2024-12-11 23:50:49 +01:00
[](https://galaxy.ansible.com/ui/standalone/roles/roles-ansible/restic/)
[](LICENSE)
[](https://ansible.l3d.space/#roles-ansible.restic)
2021-08-02 01:09:02 +02:00
Ansible Role: restic
=======================
2019-08-12 17:08:26 +02:00
2019-08-15 15:46:31 +02:00
> **Beta:** This role is in beta status.
2019-08-14 16:49:48 +02:00
2021-08-02 01:09:02 +02:00
Description
-------------
2019-08-12 17:08:26 +02:00
[Restic ](https://github.com/restic/restic ) is a versatile Go based backup
solution which supports multiple backends, deduplication and incremental
backups.
This role installs restic on a client, configures the backup repositories
2021-04-29 23:05:08 +02:00
and optionally sets systemd timer or cronjobs to run the backups.
2024-09-19 21:30:53 +02:00
Additionally, it will set up executable scripts to run a backup manually.
2019-08-13 11:27:13 +02:00
2021-04-29 23:05:08 +02:00
> This Project borrowed heavily from the
> [donat-b/ansible-restic](https://github.com/donat-b/ansible-restic) and
2021-08-02 01:09:02 +02:00
> the [https://github.com/arillso/ansible.restic](https://github.com/arillso/ansible.restic)
2024-09-19 21:30:53 +02:00
> ansible role. We try to make this role more easy to understand and modern by using systemd timer,
2024-05-07 15:04:38 +02:00
> /etc/crontab to define backup paths, more absolute paths and less options. (not tested for S3 Storage or Windows...)
2019-08-12 17:08:26 +02:00
2019-08-14 16:29:27 +02:00
### Backup Scripts
2019-09-11 11:31:51 +02:00
This role will create a backup script and a file with credentials usable with the `source` command on linux for each backup in the `restic_script_dir` .
2019-08-14 16:29:27 +02:00
These executable scripts can be used to manually trigger a backup action, but
2021-08-02 01:09:02 +02:00
are also used for automated backups if you have set `restic_create_schedule` variable to true.
Make sure to not change the files manually, as this can interfere with your
2019-08-14 16:29:27 +02:00
backups quite a bit.
on Linux, if you want to take a manual snapshot, you can run the backup like this:
```bash
$ /path/to/backup/script/backup-example.sh
```
by default, such a snapshot will be given the tag `manual` , so you can distinguish
them from automatically created snapshots. You can also append more tags by
simply appending them:
```bash
$ /path/to/backup/script/backup-example.sh --tag deployment
```
### CRON / Scheduled Tasks
In order to make use of defined backups, they can be automatically setup as
scheduled tasks. You have to be aware of the fact that (on linux systems at
least) you need to have administrator permissions for configuring such an action.
If you cannot use the automatic creation of the tasks, you can still make use
of the generated scripts. If you are for example on a shared hosting server
and can define a cronjob via a webinterface, simply add each backup file to
be executed. Make sure to prefix the command with `CRON=true` to imply that the
snapshot was created via a scheduled task:
```bash
CRON=true /path/to/backup/script/backup-example.sh
```
2019-08-15 14:26:25 +02:00
## Installation
2019-08-12 17:08:26 +02:00
2022-04-01 11:00:22 +02:00
There are multiple ways to install the role. Either clone or download it directly from the [github repository ](https://github.com/roles-ansible/ansible_role_restic.git ). Or Install it via [ansible galaxy ](https://galaxy.ansible.com/do1jlr/restic ):
2019-08-15 14:26:25 +02:00
```bash
2023-11-30 17:41:56 +01:00
ansible-galaxy install roles-ansible.restic
2019-08-15 14:26:25 +02:00
```
2019-08-12 17:08:26 +02:00
## Requirements
2024-04-04 13:27:05 +02:00
2019-08-12 17:08:26 +02:00
* bzip2
2022-04-01 11:00:22 +02:00
2019-08-12 17:08:26 +02:00
## Role Variables
2023-08-31 14:53:46 +02:00
| Name | Default | Description |
|-------------------------------|---------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------|
| `restic_url` | `undefined` | The URL to download restic from. Use this variable to overwrite the default |
| `restic_version` | `'0.15.1'` | The version of Restic to install |
| `restic_download_path` | `'/opt/restic'` | Download location for the restic binary |
| `restic_install_path` | `'/usr/local/bin'` | Install location for the restic binary |
| `restic_script_dir` | `'/opt/restic'` | Location of the generated backup scripts |
2024-02-08 11:39:05 +01:00
| `restic_backup_script_shell` | `sh` | Shell to use for run of backup script |
2023-08-31 14:53:46 +02:00
| `restic_log_dir` | `'{{ restic_script_dir }}/log'` | Location of the logs of the backup scripts |
| `restic_repos` | `{}` | A dictionary of repositories where snapshots are stored. *(More Info: [Repos](#Repos))* |
| `restic_backups` | `{}` (or `[]` ) | A list of dictionaries specifying the files and directories to be backed up *(More Infos: [Backups](#Backups))* |
| `restic_create_schedule` | `false` | Should we schedule each backup? Either via cronjob or via systemd timer. |
| `restic_backup_now` | `false` | Whether or not the backup script should be run immediately |
| `restic_schedule_type` | `systemd` | Here you can define if we create a ``cronjob`` or a ``systemd`` timer. If it fails to create a systemd timer, a cronjob will be created. |
| `restic_dir_owner` | `'{{ansible_user}}'` | The owner of all created dirs |
| `restic_dir_group` | `'{{ansible_user}}'` | The group of all created dirs |
| `restic_no_log` | `true` | Set to false to see hidden ansible logs |
| `restic_do_not_cleanup_cron ` | `false` | We changed the cron location and clean up the old one. You can skip the cleanup here |
| `restic__cache_config` | `false` | Configure custom cache directory |
| `restic__cache_dir` | `'~/.cache/restic'` | Define custom cache directory |
| `submodules_versioncheck` | `false` | If you set this variable to true, the role will run a [simple versionscheck ](tasks/versioncheck.yml ) to prevent running older versions of this role. |
| `restic__limit_cpu_usage` | `false` | Should CPU usage be limited? |
| `restic__max_cpus` | `1` | Maximum number of CPUs that can be used simultaneously |
2019-08-12 17:08:26 +02:00
### Repos
Restic stores data in repositories. You have to specify at least one repository
to be able to use this role. A repository can be local or remote (see the
official [documentation ](https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html )).
> **Using an SFTP repository**
>
> For using an SFTP backend, the user needs passwordless access to the host.
> Please make sure to distribute ssh keys accordingly, as this is outside of
> the scope of this role.
Available variables:
2019-08-12 17:14:33 +02:00
2019-12-17 14:19:25 +01:00
| Name | Required | Description |
| ----------------------- |:--------:| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
2023-08-23 21:54:30 +02:00
| `location` | yes | The location of the Backend. Currently, [Local ](https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html#local ), [SFTP ](https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html#sftp ), [S3 ](https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html#amazon-s3 ), [Azure Blob ](https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html#microsoft-azure-blob-storage ) and [B2 ](https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html#backblaze-b2 ) are supported |
2019-12-17 14:19:25 +01:00
| `password` | yes | The password used to secure this repository |
| `init` | no | Describes if the repository should be initialized or not. Use `false` if you are backuping to an already existing repo. |
2019-08-12 17:08:26 +02:00
Example:
```yaml
restic_repos:
local:
location: /srv/restic-repo
2024-02-26 20:42:07 +01:00
password: securepassword0
init: true
remote:
location: rest:https://restic_rest_server.example.com:8000/restic-repo/
2019-08-12 17:08:26 +02:00
password: securepassword1
2019-08-13 13:32:28 +02:00
init: true
2023-08-23 21:57:10 +02:00
sftp:
2019-08-12 17:08:26 +02:00
location: sftp:user@host:/srv/restic-repo
password: securepassword2
2019-08-13 13:32:28 +02:00
init: true
2023-08-23 21:57:10 +02:00
aws:
location: s3:s3.amazonaws.com/bucket_name
password: securepassword3
init: true
aws_access_key: accesskey
aws_secret_access_key: secretaccesskey
aws_default_region: eu-west-1
azure:
location: azure:container:/
password: securepassword4
init: true
azure_account_name: storageaccountname
# Only one of the following are required
azure_account_key: somekey
azure_account_sas: sasurl
# Optional
azure_endpoint_suffix: core.windows.net
b2:
location: b2:bucketname:path/to/repo
password: securepassword5
init: true
b2_account_id: accountid
b2_account_key: accountkey
2019-08-12 17:08:26 +02:00
```
### Backups
A backup specifies a directory or file to be backuped. A backup is written to a
Repository defined in `restic_repos` .
Available variables:
2019-08-12 17:14:33 +02:00
2021-07-05 14:51:27 +02:00
| Name | Required (Default) | Description |
| ------------------ |:-----------------------------:| ------------ |
| `name` | yes | The name of this backup. Used together with pruning and scheduling and needs to be unique. |
| `repo` | yes | The name of the repository to backup to. |
2021-10-26 15:46:31 +02:00
| `src` | yes (unless `stdin` == `true` ) | The source directory or file |
2021-07-05 14:51:27 +02:00
| `stdin` | no | Is this backup created from a [stdin ](https://restic.readthedocs.io/en/stable/040_backup.html#reading-data-from-stdin )? |
| `stdin_cmd` | no (yes if `stdin` == `true` ) | The command to produce the stdin. |
| `stdin_filename` | no | The filename used in the repository. |
2024-01-04 19:47:04 +01:00
| `pre_backup_cmd` | no | A command to run before backup, typically used to dump databases to disk |
2024-05-24 13:55:36 +02:00
| `past_backup_cmd` | no | A command to run after backup, typically used to cleanup database dumps on disk |
2021-07-05 14:51:27 +02:00
| `tags` | no | Array of default tags |
| `keep_last` | no | If set, only keeps the last n snapshots. |
2019-09-11 16:06:18 +02:00
| `keep_hourly` | no | If set, only keeps the last n hourly snapshots. |
| `keep_daily` | no | If set, only keeps the last n daily snapshots. |
| `keep_weekly ` | no | If set, only keeps the last n weekly snapshots. |
| `keep_monthly` | no | If set, only keeps the last n monthly snapshots. |
| `keep_yearly ` | no | If set, only keeps the last n yearly snapshots. |
| `keep_within` | no | If set, only keeps snapshots in this time period. |
| `keep_tag` | no | If set, keep snapshots with this tags. Make sure to specify a list. |
2019-09-11 16:27:17 +02:00
| `prune` | no (`false`) | If `true` , the `restic forget` command in the script has the [`--prune` option ](https://restic.readthedocs.io/en/stable/060_forget.html#removing-backup-snapshots ) appended. |
2024-12-07 14:58:38 +01:00
| `forget_extra_args` | no | Extra arguments to pass to the `restic forget` command. |
2021-08-02 01:09:02 +02:00
| `scheduled` | no (`false`) | If `restic_create_schedule` is set to `true` , this backup is scheduled and tries to create a systemd timer unit. If it fails, it is creating a cronjob. |
2021-06-15 19:48:23 +02:00
| `schedule_oncalendar` | ``'*-*-* 02:00:00'`` | The time for the systemd timer. Please notice the randomDelaySec option. By Default the backup is done every night at 2 am (+0-4h). But only if scheduled is true. |
2021-07-05 14:51:27 +02:00
| `schedule_minute` | no (`*`) | Minute when the job is run. ( 0-59, *, * /2, etc ) |
2021-07-05 16:18:46 +02:00
| `schedule_hour` | no (`2`) | Hour when the job is run. ( 0-23, *, * /2, etc ) |
2021-07-05 14:51:27 +02:00
| `schedule_weekday` | no (`*`) | Weekday when the job is run. ( 0-6 for Sunday-Saturday, *, etc ) |
| `schedule_month` | no (`*`) | Month when the job is run. ( 1-12, *, * /2, etc ) |
| `exclude` | no (`{}`) | Allows you to specify files to exclude. See [Exclude ](#exclude ) for reference. |
| `disable_logging` | no | Optionally disable logging |
2021-10-19 16:38:17 +02:00
| `log_to_journald` | no | Optionally switch logging to journald with the name of the backup job as the tag |
2021-07-05 14:51:27 +02:00
| `mail_on_error` | no | Optionally send a mail if the backupjob will fail *(mailx is required)* |
2024-09-19 21:30:53 +02:00
| `mail_address` | if `mail_on_error` is true | The mail address to receive mails if you enabled ``mail_on_error``. |
2022-07-12 21:25:34 +02:00
| `monitoring_call` | no | A command that will be called if the backup is *successful* . Useful for heartbeat monitoring systems that warn when no heartbeat is received. Use the full command, you need to run. Example: `curl https://monitoring.example.com/api/push/E9Wzm4lJ2O?status=up&msg=OK&ping=` |
2024-01-04 18:52:05 +01:00
| `niceness` | no | If set, runs any scheduled backup with given [niceness-value ](https://en.wikipedia.org/wiki/Nice_(Unix )). On Linux -20 is highest priority, 0 default and 19 is lowest priority. 10 is a common low priority assigned to backup routines on production systems. |
2020-06-05 09:01:36 +02:00
2020-11-12 14:40:15 +01:00
Example:
```yaml
restic_backups:
2020-11-13 10:01:05 +01:00
data:
name: data
2022-10-06 12:55:36 +02:00
repo: remote
2020-11-12 14:40:15 +01:00
src: /path/to/data
scheduled: true
2021-06-15 19:48:23 +02:00
schedule_oncalendar: '*-*-* 01:00:00'
2021-10-26 15:46:31 +02:00
database:
name: database
2022-10-06 12:55:36 +02:00
repo: remote
2021-10-26 15:46:31 +02:00
stdin: true
stdin_cmd: pg_dump -Ubackup db_name
stdin_filename: db_name_dump.sql
scheduled: true
schedule_oncalendar: '*-*-* 01:30:00'
2024-01-04 18:52:05 +01:00
niceness: 10
2024-01-04 19:47:04 +01:00
all_databases:
name: all_databases
repo: remote
src: /var/dumped_data
scheduled: true
schedule_oncalendar: '*-*-* 02:00:00'
pre_backup_cmd: cd /var/dumped_data & & mariadb -N -e 'show databases' | while read dbname; do mariadb-dump --complete-insert --routines --triggers --single-transaction "$dbname" > "$dbname".sql; done
2024-01-26 15:45:44 +01:00
2020-11-12 14:40:15 +01:00
```
2020-11-13 10:01:05 +01:00
> You can also specify restic_backups as an array, which is a legacy feature and
> might be deprecated in the future. currently, the name key is used for
2024-09-19 21:30:53 +02:00
> naming the access and backup files
2020-11-13 10:01:05 +01:00
2020-06-05 09:01:36 +02:00
#### Exclude
the `exclude` key on a backup allows you to specify multiple files to exclude or
files to look for filenames to be excluded. You can specify the following keys:
```yaml
exclude:
2022-09-12 09:16:24 +02:00
exclude_caches: true
2020-06-05 09:01:36 +02:00
exclude:
- /path/to/file
iexclude:
- /path/to/file
exclude_file:
- /path/to/file
exclude_if_present:
- /path/to/file
```
Please refer to the use of the specific keys to the
2020-06-05 09:04:03 +02:00
[documentation ](https://restic.readthedocs.io/en/latest/040_backup.html#excluding-files ).
2019-08-12 17:08:26 +02:00
## Dependencies
2024-09-19 21:30:53 +02:00
This role does not have any other ansible role as dependency.
2022-04-01 11:00:22 +02:00
2019-08-12 17:08:26 +02:00
## Example Playbook
```yml
2022-04-01 11:00:22 +02:00
- name: backup your homefolders to /mnt/backup everyday night
hosts: localhost
2019-08-12 17:08:26 +02:00
roles:
2022-04-01 11:00:22 +02:00
- {role: do1jlr.restic, tags: restic}
vars:
restic_create_schedule: true
restic_repos:
local:
location: '/mnt/backup'
password: 'ChangM3'
init: true
restic_backups:
home:
name: home
repo: local
src: /home/
scheduled: true
schedule_oncalendar: '*-*-* 01:00:00'
2019-08-12 17:08:26 +02:00
```
## License
2021-03-23 16:22:10 +01:00
This project is under the MIT License. See the [LICENSE ](LICENSE ) file for the full license text.
