restore command and label design #42

Closed
opened 2023-11-12 01:10:56 +00:00 by 3wordchant · 6 comments
Owner

In looking at #26, I'm wondering about the command-line interface to backup restore

Currently, it will try to restore either "everything on the server" (without -h) or "all volumes associated with an app" (if -h is set).

Personally, it would be useful to be able to restore a single service at a time – so for e.g. wordpress.example.com, being able to restore just the app service (i.e. the wordpress_content volume) or the db service (i.e. copying dump.sql.gz into the mariadb volume, then running the post-restore command to load it).

Additionally, at Autonomic, we will almost never want to restore an entire server, and we will rarely, if ever, need to restore secrets (although it's AWESOME that they are now backed up effectively through backupbot 😍). So, it would be nice if these options weren't the default.

So, I would like to propose the following CLI:

backup restore (STACK SERVICE|--all) [--secrets]

STACK      stack name, e.g. "wordpress.example.com"
SERVICE    service name, e.g. "app"

--all      restore all stacks and services
--secrets  restore secrets associated with the stacks and services to be restored

CC @moritz

In looking at #26, I'm wondering about the command-line interface to `backup restore` Currently, it will try to restore either "everything on the server" (without `-h`) or "all volumes associated with an app" (if `-h` is set). Personally, it would be useful to be able to restore a single service at a time – so for e.g. `wordpress.example.com`, being able to restore just the `app` service (i.e. the `wordpress_content` volume) or the `db` service (i.e. copying `dump.sql.gz` into the `mariadb` volume, then running the post-restore command to load it). Additionally, at Autonomic, we will almost never want to restore an entire server, and we will rarely, if ever, need to restore secrets (although it's AWESOME that they are now backed up effectively through backupbot 😍). So, it would be nice if these options weren't the default. So, I would like to propose the following CLI: ``` backup restore (STACK SERVICE|--all) [--secrets] STACK stack name, e.g. "wordpress.example.com" SERVICE service name, e.g. "app" --all restore all stacks and services --secrets restore secrets associated with the stacks and services to be restored ``` CC @moritz
3wordchant added this to the backupbot revolution project 2023-11-12 01:11:50 +00:00
Owner

I like the idea of being able to choose the volumes/container to restore.

Secrets are only backed up at the moment. Without having the secrets you are not able to restore most database dumps without manually resetting the passwords. But there is still no automated secret restore function. This would need to be implemented into abra.

I like the idea of being able to choose the volumes/container to restore. Secrets are only backed up at the moment. Without having the secrets you are not able to restore most database dumps without manually resetting the passwords. But there is still no automated secret restore function. This would need to be implemented into `abra`.
decentral1se added the
help wanted
label 2024-01-11 13:32:34 +00:00
Owner

@moritz @3wordchant heyyy, it is already possible to implement this interface on the abra side? What CLI args would I pass to the backup-bot-two to achieve the desired interface (stack, stack + service, no secrets, with secrets etc.)

@moritz @3wordchant heyyy, it is already possible to implement this interface on the `abra` side? What CLI args would I pass to the backup-bot-two to achieve the desired interface (stack, stack + service, no secrets, with secrets etc.)
Owner

Relaying updates via Matrix:

m: I hope I'll go on with it in about a month. I think the restore logic is more complex than the backups as the container should not running when restoring the files and the database needs to run and should not restart because of health checks during the restore process.

Annnnd there seems to be consensus on the CLI interface proposed in #42 (comment) 🎉

I can try wire this interface up in abra in the meantime and then hopefully we can test and close this one off in not $infinite_time 🙏

Relaying updates via Matrix: > m: I hope I'll go on with it in about a month. I think the restore logic is more complex than the backups as the container should not running when restoring the files and the database needs to run and should not restart because of health checks during the restore process. Annnnd there seems to be consensus on the CLI interface proposed in https://git.coopcloud.tech/coop-cloud/backup-bot-two/issues/42#issue-3912 🎉 I can try wire this interface up in `abra` in the meantime and then hopefully we can test and close this one off in not `$infinite_time` 🙏
Owner

Current usage:

Usage: backup restore [OPTIONS]

Options:
  -s, --snapshot TEXT
  -t, --target TEXT
  --noninteractive
  -v, --volumes TEXT
  -c, --container TEXT
  --help                Show this message and exit

Now it's possible to select the container which restores all belonging volumes and executes all belonging commands. And/Or it's also possible to select the individual volumes which should be restored. If the global -h, --host TEXT options is set only a specific app is restored.
For abra these env variables exist:
SNAPSHOT, TARGET, NONINTERACTIVE, VOLUMES, CONTAINER, SERVICE

Current usage: ``` Usage: backup restore [OPTIONS] Options: -s, --snapshot TEXT -t, --target TEXT --noninteractive -v, --volumes TEXT -c, --container TEXT --help Show this message and exit ``` Now it's possible to select the `container` which restores all belonging volumes and executes all belonging commands. And/Or it's also possible to select the individual `volumes` which should be restored. If the global `-h, --host TEXT` options is set only a specific app is restored. For abra these env variables exist: `SNAPSHOT`, `TARGET`, `NONINTERACTIVE`, `VOLUMES`, `CONTAINER`, `SERVICE`
Owner

@3wordchant @moritz amazing stuff folks. Is there anything to be resolved here in terms of design then? I see labels mentioned in the issue name and elsewhere. Otherwise, I guess we can close off? I'll be working on the abra side of things soon!

@3wordchant @moritz amazing stuff folks. Is there anything to be resolved here in terms of design then? I see labels mentioned in the issue name and elsewhere. Otherwise, I guess we can close off? I'll be working on the `abra` side of things soon!
Owner

Continues at #58

Continues at https://git.coopcloud.tech/coop-cloud/backup-bot-two/issues/58
decentral1se moved this to Done in backupbot revolution on 2025-04-20 06:03:25 +00:00
Sign in to join this conversation.
No description provided.