Paano gamitin ang Restic para sa VPS backup

Bakit hindi backup ang backup na nasa parehong server

Ang Restic ay isang free at open source na backup tool. Nagpapadala ito ng encrypted at deduplicated na snapshots ng iyong mga file sa isang repository sa ibang lokasyon: isang pangalawang VPS, isang machine sa bahay, o S3-compatible object storage. Ituturo sa gabay na ito ang pag-setup nito sa Ubuntu 24.04. Sakop nito ang installation hanggang sa repository via SFTP, ang unang backup, nightly systemd timer, retention policy, at ang restore drill para mapatunayan na gumagana ang lahat. Dapat ay ibang machine ang destination, dahil ang kopya na nasa parehong server ay mawawala rin kapag nasira ang server.

Ang isang backup/ directory sa mismong machine na bina-backup ay proteksyon lamang laban sa isang bagay: ang aksidenteng pag-delete ng file. Hindi ito makakaligtas sa failed disk, dahil nasa disk na iyon ang kopya. Hindi rin ito makakaligtas sa attacker na may root access, dahil uunahin nilang i-delete ang mga kopya. Hindi rin ito makakaligtas sa pagkakamali sa account na nagreresulta sa pagka-delete ng mismong VPS. The world's least efficient datacenter ang biro tungkol sa isang tarball na may pangalang backup_final_v2_REAL na nasa parehong array gaya ng data, at nakakatawa ito dahil marami sa atin ang nakagawa na nito. Ang panuntunan ay dapat nasa labas ng machine, at ang restic ang pinakamadaling paraan para masunod ito.

Apat na konsepto ng restic

Repository. Ang lugar kung saan nagsusulat ang restic. Isa itong directory na nasa format ng restic, puno ng mga encrypted blobs, at restic lamang ang makakabasa nito. Huwag itong i-edit nang manual; gamitin ang restic commands at ang -r address para makipag-ugnayan dito.

Snapshot. Isang point-in-time na larawan ng mga files na iyong i-back up. Ang bawat backup run ay gumagawa ng snapshot. Ang bawat snapshot ay maaaring i-restore nang mag-isa, at ang bawat isa ay nagsisilbing kumpletong kopya ng iyong data sa partikular na oras na iyon.

Deduplication. Hinahati ng restic ang mga files sa content-defined chunks at i-a-upload lamang ang mga chunk na wala pa sa repository. I-a-upload ng unang backup ang lahat; ang mga susunod na run ay i-a-upload lamang ang mga bahaging nagbago. Ang nightly snapshot na 20 GB kung saan 50 MB lang ang nagbago ay kakain lamang ng halos 50 MB, kaya mura ang pagtatabi ng maraming snapshots.

Encryption by default. Ang restic repository ay laging encrypted (AES-256), at kailangan ng bawat command ang repository password. Ang backup host o ang storage provider ay makakakita lamang ng mga encrypted blobs. Ang direktang epekto nito: kapag nawala ang password, permanenteng mawawala ang data dahil sa disenyo nito. Itabi ang kopya ng password sa lugar na hindi ito server. Mahalaga ito kaya babanggitin itong muli sa ibaba.

Install restic sa Ubuntu 24.04

sudo apt update && sudo apt install -y restic
restic version

Sa Ubuntu 24.04, ang version na naka-install ay restic 0.16.4, habang ang current upstream release ay 0.19.1. Ang pagkakaibang ito ay dahil ang mga LTS (long term support) release ay nagfi-freeze ng kanilang mga package version. Hindi ito magiging problema dahil kayang gawin ng 0.16.4 ang lahat ng nasa guide na ito. Kung kailangan mo ang pinakabagong release para sa speed improvements, i-download ang official single-binary build mula sa GitHub releases page ng restic project. I-unpack ito gamit ang bunzip2, at i-install sa /usr/local/bin/restic; wala nang ibang kailangang gawin para sa restic install.

Gumawa ng repository sa ibang server gamit ang SFTP

Kailangan mo ng destination machine: karaniwang sagot ang pangalawang maliit na VPS, pero kahit anong box na may SSH server at bakanteng disk ay pwede. Gumagamit ang Restic ng SFTP (file transfer over SSH), kaya hindi kailangang mag-install ng kahit ano sa backup host. Sa guide na ito, ang backup host ay 10.0.0.12 na may user na restic. Huwag gamitin ang pangalang backup para sa user na iyon: ang Ubuntu at Debian ay may reserved system account na backup (uid 34, no login shell) sa bawat install, kaya mag-eerror ang adduser backup at mapupunta ang ssh backup@... sa nologin.

Ang nightly job ay tatakbo bilang root sa server na bina-backup, kaya kailangan ng root ang key login sa backup host. Gumawa ng dedicated key na walang passphrase, dahil walang tao na magta-type nito ng 3am, at i-copy ito:

sudo ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519 -N "" -C "web1-restic"
sudo ssh-copy-id -i /root/.ssh/id_ed25519.pub restic@10.0.0.12
sudo ssh restic@10.0.0.12 true && echo key login works

Kung bago sa iyo ang mga keys, ipinapaliwanag ng SSH key management basics ang model, ang mga permissions, at kung paano mag-revoke ng key sa hinaharap.

Susunod ay ang repository password. Mag-generate ng malakas na password sa isang file na para sa root lamang:

openssl rand -base64 32 | sudo tee /root/.restic-password
sudo chmod 600 /root/.restic-password

I-copy na ang password na iyon sa iyong password manager bago magpatuloy. Kapag nasira ang VPS na ito, maibabalik ang lahat gamit ang repository at ang password na ito; walang maibabalik ang repository kung wala ang password.

I-initialize ang repository:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password init

created restic repository 9f3c2a1b0d at sftp:restic@10.0.0.12:/srv/restic/web1

Ang alternatibong destination ay S3-compatible object storage, na tamang piliin kung ayaw mong magpatakbo ng pangalawang machine. Ang anumang S3-compatible bucket ay gumagana sa parehong paraan; ang address at dalawang credential variables lamang ang magbabago:

export AWS_ACCESS_KEY_ID=your-key-id
export AWS_SECRET_ACCESS_KEY=your-secret-key
sudo -E restic -r s3:https://s3.example.com/web1-backups --password-file /root/.restic-password init

Ang lahat pagkatapos ng init ay pareho para sa dalawang destination. Ang natitirang bahagi ng guide na ito ay nagpapakita ng SFTP address; palitan ito ng sa iyo.

Ang unang backup, kasama ang mga excludes

I-back up lamang ang mga data na hindi pwedeng i-reinstall, hindi ang buong filesystem. Maaaring maibalik ang operating system sa pamamagitan ng reinstall; ang iyong configuration at data ay hindi. Para sa isang tipikal na VPS, ibig sabihin nito ay ang /etc, /home, at kung saan nakaimbak ang state ng iyong mga application, gaya ng /srv o /var/www. I-exclude ang mga cache dahil malaki ang size ng mga ito, mabilis magbago araw-araw, at kusa namang nabubuo muli:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password backup /etc /home /srv --exclude '/home/*/.cache'

Files:        4181 new,     0 changed,     0 unmodified
Added to the repository: 731.204 MiB (312.418 MiB stored)
snapshot 5b8a3f2c saved

I-uupload ng unang run ang lahat ng files, kaya matatagalan ito. Patakbuhin muli ang parehong command at matatapos ito sa loob ng ilang segundo. Magre-report ito ng ilang files na nagbago at ilang MiB na nadagdag, dahil ang deduplication ay nag-uupload lamang ng mga bagong chunk. I-list ang iyong mga backup:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password snapshots

Ang bawat snapshot ay nagpapakita ng ID, oras, at ang mga path na nakapaloob dito. Ang mga ID na ito ang gagamitin para sa pag-restore.

Nightly runs gamit ang systemd timer

Nakakapagod ang pag-type ng repository address sa bawat command, at ang backup na manual ang pagtakbo ay madalas nakakalimutang gawin pagkalipas ng isang buwan. Malulutas ang dalawang problemang ito gamit ang isang script at isang timer. Itinatakda ng script ang dalawang environment variables na binabasa ng restic, ang RESTIC_REPOSITORY at RESTIC_PASSWORD_FILE, para manatiling maikli ang bawat command sa loob nito:

sudo nano /usr/local/bin/restic-backup.sh

#!/usr/bin/env bash
set -euo pipefail
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password

restic backup /etc /home /srv --exclude '/home/*/.cache'
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check

sudo chmod 700 /usr/local/bin/restic-backup.sh

Ang mga linya ng forget at check ay ipinapaliwanag sa susunod na dalawang seksyon. Para sa schedule: isang oneshot service na nagpapatakbo ng script, at isang timer na nagti-trigger nito tuwing 03:00 gabi-gabi. Mas mainam ang timer kaysa sa cron line dito dahil ang logs ng takbo ay napupunta sa journal, at ang Persistent=true ay nagpapatakbo ng missed backup sa oras na bumalik ang server pagkatapos ng downtime.

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Nightly restic backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/restic-backup.sh

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Run the nightly restic backup

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target

I-enable ang timer, pagkatapos ay patakbuhin ang service nang manual nang isang beses para i-verify ang paggana nito:

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
sudo journalctl -u restic-backup.service -f

Ipinapakita ng systemctl list-timers kung kailan ang susunod na takbo. Maaari ring i-generate ang pares ng unit files sa halip na i-type ang mga ito nang manual:

Ang buong pattern sa likod ng dalawang file na ito, kasama ang calendar syntax at ang mga hardening directive na maaaring gamitin ng isang service, ay matatagpuan sa running a program as a systemd service on a VPS.

Ang backup ay sabi-sabi lamang hangga't hindi ito nare-restore

Ituring ang pangungusap na ito bilang isang utos. Ang backup job na laging "green" gabi-gabi ay nagpapatunay lamang na tumakbo ang job; hindi nito pinapatunayang maibabalik ang iyong data. Dalawang check ang kailangan para punan ang kakulangang ito.

Una, ang restic check, na kasalukuyan nang pinapatakbo ng script gabi-gabi. Sinusuri nito ang repository structure at ang index, kaya ang silent corruption sa backup host ay mahuhuli sa susunod na gabi sa halip na sa araw ng restore. Minsan sa isang buwan, patakbuhin ang mas malalim na bersyon, na nagda-download at nagve-verify ng cryptographic integrity sa random na 1/10 ng aktwal na data:

sudo -i
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic check --read-data-subset=10%

Dahil random ang subset sa bawat pagkakataon, unti-unting masasakop ng monthly runs ang buong repository nang hindi nangangailangan ng full download.

Pangalawa, ang restore drill. Gamit ang root shell mula sa itaas, i-restore ang isang totoong directory mula sa pinakabagong snapshot sa isang scratch location at i-compare ito sa live files:

restic restore latest --target /srv/restore-drill --include /etc/ssh
diff -r /etc/ssh /srv/restore-drill/etc/ssh

Kapag walang pinakita ang diff, ibig sabihin ay identical ang bawat byte na naibalik, na siyang tanging ebidensyang mahalaga. I-delete ang /srv/restore-drill pagkatapos. Gawin ang drill na ito buwan-buwan, at minsan o dalawang beses sa isang taon, gawin ang full version: i-restore ang buong pinakabagong snapshot sa isang scratch VPS at i-check kung gumagana ang iyong application mula rito. Sa araw na kailangan mo itong gumana sa ilalim ng pressure, dapat ay routine na ito na nagawa mo na dati.

Retention: forget plus prune

Kapag walang policy, patuloy na naiipon ang mga snapshot at lumalaki ang repository. Inilalapat ng forget line ng script ang policy gabi-gabi: ang --keep-daily 7 ay nagtatabi ng isang snapshot bawat araw para sa huling pitong araw, ang --keep-weekly 4 ay isang bawat linggo para sa apat na linggo, at ang --keep-monthly 6 ay isang bawat buwan para sa anim na buwan. Ang lahat ng hindi protektado ng rule ay tatanggalin (forgotten).

Ang forget ay nagtatanggal lamang ng mga snapshot record; ang mga data chunk ay mananatili sa repository hangga't walang nagtatanggal sa mga ito. Ito ang ginagawa ng --prune: hinahanap nito ang mga chunk na wala nang natitirang snapshot reference at tinatanggal ang mga ito, na siyang nagpapabawas sa disk space. Ang prune ay gumagawa ng aktwal na trabaho sa repository, kaya sa malalaking repository, ang ilang user ay nagpapatakbo ng forget gabi-gabi at --prune lingguhan; sa mga tipikal na VPS size, sapat na ang nightly.

Databases: i-dump muna, bago i-back up ang dump

Kinokopya ng restic ang mga file habang binabasa ang mga ito, habang ang database naman ay patuloy na nagsusulat sa mga file nito. Ang live database file na nakopya habang may isinusulat ay magre-restore bilang corrupt na database, dahil ang kopya ay may halong pages mula bago at pagkatapos ng isang write operation. Ang standard na solusyon ay ito: hayaan ang database engine na gumawa ng consistent na export sa isang file, pagkatapos ay i-back up ng restic ang file na iyon.

Para sa PostgreSQL, magdagdag ng dump line sa itaas ng restic-backup.sh, bago ang restic backup command, at isama ang dump directory sa mga backup paths:

mkdir -p /var/backups/db
sudo -u postgres pg_dump myapp | gzip > /var/backups/db/myapp.sql.gz

Ginagawa rin ng mysqldump ang parehong papel para sa MariaDB at MySQL. Para sa isang halimbawa ng buong pattern, ang Nextcloud backup section ay nag-o-on ng maintenance mode, nag-di-dump ng Postgres, at kinokopya ang mga file bilang isang consistent na set, ang eksaktong set na dapat i-back up ng restic gabi-gabi. Ang SQLite ay may parehong konsepto pero mas simple: ang Vaultwarden guide ay ititigil ang container ng ilang segundo para kumuha ng cold copy ng db.sqlite3, at ang archive na iyon ang i-shi-ship ng restic palabas ng server.

FAQ

Encrypted ba ang mga restic backup?

Oo, palagi. Ang bawat restic repository ay naka-encrypt gamit ang AES-256. Walang unencrypted mode, at kailangan ang repository password sa bawat command. Ang machine o provider na nagtatago ng repository ay may hawak lamang na mga encrypted blobs, kaya hindi malalantad ang iyong mga file kahit ma-compromise ang backup host. Ang trade-off ay absolute: hindi mababawi ang data ng kahit sino nang walang password, kaya magtabi ng kopya nito malayo sa server.

Gumagawa ba ang restic ng incremental backups?

Ang bawat restic snapshot ay kumikilos na parang full backup, pero incremental lang ang gastos sa storage. Hinahati ng restic ang mga file sa mga chunk at i-a-upload lang ang mga chunk na wala pa sa repository, kaya ang nightly run ay naglilipat lamang ng mga nagbago sa araw na iyon. Hindi tulad ng mga tradisyunal na incremental scheme, walang chain na kailangang i-replay: ang anumang snapshot ay direktang nare-restore at ang pagbura sa lumang snapshot ay hindi makakasira sa mas bago.

Paano mag-restore ng mga file mula sa restic backup?

Gamitin ang restic snapshots para mahanap ang snapshot ID, pagkatapos ay gamitin ang restic restore <id> --target /some/empty/dir para i-restore ito, at idagdag ang --include /path kung bahagi lang ang gustong i-restore. Maaaring gamitin ang latest bilang kapalit ng ID. Re-recreate ng restic ang orihinal na directory structure sa ilalim ng target, kaya ang pag-restore ng /etc/ssh ay mapupunta sa /some/empty/dir/etc/ssh. Sanayin ito bago mo pa kailanganin, dahil ang backup na hindi na-test ay isang sabi-sabi lamang.

Gaano kadalas dapat patakbuhin ang restic backup?

Ang nightly run ang pinaka-praktikal na minimum para sa isang server, at mura ito dahil sa deduplication: ang bawat run ay nag-a-upload lang ng mga chunk na nagbago mula sa huling run. Para sa data na mabilis magbago, o sa data na kritikal kahit isang araw lang ang mawala, maaaring patakbuhin ito kada ilang oras gamit ang parehong timer pattern. Madali ang frequency; dapat din magpatakbo nang regular ng restic check at mag-restore drill buwan-buwan, dahil ang schedule na walang verification ay huwad na kapanatagan.

Ano ang mangyayari kung mawala ang aking restic repository password?

Hindi na mababawi ang mga backup. Ang encryption ng restic ay walang back door at walang reset, kaya ang password ay kasing-halaga ng mismong mga backup. Magtabi ng kopya sa iyong password manager o sa anumang matibay na storage na hiwalay sa backed-up server. Habang may access ka pa, maaaring mag-register ang restic key add ng pangalawang password para sa parehong repository, na magsisilbing spare mo.