In a previous article I already described how to use autorestic to backup a server to a Hetzner Storagebox. Since then I have configured several Cloudron installations to use this method and would like to give some recommendations on the backup and restore process using this mechanism.
Backing up Link to heading
For the backup, I use the autoresponder configuration below, triggered by its native [cron implementation] (https://autorestic.vercel.app/location/cron#installing-the-cron):
version: 2
locations:
home:
from: /root
to: storagebox
#forget: "prune"
cron: '30 */3 * * *'
cloudron-backup:
from: /var/backups
to: storagebox
#forget: "prune"
cron: '30 */3 * * *'
cloudron-appsdata:
from: /home/yellowtent/appsdata
to: storagebox
#forget: "prune"
cron: '30 */3 * * *'
cloudron-boxdata:
from: /home/yellowtent/boxdata
to: storagebox
#forget: "prune"
cron: '30 */3 * * *'
options:
backup:
exclude:
- '*.log'
backends:
storagebox:
type: sftp
path: storagebox:restic
key: xxx
options:
forget:
keep-last: 15
keep-daily: 14
keep-weekly: 52
keep-monthly: 12
keep-yearly: 7
In the configuration above, I make separate backups of /root (where the autorestic and ssh configuration is stored, as well as small helper scripts) and /var/backups (the folder Cloudron writes its backup to).
For good measure, I also make backups of the file mounts of the individual applications (/home/yellowtent/appsdata) and Cloudron services (/home/yellowtent/boxdata), which should give me the best coverage for restoring individual files and applications.
The configuration inside Cloudron looks like this:
In the Cloudron UI, this results in a scary looking warning message:
Cloudron backups are currently on the same disk as the Cloudron server instance. This is dangerous and can lead to complete data loss if the disk fails.
However, as we are using autorestic to write these folders to an external destination, we are in the safe zone and the only risk we really face is that if we run out of disk space, this will happen to our main production data as well as our local backup directory.
Day of the migration Link to heading
If a Cloudron needs to be moved from one host to another, or restore should be performed as a dry-run. The following steps can be performed:
- on the old host, manually trigger a backup within Cloudron
- once this backup is complete, download the backup configuration
- and run autorestic to perform a last backup of the Cloudron backup directory:
autorestic -v backup -l cloudron-backup
- afterwards the old Cloudron can be shut down
Preparing the restore Link to heading
The first thing we need to do on the new server is install autorestic and copy the ssh and autorestic configuration from the old host to the new one. Once connected to the storagebox, we can do a selective restore before running the Cloudron restore:
autorestic -v restore -l cloudron-backup --to /var/backups latest:/var/backups --include 2024-01-02-203000-999
Where 2024-01-02-203000-999 is the remotePath as shown in the previously downloaded cloudron-backup-config-2024-01-02-14-30-00 (my.cloudron.domain).json.
Once this command has been completed, we can follow the official instructions on Restoring Cloudron to restore our Cloudron from the snapshot located at /var/backups/2024-01-02-203000-999.
Maintenance Link to heading
To forget and prune old backup sets, autorestic can be configured with an additional cron job. To do this, simply run the following command once a day:
autorestic forget -a -v --prune
Happy backup & restore!