Red Hat Bugzilla – Bug 1308713
engine-backup backup/restore time/space considerations
Last modified: 2016-12-01 01:08:19 EST
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
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:
Moving to CLOSED.