forked from toolshed/docs.coopcloud.tech
		
	update
This commit is contained in:
		| @ -7,12 +7,13 @@ backup/restore logic. | ||||
| ## Tools | ||||
|  | ||||
| Two of the current "blessed" options are, which both implement the [backupbot specification](link to spec) | ||||
|  | ||||
| - [`backup-bot-two`](https://git.coopcloud.tech/coop-cloud/backup-bot-two) | ||||
| - [`abra`](https://git.coopcloud.tech/coop-cloud/abra) | ||||
|  | ||||
| ### `backup-bot-two` | ||||
|  | ||||
| `backup-bot-two` is a recipe which gets deployed on the server, it can perform automatic backups. | ||||
| `backup-bot-two` is a recipe which gets deployed on the server, it can perform automatic backups and uses restic. | ||||
| Please see the [`README.md`](https://git.coopcloud.tech/coop-cloud/backup-bot-two#backupbot-ii) for the full docs. | ||||
|  | ||||
| ### `abra` | ||||
| @ -27,19 +28,22 @@ It also provides an integration for `backup-bot-two`. | ||||
| Unless otherwise stated all labels should be added to the main service (which should be named `app`). | ||||
|  | ||||
| 1. Enable backups for the recipe: | ||||
| You need to enable backups for the recipe by adding the following label: | ||||
|    You need to enable backups for the recipe by adding the following deploy label: | ||||
|  | ||||
| ``` | ||||
| backupbot.backup=true | ||||
| ``` | ||||
|  | ||||
| 2. Decide wich volumes should be backed up: | ||||
| By default all volumes will be backed up. To disable a certain volume you can add the following label: | ||||
|    By default all volumes will be backed up. To disable a certain volume you can add the following deploy label: | ||||
|  | ||||
| ``` | ||||
| backupbot.backup.volumes.{volume_name}=false | ||||
| ``` | ||||
|  | ||||
| 3. Decide which path should be backed up on each volume | ||||
| By default all files get backed up for a volume. To only include certain paths you can add the following label: | ||||
|    By default all files get backed up for a volume. To only include certain paths you can add the following deploy label: | ||||
|  | ||||
| ``` | ||||
| backupbot.backup.volumes.{volume_name}.path=/mypath1/foo,/mypath2/bar | ||||
| ``` | ||||
| @ -48,15 +52,17 @@ Note: You can include multiple paths by providing a comma seperated list | ||||
| Note: All paths are specified relativ to the volume root | ||||
|  | ||||
| 4. Run commands before the backup | ||||
| For certain services like a database it is not reccomend to just backup files, because the backup might end up in a corrupted state. Instead it is reccomended to make a database dump. You can run arbitrary commands in any container before the files are backed up. | ||||
| To do this add the following label to the service on which you want the command being run: | ||||
|    For certain services like a database it is not reccomend to just backup files, because the backup might end up in a corrupted state. Instead it is reccomended to make a database dump. You can run arbitrary commands in any container before the files are backed up. | ||||
|    To do this add the following deploy label to the service on which you want the command being run: | ||||
|  | ||||
| ``` | ||||
| backupbot.backup.pre-hook=mysqldump -u root -pghost ghost --tab /var/lib/foo | ||||
| ``` | ||||
|  | ||||
| 5. Run commands after the backup | ||||
| Sometimes you want to clean up after the backup. You can run arbitrary commands in any container after the files were backed up. | ||||
| To do this add the following label to the service on which you want the command being run: | ||||
|    Sometimes you want to clean up after the backup. You can run arbitrary commands in any container after the files were backed up. | ||||
|    To do this add the following deploy label to the service on which you want the command being run: | ||||
|  | ||||
| ``` | ||||
| backupbot.backup.post-hook=rm -rf /var/lib/mysql-files/* | ||||
| ``` | ||||
| @ -72,6 +78,8 @@ abra app backup myrecipe.example.com | ||||
| tar -tf ~/.abra/backups/mybackup | ||||
| ``` | ||||
|  | ||||
| TODO: this is not complete yet | ||||
|  | ||||
| ## Restore | ||||
|  | ||||
| When restoring an app, it takes the files from a backup and copies them to their correct location. | ||||
| @ -85,16 +93,19 @@ The pre and post hooks can be used to prepare the files which should get backed | ||||
| Here are some examples: | ||||
|  | ||||
| ### Example 1: Execute simple command | ||||
|  | ||||
| ``` | ||||
| backupbot.backup.pre-hook: "echo 'foo' > /path/to/volume/bar.txt | ||||
| ``` | ||||
|  | ||||
| ### Example 2: Access environment variable | ||||
|  | ||||
| ``` | ||||
| backupbot.backup.pre-hook: "cat $${POSTGRES_PASSWORD_FILE}" | ||||
| ``` | ||||
|  | ||||
| ### Example 3: Access secret | ||||
|  | ||||
| ``` | ||||
| backupbot.backup.pre-hook: "cat /var/run/secrets/mysupersecret" | ||||
| ``` | ||||
| @ -104,7 +115,9 @@ backupbot.backup.pre-hook: 'mysqldump -p"$$(cat /run/secrets/mysupersecret)" myd | ||||
| ``` | ||||
|  | ||||
| ### Example 4: Complex script | ||||
|  | ||||
| Sometimes the logic to backup up a service can get quite complex. In that case it might be easier to add a script (via mount or config) inside the container and call that from the pre and post hook: | ||||
|  | ||||
| ``` | ||||
| backupbot.backup.pre-hook: "/scripts/my-pre-backup-scripts" | ||||
| backupbot.backup.post-hook: "/scripts/my-post-backup-scripts" | ||||
|  | ||||
		Reference in New Issue
	
	Block a user