Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1505890 - [RFE] Document snapshot backups
Summary: [RFE] Document snapshot backups
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Docs Server Administration Guide
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: Unspecified
Assignee: Michaela Slaninkova
QA Contact: Russell Dickenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-10-24 13:41 UTC by Peter Ondrejka
Modified: 2019-09-26 16:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-02-23 09:49:47 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Peter Ondrejka 2017-10-24 13:41:12 UTC
New feature being added for satellite-backup, see https://bugzilla.redhat.com/show_bug.cgi?id=1502889

Using this feature has some prerequisites, and is different from regular backups, so it should be documented.

Comment 1 Peter Ondrejka 2017-10-24 13:54:33 UTC
Sorry, error, the correct link is https://bugzilla.redhat.com/show_bug.cgi?id=1284686

Comment 2 Andrew Dahms 2017-11-01 01:15:36 UTC
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

Comment 3 Andrew Dahms 2017-11-01 01:44:26 UTC
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.

Comment 6 Peter Ondrejka 2018-02-07 11:42:35 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.