Update Satellite - Backup & Restore

Latest response

Hello,

we have a single satellite server, running on an rhel7 vmware based virtual machein. All client configuration management and patching is running nightly, so i want to update from Satellite 6.6 to 6.9 during daytime. My plan looks as follows:

  1. Shutdown satellite services and vm
  2. Create a full vm backup (vmdk)
  3. Start satellite
  4. Update satellite
  5. In case of fire: Destroy current vm and used the backuped one from step 2

Will this work? Anything else that i missed in my considerations? I havent found this type of backup in the docs, but i think in my case its the easiest and fastest way.

https://access.redhat.com/documentation/en-us/red_hat_satellite/6.6/html/administering_red_hat_satellite/chap-red_hat_satellite-administering_red_hat_satellite-backup_and_disaster_recovery

Kind regards,
Sascha

Responses

Hello, that approach should work well, similarly like creating a snapshot of the VM "only".

Neither is officially tested hence not officially supported - since there can be too many options of cloning or backuping or snapshoting a VM. But there should not be any principal issue why it wont work.

I've put considerable time into testing and investigating different options to backup Satellite. Our environment consists of several capsules next to Satellite. The only official way is the LVM snapshot feature with list of requirements, all of which you have to take into account when designing and setting up your VM's, with growth and scaling in mind. This is challenging to say the least (almost impossible even). The space requirement is twice the space you currently occupy (1,5 TB in databases and pulp requires 1,5 TB free unallocated in the LVM VG, and another 1,5 TB free space in your backup location), because it first copies the data to a temporary location and then creates the archives in the final backup location. The time this takes is insane, and with a large pulp collection it can take an entire day to fully backup a large Satellite environment.

Nevertheless, I found that even when setup for the official way with LVM snapshotting, the restores were hit & miss; this is completely unacceptable if you ask me. Restores should be fool proof, with 100% success rate. I stopped troubleshooting and investigating, and opted for making clones instead. I wrote a couple of ansible playbooks that shut down the VM's, make an offline snapshot, turns them back on (downtime is less than a few minutes) and creates clones from the offline snapshots to backup VM's. These clones are independent, with exactly the same virtual hardware settings. Any of the clones can be used to replace their counterpart without any issues.

With just a single Satellite VM, I would definitely go this route; the official backup simply isn't reliable enough and your downtime will be significantly longer, as you would have to reinstall Satellite and restore your backup on that. The risk here also is that when you install a new Satellite, it may contain different patches or even be a different minor version. Another requirement you have to take into account.

Do yourself a favor, shutdown Satellite, make an independent clone and turn your Satellite back on. Few minutes downtime. Then test your upgrade steps on the clone. Isolate it from the network so that it won't serve DHCP, DNS or BOOTP requests or cause IP conflicts. Once you're satisfied your steps work, throw the clone away, make a new clone and leave it as a backup option and implement your steps on your production Satellite.

Good luck!

Hey Pan Cake,

thank you for your great and detailed answer. I`ve also contacted support and received the following answer:

"Take a snapshot of the host and proceed with the plan. // As the Satellite host is hosted on Vmware env, then we generally suggest taking a Vmware snapshot of the satellite server and proceed with the update/upgrade."

Also RH, or at least this supporter, recommends to use vSphere Snapshots/Clones.