Arriving at a workable generic backup solution #30
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Current stab was https://git.autonomic.zone/coop-cloud/backup-bot.
Upsides:
Downsides:
Something more flexible and disconnected directly from the app repository would be ideal. There has been some research going on, so here comes the links:
backup-bot example working configs:
Use-cases
docker inspect
backupbot
currentlyFeatures
Coming down the tubes over at https://git.autonomic.zone/coop-cloud/abra/issues/70
July 2021: Some More Thoughts
coop-cloud.backup-bot
label on any serviceBased on restic-docker-swarm:
Personally I would also love to see
backup-bot
support restic for those of us who aren't yet borgbase converts.This looks promising: https://github.com/offen/docker-volume-backup
150c953c51
Another thought: abra could also read these labels and run the same commands as backup-bot-two, which could be the path to getting one-off backups & restores working again?
Expanding on this:
abra app backup foobar app
= read thebackupbot
labels off theapp
service, run pre/post commands, savebackupbot.backup.path
to~/.abra/backups
.abra app backup foobar
= readbackupbot
labels off all services, run as above.abra app restore foobar app app.tar.gz
= copy and extractapp.tar.gz
tobackupbot.backup.path
, and run restore-specific pre-/post- commands.@3wordchant more interface confusions on the
abra
side...Take the following labels:
When I run
abra app backup ghost.com app
, what should I get as output?ghost_com_app_<timestamp>.tar.gz
with both directories inside? Orghost_com_app_var_lib_ghost_content_<timestamp>.tar.gz
&ghost_com_app_var_lib_ghost_otherthing_<timestamp>.tar.gz
? Or another format?This causes an issue for restore, which paths should be read for the restoring of files? We have
abra app restore <domain> <service> <file>
but do we also need to add<path>
🙈From what I remember from the last chat, we don't want to make the filename of the backup file correspond to how it is restored because that will make restoring non co-op cloud apps awkward?
The simplest implementation on
abra
side would be to generate a backup file per-path & add<path>
to therestore
UI. But that may be a really not fun backup/restore interface.Got any ideas?
Available for testing on latest HEAD.
We have arrived 😅 Will be following up on fixes when feedback comes in. Thanks all!