Juju backup doesn't contain .juju files

[Gema Gomez]

We have lost a machine from which we deployed a cloud today. This is the node that had the .juju credentials and all the charms. The juju environment is still there but we have no access to the bootstrap node or any other machine for that matter (we lost the certificates).

After this event happened we decided to make a juju backup of another cloud and check what is inside. We couldn't find the certificates or CA files in it that would have allowed us to recover the environment so we are copying all that manually at the moment.

The juju version used for the test is: 1.20.10-trusty-amd64

[Aaron Bentley (abentley)]

AFAICT, you are talking about the files in the .juju directory of the juju client machine. The .juju directory may contain credentials that are unrelated to the environment being backed up, so it would be a security breach to include *all* files, but it would be possible to back up the .jenv file for the particular environment. But you'd presumably also need the relevant ssh private key.

It's possible, but I think it also makes sense to place the onus on the juju user to back up their own .juju directory and credentials.

[Gema Gomez (gema)]

Hi Aaron, yes I was talking about that directory.

First of all, the creation of keys and credentials for the juju environment are completely transparent to the user, hence the user may or may not know she has to make a backup of the keys. From the viewpoint of a user, I'd think that it should be easy to access my juju environment from a different client if I wanted to. I haven't seen anywhere documented and stressed how important this "client machine" is, it's as important as the keys to your car... for which the provider always gives you two sets in case you misplace/lose/destroy one accidentally.

However I see your point about being cautious and maybe putting these credentials and files within the backup, unencripted is not a good idea. We could add a different backup option (backup-client or backup-keys ? ) and could backup all the client content on a file encrypted with a key of the user's choice so that they can be safely stored away. This should also be properly documented and emphasized so users know about it and can manage it as part of their backup policies.

[Eric Snow (ericsnowcurrently)]

Also note that a juju backup file contains only files related to recreating a juju state machine (e.g. db dump, server-side config). It won't include client-side files nor any files from deployed services.

[Eric Snow (ericsnowcurrently)]

I've opened a documentation bug at https://github.com/juju/docs/issues/313 about making it clear to users that they should back up their client-side files. Considering that there isn't a lot to back up and that it isn't spread out over the filesystem, I'm not convinced that adding tooling to the juju client will bring a lot of benefit.

I'm closing this bug in favor of the documentation one, but if you feel like there is more to address here please feel free to re-open the bug. Thanks!

[Gema Gomez (gema)]

I think a comment in the juju backup command saying explicitely that it excludes the client side is necessary.

[Eric Snow (ericsnowcurrently)]

I think a note in the command's help text is certainly in order. I'm not convinced that we should spam users every time they run the command though. I'm going to consider it and get back to you tomorrow.

[Eric Snow (ericsnowcurrently)]

For the record, I also opened a feature request for the GUI: #1437022.

[Eric Snow (ericsnowcurrently)]

lp:1437022