Bug 1505890

Sorry, error, the correct link is https://bugzilla.redhat.com/show_bug.cgi?id=1284686

See the following comment in the attached engineering bug for some important details that should be noted in the documentation -

https://bugzilla.redhat.com/show_bug.cgi?id=1284686#c17

Assigning to Misa for review.

Misa - this bug should be worked on after the work in BZ#1508264 is complete. We will need to add a new sub-section along the lines of "Performing a Snapshot Backup" to the same section on backing up Satellite Server that provides a quick overview of what it does and the points raised in the bug linked in comment #2, then a procedure on how to perform the backup. We should also include the same "Warning" admonition box as the other backup procedures.

Hi, 

I think your description reads well, here are some suggestions:

-- In the 1st sentence I would say: A snapshot backup method uses *LVM* snapshots of the pulp, mongodb, and pgsql *directories* to create a backup. 

-- What are the advantages over online-backup? I'd say smth. like (I leave style corrections to you :P): "This method takes less time than creating a full off-line backup, which reduces Satellite downtime. The actual backup is then performed from the LVM snapshot and not from the running Satellite like it is with online backup, which mitigates the risk of creating an inconsistent backup. As such, this method suits well for backing up highly populated Satellite servers with long backup times."

-- note that this feature has implications on chapter 7.1.4. about online backup. In that important box, you can now recommend using snapshot backup in production 

-- "There is 3 times the snapshot size free disk space in the relevant volume groups (VGs). The default snapshot size is 2GB so 6GB are required." -- I'd say it is just one VG in most cases. 2GB is default *block* size, which is someth. like a unit of measurement, snapshot size can be much bigger, so this bit is not correct. I would leave it out, but if you really want to mention it, then add also that block size can be adjusted using *--snapshot-size* option.

-- This is a bit hard to describe, but the 3 times size requirement is a little more complex. The VG has to have enough LV-less space for creating snapshots (which are esentially new LVs). And the target backup dir will arrive at some existing LV, so there has to be an LV with sufficient space for it. I suggest:

"There is 3 times the snapshot size free disk space in the relevant volume group (VG). More precisely, VG has to have enough space unreserved by the member LVs to accommodate new snapshots. In addition, one of the LVs has to have enough free space to accommodate backup directory."

-- IMHO the 3rd prerequisite is also not true, as we are snapshotting just pulp, mongo and pgsql and not previous backups. I'd just say: "Make sure the target directory for backup is on a LV with sufficient space, preferably a different LV than the source files (/var/lib/pulp/, /var/lib/mongodb/, /var/lib/pgsql/) are stored on"

-- also it is important to note the LVM snapshots are just a midproduct and are removed after successful backup. I would add that to the last paragraph about restarting services.

Hope this helps.

Hello,


This content is now live on the customer portal.

https://access.redhat.com/documentation/en-us/red_hat_satellite/6.3/html-single/administering_red_hat_satellite/#sect-Red_Hat_Satellite-Administering_Red_Hat_Satellite-Backing_up_Satellite_Server_or_Capsule_Server-Performing_a_Snapshot_Backup