backup archives should always contain the same files

[Eric Snow]

...for the same juju version.

Currently we are not including four different files if they don't exist on the host (see state/backups/files.go). Instead backup should fail with a meaningful error if any of the files do not exist.

An alternative is to make it clear via a manifest file in the archive as to which files are in all archives, which are supplemental (i.e. optional) and which ones were missing. However, this only covers up the fact that some data a user may have wanted (e.g. logs) was left out.

Another alternative is to give users the option (in the CLI and API client) to allow files to be missing. The default would be to require that all files be included.

[Nate Finch (natefinch)]

It seems to me, as a consumer of backups, that I would not feel very trusting of a backup that didn't always contain the same stuff. If sometimes some of it could be missing, how do I know that it's not just a bug? Also, if it seems like the usefulness of any particular file in a backup is binary - either it's useful enough to backup, or it's not. It shouldn't ever just be there "some of the time if it's handy and easy to get".

I'm also definitely against any kind of manifest. The backup file should be opaque to users. It should be a blob they never need to get into. IF they ever do, it should be the exception, not the rule. At best, this kind of information about optional files should simply be in the help for backups somewhere. ...but again, the idea of optional data in backups seems incredibly wrong to me.