Bug 1308713 - engine-backup backup/restore time/space considerations
engine-backup backup/restore time/space considerations
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: Documentation (Show other bugs)
3.6.3
Unspecified Unspecified
medium Severity medium
: ovirt-3.6.9
: ---
Assigned To: Julie
Byron Gravenorst
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-15 15:57 EST by Yedidyah Bar David
Modified: 2016-12-01 01:08 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-01 01:08:19 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Docs
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Yedidyah Bar David 2016-02-15 15:57:56 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
--*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.
Comment 1 Roman Hodain 2016-02-16 01:10:16 EST
This should be part of the documentation. KB is rather a workaround.
Comment 2 Yedidyah Bar David 2016-02-16 01:50:38 EST
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).
Comment 4 Lucy Bopf 2016-06-07 02:53:10 EDT
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).
Comment 6 Byron Gravenorst 2016-09-23 00:03:50 EDT
Reviewed and verified. 

Updated the revision history.

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