abra app backup/restore #70

Closed
opened 2020-12-31 17:39:20 +00:00 by decentral1se · 5 comments
Owner

Inspiration:

# backup files
abra app foo.info cp app:/var/www/html/wp-content - | gzip > foo_wp-content_`date +%F`.tar.gz

# backup DB
abra app foo.info run db "mysqldump -u root -p$(pass hosts/swarm.autonomic.zone/anarchyrules_info/db_root_password) wordpress" | gzip > anarchyrules_`date +%F`.sql.gz

# restore files
zcat foo_wp-content_`date +%F`.tar.gz | abra app foo.info cp - app:/var/www/html/wp-content

# restore database
zcat foo_`date +%F`.sql.gz | abra app foo.info run db --no-tty "mysql -u root -p$(pass hosts/swarm.autonomic.zone/foo_info/db_root_password) wordpress"

One braindump is: AFAIU each app probably has different commands to deal with the backing up, I was thinking that we could maybe specify a commands.sh or whatever in the actual upstream app repo which abra then sources and runs. This leaves the specifics of the backing up and restoring to the package maintainer. abra can feed in the container names and passwords etc. required to get it done.

Inspiration: ``` # backup files abra app foo.info cp app:/var/www/html/wp-content - | gzip > foo_wp-content_`date +%F`.tar.gz # backup DB abra app foo.info run db "mysqldump -u root -p$(pass hosts/swarm.autonomic.zone/anarchyrules_info/db_root_password) wordpress" | gzip > anarchyrules_`date +%F`.sql.gz # restore files zcat foo_wp-content_`date +%F`.tar.gz | abra app foo.info cp - app:/var/www/html/wp-content # restore database zcat foo_`date +%F`.sql.gz | abra app foo.info run db --no-tty "mysql -u root -p$(pass hosts/swarm.autonomic.zone/foo_info/db_root_password) wordpress" ``` One braindump is: AFAIU each app probably has different commands to deal with the backing up, I was thinking that we could maybe specify a `commands.sh` or whatever in the actual upstream app repo which `abra` then sources and runs. This leaves the specifics of the backing up and restoring to the package maintainer. `abra` can feed in the container names and passwords etc. required to get it done.
decentral1se added the
enhancement
design
labels 2020-12-31 17:39:20 +00:00
Owner

One braindump is: AFAIU each app probably has different commands to deal with the backing up, I was thinking that we could maybe specify a commands.sh or whatever in the actual upstream app repo which abra then sources and runs. This leaves the specifics of the backing up and restoring to the package maintainer. abra can feed in the container names and passwords etc. required to get it done.

Snap, this was my thought too.

Good news! commands.sh already exists, peep e.g. coop-cloud/wordpress:

https://git.autonomic.zone/coop-cloud/wordpress/src/branch/master/abra-commands.sh

You just define a sub_something command there and then abra app foo_bar something "args" becomes available.

One down-side is it doesn't integrate w/ docopt (yet?) so it won't show up in abra --help and you don't get any fancy argument-parsing, but maybe enough to start with.

> One braindump is: AFAIU each app probably has different commands to deal with the backing up, I was thinking that we could maybe specify a `commands.sh` or whatever in the actual upstream app repo which abra then sources and runs. This leaves the specifics of the backing up and restoring to the package maintainer. abra can feed in the container names and passwords etc. required to get it done. Snap, this was my thought too. Good news! `commands.sh` already exists, peep e.g. coop-cloud/wordpress: https://git.autonomic.zone/coop-cloud/wordpress/src/branch/master/abra-commands.sh You just define a `sub_something` command there and then `abra app foo_bar something "args"` becomes available. One down-side is it doesn't integrate w/ docopt (yet?) so it won't show up in `abra --help` and you don't get any fancy argument-parsing, but maybe enough to start with.
Author
Owner

YES 🚀

One down-side is it doesn't integrate w/ docopt (yet?)

Definitely think we can hack a sub-parser into the abra-commands.sh for this!

YES 🚀 > One down-side is it doesn't integrate w/ docopt (yet?) Definitely think we can hack a sub-parser into the `abra-commands.sh` for this!
Owner

Or:

Define abra [command] app <app> backup [whatever args we want] in abra, have it call app_backup if it's defined and say "no backup configuration for this app yet" if it's not.

Then define app_backup in per-app abra-commands.sh.

Advantage: we can use whichever tasty docopt-parsed options to backup we want, without messing with sub-parsers (which I am still unsure how to do).

Disadvantage is all apps' backup commands would need to take the same arguments, but maybe that's a good thing.


Question: where should backups go by default? ~/.abra/backups seems decent, although maybe not the most intuitive.

$PWD (default from the above one-liners) could also be fine?

Or we could yunohost / Cloudron / Heroku it, and have backups live on the server in a fixed directory by default then have a separate command to download them locally - would also solve the "transmitting possibly-uncompressed data over the network" wrinkle -- but I think would be architecturally harder; would we need to SSH to the swarm box and run docker cp there intead? 🤔

Or: Define `abra [command] app <app> backup [whatever args we want]` in `abra`, have it call `app_backup` if it's defined and say "no backup configuration for this app yet" if it's not. Then define `app_backup` in per-app `abra-commands.sh`. Advantage: we can use whichever tasty docopt-parsed options to `backup` we want, without messing with sub-parsers (which I am still unsure how to do). Disadvantage is all apps' `backup` commands would need to take the same arguments, but maybe that's a good thing. --- Question: where should backups go by default? `~/.abra/backups` seems decent, although maybe not the most intuitive. `$PWD` (default from the above one-liners) could also be fine? Or we could yunohost / Cloudron / Heroku it, and have backups live on the server in a fixed directory by default then have a separate command to download them locally - would also solve the "transmitting possibly-uncompressed data over the network" wrinkle -- but I think would be architecturally harder; would we need to SSH to the swarm box and run `docker cp` there intead? 🤔
Author
Owner

Or:

Define abra [command] app backup [whatever args we want] in abra, have it call app_backup if it's defined and say "no backup configuration for this app yet" if it's not.

Then define app_backup in per-app abra-commands.sh.

Advantage: we can use whichever tasty docopt-parsed options to backup we want, without messing with sub-parsers (which I am still unsure how to do).

Disadvantage is all apps' backup commands would need to take the same arguments, but maybe that's a good thing.

Perfect

Question: where should backups go by default? ~/.abra/backups seems decent, although maybe not the most intuitive.

$PWD (default from the above one-liners) could also be fine?

Or we could yunohost / Cloudron / Heroku it, and have backups live on the server in a fixed directory by default then have a separate command to download them locally - would also solve the "transmitting possibly-uncompressed data over the network" wrinkle -- but I think would be architecturally harder; would we need to SSH to the swarm box and run docker cp there intead? 🤔

$PWD or ~/.abra/backups seems fine! I guess we'll output a line where they live when they are produced. Having them remote also seems solid but yes, more work 🥇 Liking the way this is shaping up!

> Or: > > Define abra [command] app <app> backup [whatever args we want] in abra, have it call app_backup if it's defined and say "no backup configuration for this app yet" if it's not. > > Then define app_backup in per-app abra-commands.sh. > > Advantage: we can use whichever tasty docopt-parsed options to backup we want, without messing with sub-parsers (which I am still unsure how to do). > > Disadvantage is all apps' backup commands would need to take the same arguments, but maybe that's a good thing. Perfect ⭐ > Question: where should backups go by default? ~/.abra/backups seems decent, although maybe not the most intuitive. > > $PWD (default from the above one-liners) could also be fine? > > Or we could yunohost / Cloudron / Heroku it, and have backups live on the server in a fixed directory by default then have a separate command to download them locally - would also solve the "transmitting possibly-uncompressed data over the network" wrinkle -- but I think would be architecturally harder; would we need to SSH to the swarm box and run docker cp there intead? 🤔 `$PWD` or `~/.abra/backups` seems fine! I guess we'll output a line where they live when they are produced. Having them remote also seems solid but yes, more work 🥇 Liking the way this is shaping up!
Owner

Getting there:

$ abra app foo.info backup app -U
$ ls
foo.info_wp-content_2021-01-01.tar.gz
$ tar -tzvf foo.info_wp-content_2021-01-01.tar.gz 
drwxrwxrwx 33/33             0 2020-12-30 16:36 wp-content/
drwxrwxrwx 33/33             0 2020-11-19 07:06 wp-content/cache/
-rw-r--r-- 33/33            28 2012-01-08 19:01 wp-content/index.php
drwxrwxrwx 33/33             0 2020-12-17 03:00 wp-content/languages/
-rw-r--r-- 33/33        458682 2020-12-17 03:00 wp-content/languages/admin-en_GB.mo
...

(-U is --skip-update to not run git pull every time 😬 I put it in [options] so it can be added to any command)

Getting there: ``` $ abra app foo.info backup app -U $ ls foo.info_wp-content_2021-01-01.tar.gz $ tar -tzvf foo.info_wp-content_2021-01-01.tar.gz drwxrwxrwx 33/33 0 2020-12-30 16:36 wp-content/ drwxrwxrwx 33/33 0 2020-11-19 07:06 wp-content/cache/ -rw-r--r-- 33/33 28 2012-01-08 19:01 wp-content/index.php drwxrwxrwx 33/33 0 2020-12-17 03:00 wp-content/languages/ -rw-r--r-- 33/33 458682 2020-12-17 03:00 wp-content/languages/admin-en_GB.mo ... ``` (`-U` is `--skip-update` to not run `git pull` every time 😬 I put it in `[options]` so it can be added to any command)
This repo is archived. You cannot comment on issues.
No Milestone
No Assignees
2 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/abra#70
No description provided.