restic-backup-suite: Restore
Restoring with restic-restore: choose a snapshot, menu options, temporary restore directory, importing SQL dumps, SSL certificates and known limitations of the database import.
Restore
sudo restic-restore [--config FILE] [--snapshot ID]
restore.sh restores files from a snapshot into a temporary directory. It does not overwrite anything on the running system (exception: the database import, see below).
Sequence
- Choose a snapshot. With
--snapshot IDthe prompt is skipped, otherwise the script showsrestic snapshotsand asks for an ID orlatest. - The script creates
/tmp/restic-restore-XXXXXX(mode 700). - Choose a menu item. The script performs exactly one action and then ends.
- Review the files in the restore directory and copy them to their destination yourself. You delete the directory by hand afterwards (
rm -rf), the script does not clean it up.
The files sit under their original path inside the restore directory, so /etc/nginx ends up in /tmp/restic-restore-XXXXXX/etc/nginx.
The restore directory is under
/tmp. Large restores need enough space there.
Menu
| Choice | Action |
|---|---|
1 |
Restore the complete snapshot |
2 |
/var/www |
3 |
/etc |
4 |
/home |
5 |
Select and import database dumps |
6 |
/etc/letsencrypt, followed by the steps to apply it (stop the certbot timer, copy, set ownership, start the certbot timer, reload the web server) |
7 |
Any path you enter |
q |
Cancel, the empty restore directory is deleted |
Items 2 to 4 and 6 are hard-wired paths. They only work if that path is part of the snapshot (that is, it was in BACKUP_PATHS).
Importing database dumps
Item 5 searches the snapshot for the directory /tmp/restic-db-dump-* (alternatively /tmp/mysql_backup), restores it and lists the .sql files. You choose one or more numbers, or a for all. For each file the script asks which database to import into, creates it with CREATE DATABASE IF NOT EXISTS if needed and imports the dump with the local mysql client.
The import runs directly against the local MySQL/MariaDB server and uses the
mysqlclient without credentials. That is not the database container the dump came from.
The import replaces existing tables of the target database. Dumps created with
mysqldumpormariadb-dumpcontainDROP TABLEstatements by default, so existing tables of the same name are lost.
Known limitations:
- The suggested database name is the part of the file name after the last underscore.
wikijs-db_mm_faq.sqlbecomesfaq, notmm_faq. Witha(all) there is no way to change the name. For names containing an underscore, pick files individually and type the name. - The script does not distinguish MySQL from PostgreSQL dumps. PostgreSQL dumps show up in the list but cannot be imported with
mysql. Import them manually withpsqlinto the container. - For container databases the safe route is to take the dump from the restore directory and import it into the container yourself, for example
docker exec -i <container> mariadb -u root -p <db> < file.sql.
SFTP prerequisite
restore.sh does not write an SSH configuration. For an sftp: repository the configuration from an earlier backup run (or a manual one) must already exist, see Technical details.
Restoring without the scripts
The repository is a normal restic repository. With RESTIC_REPOSITORY and RESTIC_PASSWORD_FILE you can reach the data without the scripts, for example on a new server with restic restore latest --target /restore. All you need is the repository and the password, see Security.