Restic Backup: Ilipat ang VPS Data sa Ibang Server

Bakit hindi backup ang backup na nasa parehong server

Ang Restic ay isang libre at open source na backup tool na nagpapadala ng encrypted at deduplicated na snapshots ng iyong mga file sa isang repository sa ibang lokasyon: ikalawang VPS, machine sa bahay, o S3-compatible object storage. Sa guide na ito, ise-set up ito sa Ubuntu 24.04, mula sa pag-install hanggang sa repository gamit ang SFTP, unang backup, nightly systemd timer, retention policy, at restore drill na nagpapatunay na gumagana ang buong proseso. Kailangang ibang machine ang destination, dahil mamamatay kasama ng server ang kopyang nasa parehong server.

Ang backup/ directory sa server na bina-back up nito ay nagpoprotekta sa iyo laban sa isang bagay lamang: hindi sinasadyang pagbura ng file. Hindi ito makakaligtas sa pagkasira ng disk, dahil nasa disk ding iyon ang kopya. Hindi ito makakaligtas sa attacker na may root access, dahil buburahin muna nila ang mga kopya. Hindi rin ito makakaligtas sa maling account action na nag-aalis mismo sa VPS. Binibiro ng pinakawalang-kahusayang datacenter sa mundo ang isang tarball na pinangalanang backup_final_v2_REAL na nasa parehong array ng data, at tumatama ang biro dahil marami sa atin ang nakagawa na ng eksaktong ganoon. Ang rule ay dapat nasa labas ng server ang kopya, at ang restic ang isa sa pinakamadaling paraan para sundin ito.

Restic sa apat na ideya

Repository. Ito ang lugar kung saan nagsusulat ang restic. Isa itong directory na nasa sariling format ng restic at puno ng mga naka-encrypt na blob; restic lamang ang makakabasa nito. Huwag itong i-edit nang mano-mano. Gamitin ang mga command ng restic at ang -r address para makipag-ugnayan dito.

Snapshot. Isa itong kopya ng mga file na bina-back up sa isang partikular na oras. Bawat backup run ay gumagawa ng snapshot. Maaaring i-restore nang hiwalay ang bawat snapshot, at kumikilos ang bawat isa na parang kumpletong kopya ng iyong data sa oras na iyon.

Deduplication. Hinahati ng restic ang mga file sa mga chunk na tinutukoy batay sa content at ina-upload lamang ang mga chunk na hindi pa nakita ng repository. Sa unang backup, lahat ay ina-upload. Sa bawat kasunod na run, humigit-kumulang ang nagbago lamang ang ina-upload. Kung 50 MB ang nagbago sa isang nightly snapshot na 20 GB, humigit-kumulang 50 MB ang magagastos sa storage. Ito ang dahilan kung bakit mura ang pagpapanatili ng dose-dosenang snapshot.

Encryption by default. Palaging naka-encrypt ang restic repository gamit ang AES-256, at kailangan ng password ng repository sa bawat command. Mga naka-encrypt na blob lamang ang nakikita ng backup host o storage provider. Ang mahirap na resulta: kapag nawala ang password, tuluyan nang mawawala ang data, ayon sa disenyo ng system. Magtabi ng kopya ng password sa isang lugar na hindi ang server na ito. Mahalaga ito kaya babanggitin pa ito nang dalawang beses sa ibaba.

I-install ang restic sa Ubuntu 24.04

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

Sa Ubuntu 24.04, ini-install nito ang restic 0.16.4, habang ang kasalukuyang upstream release ay 0.19.1. May ganitong agwat dahil ni-freeze ng isang LTS (long term support) release ang mga package version nito. Hindi ito mahalaga rito dahil sapat na ang 0.16.4 para sa lahat ng nasa guide na ito. Kung gusto mo ang pinakabagong release para sa mga speed improvement nito, 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 iba pang kailangan para sa restic install.

Gawin ang repository sa ibang server gamit ang SFTP

Kailangan mo ng destination machine: karaniwang sapat na ang pangalawang maliit na VPS, at gagana ang anumang machine na may SSH server at libreng disk space. Sinusuportahan ng Restic ang SFTP (file transfer over SSH), kaya walang kailangang i-install sa backup host. Sa gabay na ito, ang backup host ay 10.0.0.12 at ang user ay restic. Huwag pangalanan ang user na backup: may reserved system account na backup (uid 34, walang login shell) ang Ubuntu at Debian sa bawat installation, kaya mabibigo ang adduser backup at mapupunta ang ssh backup@... sa nologin.

Ang nightly job ay tatakbo bilang root sa server na bina-back up, kaya kailangan ng root ng key login papunta sa backup host. Gumawa ng dedicated key na walang passphrase, dahil walang taong magta-type nito nang 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 key, ipinapaliwanag sa Mga pangunahing kaalaman sa SSH key management ang model, mga permission, at kung paano mag-revoke ng key sa susunod.

Sunod, gawin ang repository password. Bumuo ng malakas na password at ilagay ito sa file na root-only:

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

I-copy na ngayon ang password sa password manager mo bago magpatuloy. Kapag nasira ang VPS na ito, maibabalik ng repository kasama ang password ang lahat; walang maibabalik kung repository lang ang mayroon at 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. Ito ang tamang piliin kung ayaw mong magpatakbo ng pangalawang machine. Pareho ang paraan ng paggamit sa anumang S3-compatible bucket; ang address at dalawang credential variable lang ang nagbabago:

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

Magkapareho ang lahat pagkatapos ng init para sa dalawang destination. Ipinapakita ng natitirang bahagi ng gabay na ito ang SFTP address; palitan ito ng address mo.

Unang backup, kasama ang mga exclude

I-backup ang data na hindi mo basta mai-reinstall, hindi ang buong filesystem. Maibabalik ang operating system sa pamamagitan ng reinstall; hindi ganoon ang iyong configuration at data. Para sa karaniwang VPS, kabilang dito ang /etc, /home, at ang mga lokasyong pinag-iimbakan ng state ng iyong mga application, gaya ng /srv o /var/www. I-exclude ang mga cache dahil malalaki ang mga ito, araw-araw nagbabago, at awtomatikong 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

Sa unang run, ia-upload ang lahat kaya magtatagal ito. Patakbuhin muli ang parehong command at matatapos ito sa loob ng ilang segundo. Mag-uulat ito ng ilang nabagong file at ilang MiB na nadagdag dahil ang deduplication ay nag-a-upload lamang ng mga bagong chunk. Ilista ang mga mayroon ka:

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

Ipinapakita ng bawat snapshot ang ID, oras, at mga path na nilalaman nito. Ang mga ID na iyon ang gagamitin mo sa pag-restore.

Nightly run gamit ang systemd timer

Nakakasawa nang i-type ang repository address sa bawat command, at ang backup na mano-mano mong pinapatakbo ay kadalasang hindi na naisasagawa paglipas ng isang buwan. Nalulutas ang dalawang problemang ito gamit ang isang script at isang timer. Itinatakda ng script ang dalawang environment variable na binabasa ng restic, RESTIC_REPOSITORY at RESTIC_PASSWORD_FILE, kaya 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

Ipapaliwanag ang mga linyang forget at check sa susunod na dalawang seksyon. Ngayon naman ang schedule: isang oneshot service na nagpapatakbo ng script, at isang timer na nagpapatakbo nito gabi-gabi nang 03:00. Mas angkop dito ang timer kaysa cron line dahil itinatala sa journal ang run, at awtomatikong pinapatakbo ng Persistent=true ang na-miss na backup sa sandaling muling maging available ang server matapos ang 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 nang isang beses ang service nang mano-mano at i-monitor ang takbo 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 run. Maaari mo ring i-generate ang pares ng unit file sa halip na mano-manong i-type ang mga ito:

Makikita ang buong pattern sa likod ng dalawang file na ito, kabilang ang calendar syntax at mga hardening directive na maaaring taglayin ng isang service, sa pagpapatakbo ng program bilang systemd service sa VPS.

Ang backup ay hinala lamang hangga’t hindi mo ito nare-restore

Ituring ang pangungusap na ito bilang utos. Ang backup job na matagumpay na tumatakbo gabi-gabi ay nagpapatunay lamang na tumakbo ang job; hindi nito pinatutunayang maibabalik ang data mo. Dalawang pagsusuri ang tumutugon sa agwat na ito.

Una, restic check, na pinapatakbo na ng script gabi-gabi. Vine-verify nito ang structure ng repository at ang index, kaya mahuhuli ang tahimik na corruption sa backup host sa susunod na gabi, sa halip na sa araw ng restore. Minsan bawat buwan, patakbuhin ang mas masusing bersyon, na nagda-download at cryptographically nagve-verify ng random na ikasampung bahagi ng aktuwal 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 pag-run, unti-unting nasusuri ng mga monthly run ang buong repository nang hindi kailanman kailangang mag-download ng buong repository.

Ikalawa, ang restore drill. Habang nasa root shell ka pa mula sa naunang hakbang, i-restore ang isang aktuwal na directory mula sa pinakabagong snapshot papunta sa scratch location at ikumpara ito sa live files:

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

Ang diff na walang inilalabas na output ay nangangahulugang eksaktong magkapareho ang bawat byte pagkatapos ng restore. Iyon lamang ang ebidensiyang mahalaga. Pagkatapos, i-delete ang /srv/restore-drill. Gawin ang drill na ito buwan-buwan. Minsan o dalawang beses bawat taon, gawin ang buong bersyon: i-restore ang buong pinakabagong snapshot sa isang scratch VPS at tiyaking aktuwal na nagsisimula ang application mula rito. Kapag kailangan mong gumana ito sa ilalim ng pressure, dapat isa na itong routine na nagawa mo na.

Retention: forget at prune

Kung walang retention policy, patuloy na maiipon ang snapshots at patuloy ding lalaki ang repository. Inilalapat ng forget line ng script ang policy gabi-gabi: pinananatili ng --keep-daily 7 ang isang snapshot bawat araw sa nakalipas na pitong araw, --keep-weekly 4 ang isang snapshot bawat linggo sa loob ng apat na linggo, at --keep-monthly 6 ang isang snapshot bawat buwan sa loob ng anim na buwan. Ang lahat ng snapshot na hindi protektado ng isang rule ay ifo-forget.

Ang forget ay nag-aalis lamang ng mga record ng snapshot; nananatili ang mga data chunk sa repository hanggang may mag-delete sa mga ito. Iyon ang ginagawa ng --prune: hinahanap nito ang mga chunk na wala nang reference mula sa anumang natitirang snapshot at dine-delete ang mga ito. Sa puntong iyon aktuwal na nababawi ang disk space. Ang prune ay nagsasagawa ng aktuwal na repository work, kaya sa malalaking repository, pinapatakbo ito ng ilang user gabi-gabi gamit ang forget at lingguhan gamit ang --prune; sa karaniwang VPS sizes, ayos na ang nightly run.

Mga Database: gumawa muna ng dump, saka i-back up ang dump

Kinokopya ng Restic ang mga file habang binabasa nito ang mga ito, at patuloy na nagsusulat ang database sa mga file nito. Kapag nakopya ang isang live database file habang may isinusulat, mare-restore ito bilang corrupt na database dahil pinaghahalo ng kopya ang mga page bago at pagkatapos ng write. Ang karaniwang solusyon ay ipagawa sa database engine ang consistent na export sa isang file, saka ipa-back up sa restic ang file na iyon.

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

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

Ginagampanan ng mysqldump ang parehong tungkulin para sa MariaDB at MySQL. Para sa kumpletong halimbawa ng pattern na ito, ino-on ng section ng backup para sa Nextcloud ang maintenance mode, gumagawa ng dump ng Postgres, at kinokopya ang mga file bilang isang consistent na set—ang eksaktong set na dapat ilipat ng restic palabas ng server bawat gabi. Pareho ang ideya sa SQLite, pero mas simple: pinatitigil ng guide para sa Vaultwarden ang container nang ilang segundo upang makagawa ng cold copy ng db.sqlite3, at ang archive na iyon ang ipinapadala ng restic palabas ng server.

FAQ

Naka-encrypt ba ang mga backup ng restic?

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 nag-iimbak ng repository ay encrypted blobs lamang ang hawak, kaya hindi inilalantad ng isang breached na backup host ang iyong mga file. Walang kompromiso rito: kung wala ang password, walang makakabawi ng data. Kaya mag-imbak ng kopya nito sa labas ng server.

Gumagawa ba ang restic ng incremental backup?

Kumikilos na parang full backup ang bawat restic snapshot, pero incremental ang storage cost. Hinahati ng restic ang mga file sa chunks at ina-upload lamang ang mga chunk na wala pa sa repository. Kaya sa nightly run, karaniwang ang mga pagbabago lang sa araw na iyon ang naililipat. Hindi tulad ng tradisyonal na incremental scheme, walang chain na kailangang i-replay. Direktang nari-restore ang anumang snapshot, at hindi nasisira ang mas bagong snapshot kapag nag-delete ng lumang snapshot.

Paano ako magre-restore ng mga file mula sa restic backup?

Patakbuhin ang restic snapshots para hanapin ang snapshot ID, pagkatapos ay ang restic restore <id> --target /some/empty/dir para i-restore ito. Idagdag ang --include /path para isang bahagi lamang nito ang i-restore. Maaaring gamitin ang latest bilang kapalit ng ID. Muling ginagawa 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. Subukan ito bago mo ito kailanganin, dahil ang backup na hindi pa nasusubukan ay palagay lamang.

Gaano kadalas dapat patakbuhin ang restic backup?

Ang nightly backup ang praktikal na minimum para sa isang server, at pinapamura ito ng deduplication: sa bawat run, ang mga chunk lamang na nagbago mula sa huling run ang ina-upload. Ang data na mabilis magbago, o data na malaking problema kapag nawala kahit isang araw, ay maaaring i-backup bawat ilang oras gamit ang parehong timer pattern. Madali lamang ang pagtatakda ng frequency. Regular ding patakbuhin ang restic check at magsagawa ng restore drill bawat buwan, dahil walang saysay ang schedule kung hindi ito vine-verify.

Ano ang mangyayari kung mawala ang restic repository password ko?

Hindi na mare-recover ang mga backup. Walang back door o reset ang encryption ng restic, kaya kasinghalaga ng mga backup mismo ang password. Mag-imbak ng kopya nito sa password manager at sa iba pang matibay na lokasyon na hindi ang server na bina-backup. Habang may access ka pa, maaaring gamitin ang restic key add para mag-register ng pangalawang password para sa parehong repository. Magbibigay ito sa iyo ng ekstrang password.