Bug 1308713

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.