We added in 3.6 options that can affect $subject. This was partially tracked in bug 1213152 and bug 1213153. Considering past experience of gss, we might want to write some document, either as a KB article or part of main docs, with relevant material. Specifically: 1. Use of custom vs plain format Custom has more features, allows faster restores etc. Plain is "simpler", some admins tend to prefer it because it gives an impression of something more portable, easier to debug etc. In 3.5 we had only plain. In 3.6 we have both, default to custom. 2. Compression options and size/speed I think plain is more compressible, thus potentially needs less space. Custom is faster to restore, especially on multi-core client (restore machine) and server (db, if db on remote machine) with fine-tuned --*db-restore-jobs options. 3. Backing up scope=all vs some scopes separately Especially important if a single large system with engine+dwh+reports. If we backup all, and especially if we restore all in a single run, can potentially take much more time. Restoring each part separately wasn't tested (at least not well, perhaps I tested it but not sure about proper qe). 4. Separate machines Best is to have each of engine/dwh/reports on its own machine. IIUC we didn't test engine-backup on a dwh- or reports-only machine. It should work, but ugly - currently requires installing (and not configuring) the engine (bug 1216888). This way, if only one of them dies, there's less to restore, and if all died, can be restored in parallel, especially if DBs are on their own separate machines, and engine can be brought up sooner while dwh is still restored (if history data for the gap is not important). We do have docs for migrating dwh/reports to separate machines, I do not think we ever talked about backup/restore for them.
This should be part of the documentation. KB is rather a workaround.
A few more notes: (In reply to Yedidyah Bar David from comment #0) > 2. Compression options and size/speed > I think plain is more compressible, thus potentially needs less space. > Custom is faster to restore, especially on multi-core client (restore > machine) and server (db, if db on remote machine) with fine-tuned > --*db-restore-jobs options. Obviously the compressor used also significantly affects speed/size. custom uses gzip-compatible compression internally, and restoring from it with more then one job (--*db-restore-jobs) requires that it will not be further compressed (*compressor=None).
Assigning to Julie for review. Julie, I think we're just missing items 1 and 2 for this bug. Items 3 and 4 have now been addressed separately (though please let me know if you think there's still work to be done).
Reviewed and verified. Updated the revision history.
This content has now been published: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6/html-single/Administration_Guide/index.html#sect-Backing_Up_and_Restoring_the_Red_Hat_Enterprise_Virtualization_Manager Moving to CLOSED.