juju-backup plugin
Bug #1254572 reported by
Tim Penhey
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
juju-core |
Fix Released
|
Critical
|
Ian Booth |
Bug Description
Create a plug-in that backs up the relevant information from the bootstrap node in order to recover the environment due to catastrophic failure.
The database should be backed up by doing the following:
sudo stop juju-db
sudo mongodump --dbpath /var/lib/juju/db # where does it put it?
sudo start juju-db
That mongo dump will then be tar.gz'ed up with the other important files:
/var/lib/juju/*
- with the possible exclusion of containers (let them be rebuilt)
/etc/init/*juju*
/etc/rsyslog/*juju*
/home/ubuntu/
- more than just the original may have been configured and recorded in state
Related branches
lp:~wallyworld/juju-core/juju-backup-script
- John A Meinel: Approve
-
Diff: 113 lines (+108/-0)1 file modifiedcmd/plugins/juju-backup/juju-backup (+108/-0)
tags: | added: backup-restore |
Changed in juju-core: | |
milestone: | none → 1.17.1 |
Changed in juju-core: | |
status: | In Progress → Fix Committed |
milestone: | 1.17.1 → 1.17.0 |
Changed in juju-core: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
I think we should actually be explicit in that we don't backup any of the unit that may be running on machine 0.
This means we should be able to ignore any juju unit upstart jobs for the unit agents, and ignore any unit agent configuration files in /var/lib/juju, as well as any unit agent rsyslog configuration.
It wouldn't be right to bring back the unit agents when the charm isn't there.
We probably need a not entirely horrible way to indicate that units that were on machine 0 are no longer there (during restore)