I've just started testing with Unimus, primarily for backing up F5 (big ip) devices, but also Juniper as well. Out of the box, I see Unimus backs up the F5 config as a text file, whereas I'm wanting to also get a backup in ".ucs" format (contains more than the config file). I've seen an F5 article regarding editing the root crontab file on the F5 for creating and sending backups using public key authentication via SCP [ K13418: Archiving UCS files using the logrotate and crontab utilities (11.x - 16.x) ]. Can I use Unimus as the destination for these ".ucs" backups?
The vast majority of the potential devices to be backed up by Unimus are Juniper, with a smattering of other vendor devices. The F5s are going to require a little work on their side to get what I need.
Thanks!
[Solved] F5: Push backup to Unimus via SCP and public key auth?
-
Vik@Unimus
- Posts: 198
- Joined: Thu Aug 05, 2021 6:35 pm
Because of the nature of backups in the UCS format (an archive that is, with folders and separate files inside) being basically binary files, this type of backup is not retrieved natively by Unimus. But if you are interested in getting them into Unimus, there is another route you could take.
A little while ago we posted a blog article about backing up Mikrotik SwOS, which also uses binary backups:
https://blog.unimus.net/automating-mikr ... -to-guide/
You can use it to create a similar solution for your Big-IP devices and what's more, thanks to the fact that these devices are supported by Unimus you don't have to unmanage the devices to upload the backups to. Just set them to a schedule that will never run. You will still need to look into generating an API key from the first step, though, as you will need it to upload backups to Unimus using our API.
You can then use our script and adjust it to your needs:
- if you want to keep the existing device fetching, you will need to add a custom description for F5 devices you'd want to add UCS backups to; otherwise you can change how devices are fetched, if you prefer doing it another way
- choose and apply a preferred way to gather backups from devices - whether you enable a schedule backup on the devices themselves which you can then download using SCP or SFTP protocol on a machine where this script would be running from or have the devices uploading them directly onto that machine as you mentioned and the script would be just grabbing local files from that machine and uploading them to Unimus.
A little while ago we posted a blog article about backing up Mikrotik SwOS, which also uses binary backups:
https://blog.unimus.net/automating-mikr ... -to-guide/
You can use it to create a similar solution for your Big-IP devices and what's more, thanks to the fact that these devices are supported by Unimus you don't have to unmanage the devices to upload the backups to. Just set them to a schedule that will never run. You will still need to look into generating an API key from the first step, though, as you will need it to upload backups to Unimus using our API.
You can then use our script and adjust it to your needs:
- if you want to keep the existing device fetching, you will need to add a custom description for F5 devices you'd want to add UCS backups to; otherwise you can change how devices are fetched, if you prefer doing it another way
- choose and apply a preferred way to gather backups from devices - whether you enable a schedule backup on the devices themselves which you can then download using SCP or SFTP protocol on a machine where this script would be running from or have the devices uploading them directly onto that machine as you mentioned and the script would be just grabbing local files from that machine and uploading them to Unimus.
-
Fallout1984
- Posts: 3
- Joined: Thu Jul 21, 2022 8:23 pm
Excellent! I'll look into that. Thanks, Vik! 
-
carlos.alperin
- Posts: 1
- Joined: Thu Mar 07, 2024 12:45 pm
There was any completion on this item?
I'm going to start to work on this, just trying to not to put time on something will not work
I'm going to start to work on this, just trying to not to put time on something will not work