Jinsi ya kutumia Restic kwenye VPS yako

Kwa nini nakala ya akiba kwenye seva moja siyo nakala ya akiba

Restic ni zana ya bure ya nakala ya akiba (open source) inayotuma snapshots zilizofichwa (encrypted) na zilizofanyiwa deduplication kwenda kwenye sehemu nyingine: VPS ya pili, mashine ya nyumbani, au S3-compatible object storage. Mwongozo huu unaweka mipangilio kwenye Ubuntu 24.04, kuanzia ufungaji hadi kwenye repository kupitia SFTP, nakala ya kwanza, timer ya systemd ya kila usiku, sera ya uhifadhi (retention policy), na mazoezi ya kurejesha (restore) ili kuthibitisha mfumo unaofanya kazi. Sehemu ya kuhifadhia lazima iwe mashine nyingine, kwa sababu nakala inayokaa kwenye seva moja itapotea ikiwa seva hiyo itaharibika.

Directory ya backup/ kwenye mashine inayohifadhiwa inakulinda dhidi ya jambo moja tu: kufuta faili kwa bahati mbaya. Haitasalimika ikiwa diski itafeli, kwa sababu ilikuwa kwenye hiyo diski. Haitasalimika ikiwa mshambuliaji (attacker) ana uwezo wa root, kwa sababu watafuta nakala hizo kwanza. Haitasalimika ikiwa kuna makosa ya akaunti yanayofuta VPS yenyewe. Datacenter isiyo na ufanisi zaidi duniani inatania kuhusu tarball iitwayo backup_final_v2_REAL inayokaa kwenye array ileile kama data, na utani huo unaeleweka kwa sababu watu wengi wametumia mfumo huo. Kanuni ni kuhifadhi nje ya mashine, na restic ndiyo njia rahisi zaidi kuifuata.

Restic katika mawazo manne

Repository. Mahali ambapo restic huandika data. Ni kielelezo cha directory katika mfumo wa restic, kimejaa blobs zilizofichwa (encrypted), na ni restic pekee inayoweza kusoma. Usifanye marekebisho ya mkono kwenye directory hii; tumia amri za restic na anwani ya -r.

Snapshot. Picha ya hali ya faili zako wakati fulani uliyofanya backup. Kila safari ya backup hutengeneza snapshot, kila snapshot inaweza kurejeshwa peke yake, na kila moja inafanya kazi kama nakala kamili ya data yako wakati huo.

Deduplication. Restic hugawanya faili katika vipande (chunks) vilivyofafanuliwa kwa maudhui na kupakia vipande ambavyo repository bado haijaviona. Backup ya kwanza hupakia kila kitu; kila safari inayofuata hupakia kile ambacho kimebadilika. Snapshot ya usiku ya GB 20 ambapo MB 50 zimebadilika hutumia takriban MB 50, ndiyo maana kuhifadhi snapshot nyingi ni gharama nafuu.

Encryption by default. Repository ya restic kila wakati imefichwa (AES-256), na kila amri inahitaji nywila ya repository. Host ya backup au mtoa huduma wa hifadhi ataona tu blobs zilizofichwa. Matokeo yake: ukipoteza nywila, data inapotea kabisa na kwa makusudi. Hifadhi nakala ya nywila mahali ambapo si kwenye seva hii. Jambo hili ni muhimu kiasi kwamba linatajwa mara mbili zaidi hapa chini.

Install restic kwenye Ubuntu 24.04

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

Kwenye Ubuntu 24.04, hii huweka restic 0.16.4, ingawa toleo la sasa la upstream ni 0.19.1. Tofauti hii hutokea kwa sababu toleo la LTS (long term support) hufunga matoleo ya vifurushi vyake, lakini hili halina umuhimu hapa: 0.16.4 hufanya kila kitu kilichopo kwenye mwongozo huu. Ikiwa unataka toleo jipya zaidi kwa ajili ya maboresho ya kasi, pakua faili ya single-binary kutoka kwenye ukurasa wa GitHub releases wa mradi wa restic, ifungue kwa kutumia bunzip2, na uweke kwenye /usr/local/bin/restic; hakuna hatua nyingine ya ziada katika kuweka restic.

Tengeneza repository kwenye server nyingine kupitia SFTP

Unahitaji mashine ya mwisho: VPS ndogo ya pili ndiyo suluhisho la kawaida, na mashine yoyote yenye SSH server na nafasi ya diski inafaa. Restic hutumia SFTP (uhamisho wa faili kupitia SSH), hivyo host ya backup haihitaji kusakinishwa kitu chochote. Katika mwongozo huu, host ya backup ni 10.0.0.12 ikiwa na mtumiaji anayeitwa restic. Usimpe mtumiaji huyo jina la backup: Ubuntu na Debian huweka akaunti ya mfumo iliyohifadhiwa inayoitwa backup (uid 34, haina login shell) kwenye kila usakinishaji, hivyo adduser backup itashindwa na ssh backup@... itaishia kwenye nologin.

Kazi ya usiku itafanya kazi kama root kwenye server inayofanyiwa backup, hivyo root anahitaji kuingia kwa kutumia key kwenye host ya backup. Tengeneza key maalum isiyo na passphrase, kwa sababu hakuna binadamu atakayekuwepo saa 3:00 usiku kuandika passphrase, kisha ihamishe:

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

Kama keys ni mpya kwako, misingi ya usimamizi wa SSH key inaelezea mfumo, ruhusa, na jinsi ya kufuta key baadaye.

Inayofuata ni password ya repository. Tengeneza password yenye nguvu kwenye faili inayofikiwa na root pekee:

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

Sasa nakili password hiyo kwenye password manager yako kabla ya kuendelea zaidi. Ikiwa VPS hii itaharibika, repository pamoja na password hii vitarudisha kila kitu; repository bila password haitarudisha kitu chochote.

Anzisha (Initialise) 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

Njia nyingine ya mwisho ni S3-compatible object storage, ambayo ni chaguo sahihi ikiwa hutaki kuendesha mashine ya pili. Bucket yoyote inayokubali S3 inafanya kazi kwa njia ileile; ni anwani na variable mbili za credentials pekee zinazobadilika:

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

Kila kitu baada ya init ni sawa kwa malengo yote mawili. Sehemu nyingine ya mwongozo huu inaonyesha anwani ya SFTP; badilisha na yako.

Backup ya kwanza, ukitumia mbinu ya kutenga (excludes)

Nakili data ambazo huwezi kuzirejesha kwa kufanya reinstall, usinakili filesystem nzima. Mfumo wa uendeshaji (operating system) unarudi baada ya kufanya reinstall; mipangilio yako na data zako hazirudi. Kwa VPS ya kawaida, hii inamaanisha /etc, /home, na sehemu yoyote programu zako zinapohifadhi hali ya data (state), kama vile /srv au /var/www. Tenga mafaili ya cache, kwa sababu ni makubwa, yanabadilika kila siku, na hujijenga upya yenyewe:

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

Mzunguko wa kwanza unapakia kila kitu, hivyo huchukua muda. Run amri hiyo hiyo tena na itamalizika ndani ya sekunde chache, ikiripoti mafaili machache yaliyobadilika na MiB chache zilizoongezwa, kwa sababu deduplication inapakia vipande (chunks) vipya pekee. Orodhesha unachonacho:

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

Kila snapshot inaonyesha ID, muda, na njia (paths) zilizomo. ID hizo ndizo utakazotumia wakati wa kurejesha data (restore).

Kazi za usiku kwa kutumia systemd timer

Kuandika anwani ya repository kila wakati ni kazi inayochosha, na nakala ya ziada (backup) inayofanywa kwa mkono huacha kufanyika ndani ya mwezi mmoja. Suluhisho la matatizo haya mawili ni skript moja na timer moja. Skript hiyo huweka variable mbili za mazingira ambazo restic husoma, RESTIC_REPOSITORY na RESTIC_PASSWORD_FILE, ili kila amri ndani yake iwe fupi:

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

Mistari ya forget na check inaelezwa katika sehemu mbili zinazofuata. Sasa kuhusu ratiba: service ya oneshot inayotekeleza skript, na timer inayoiwasha saa 03:00 kila usiku. Timer ni bora kuliko cron hapa kwa sababu logi za kazi huhifadhiwa kwenye journal, na Persistent=true huendesha backup iliyokosekana mara tu seva inapopata muunganisho baada ya kuzimika.

# /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

Washa timer, kisha endesha service mara moja kwa mkono ili kuona inavyofanya kazi:

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

systemctl list-timers inaonyesha ni lini kazi inayofuata itaanza. Pia unaweza kutengeneza jozi ya faili za unit badala ya kuziandika:

Mchanganuo kamili wa faili hizi mbili, ikijumuisha sintaksi ya kalenda na maelekezo ya uimarishaji (hardening) ambayo service inaweza kuwa nayo, unapatikana kwenye running a program as a systemd service on a VPS.

Backup ni uvumi hadi utakapofanya restore

Chukulia sentensi hiyo kama amri. Kazi ya backup inayokamilika vizuri kila usiku inathibitisha tu kuwa kazi ilifanyika; haithibitishi kuwa data yako itarudi. Hatua mbili zinazoziba pengo hilo.

Kwanza, restic check, ambayo skript tayari huendesha kila usiku. Inahakiki muundo wa repository na index, hivyo uharibifu wa kimya kwenye host ya backup utakamatwa usiku unaofuata badala ya siku ya restore. Mara moja kwa mwezi, run toleo la kina, ambalo linapakua na kuhakiki kwa njia ya cryptographic sehemu ya kumi ya data halisi:

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%

Kwa sababu kundi la data ni la nasibu kila wakati, matokeo ya kila mwezi yanapitia repository nzima bila kuhitaji kupakua data yote kwa mara moja.

Pili, mazoezi ya restore. Bado ukiwa kwenye root shell kutoka hapo juu, restore directory moja halisi kutoka snapshot ya hivi karibuni kwenda eneo la muda (scratch location) na ulinganishe na faili zinazotumika sasa:

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

Ikiwa diff haitoi maandishi yoyote, inamaanisha kila byte imerudi vilevile, ambayo ndiyo ushahidi pekee unaofaa. Futa /srv/restore-drill baada ya hapo. Fanya mazoezi haya kila mwezi, na mara moja au mbili kwa mwaka fanya toleo kamili: restore snapshot nzima ya hivi karibuni kwenye VPS ya muda na uhakikishe kuwa application yako inaanza kufanya kazi kutoka hapo. Siku utakayohitaji hili kufanya kazi chini ya shinikizo, unapaswa kuwa utaratibu ambao tayari umeshaufanya.

Retention: forget plus prune

Bila sera, snapshots hujikusanya milele na repository hukua tu. Mstari wa forget wa script hutumia sera kila usiku: --keep-daily 7 huweka snapshot moja kwa siku kwa siku saba zilizopita, --keep-weekly 4 moja kwa wiki kwa wiki nne, na --keep-monthly 6 moja kwa mwezi kwa miezi sita. Kila kitu ambacho hakijalindwa na sheria hufutwa.

forget pekee huondoa rekodi za snapshot tu; data chunks hubaki kwenye repository mpaka kitu kingine kizifute. Hicho ndicho --prune hufanya: hutafuta chunks ambazo hazina marejeo ya snapshot na kuzifuta, hapo ndipo nafasi ya diski hurejeshwa. Prune hufanya kazi halisi ya repository, hivyo kwenye repository kubwa baadhi ya watu hurun forget kila usiku na --prune kila wiki; kwenye ukubwa wa kawaida wa VPS, kila usiku inatosha.

Databases: fanya dump kwanza, kisha backup dump hiyo

Restic hunakili faili wakati inasoma, lakini database huandika kwenye faili zake kila wakati. Faili ya database iliyonaswa katikati ya uandishi itarejea ikiwa imeparara, kwa sababu nakala hiyo itachanganya kurasa (pages) za kabla na baada ya uandishi. Suluhisho ni la kawaida: iweke database itengeneze export thabiti kwenye faili, kisha iache restic i-backup faili hiyo.

Kwa PostgreSQL, ongeza mstari wa dump juu ya restic-backup.sh, kabla ya amri ya restic backup, na uweke directory ya dump kwenye njia za backup:

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

mysqldump hufanya kazi sawa kwa MariaDB na MySQL. Kwa mfano kamili wa mbinu hii, sehemu ya backup ya Nextcloud huwasha hali ya matengenezo (maintenance mode), hufanya dump ya Postgres, na hunakili faili kama seti moja thabiti, ambayo ndiyo seti restic inapaswa kuichukua kila usiku. SQLite inatumia wazo lile lile kwa njia rahisi zaidi: mwongozo wa Vaultwarden husitisha container kwa sekunde chache ili kuchukua nakala ya db.sqlite3, na nyimbo hiyo ndiyo restic inayoituma nje ya server.

FAQ

Je, restic backups zimefanyiwa encryption?

Ndiyo, kila wakati. Kila restic repository imefanyiwa encryption kwa kutumia AES-256. Hakuna hali ya kutotumia encryption, na kila amri inahitaji password ya repository. Mashine au mtoa huduma anayehifadhi repository anashikilia tu encrypted blobs, hivyo host ya backup ikiwa imeingiliwa, mafaili yako hayatovuja. Makubaliano ni kwamba: bila password, data haiwezi kupatawa na mtu yeyote, hivyo hifadhi nakala ya password hiyo mbali na server.

Je, restic hufanya incremental backups?

Kila restic snapshot inafanya kazi kama full backup, huku ikitumia nafasi ndogo ya storage kwa njia ya incremental. Restic hugawanya mafaili katika chunks na kupakia tu chunks ambazo repository bado haijazihifadhi, hivyo kazi ya usiku mmoja inahamisha kile kilichobadilika tu siku hiyo. Tofauti na mifumo ya kizamani ya incremental, hakuna mnyororo (chain) wa kuufuatilia: snapshot yoyote inarudisha data moja kwa moja na kufuta snapshot ya zamani hakuharibu snapshot mpya.

Nitafautishaje mafaili kutoka kwenye restic backup?

Tumia restic snapshots kupata snapshot ID, kisha tumia restic restore <id> --target /some/empty/dir kuirudisha, ukiongeza --include /path ili kurudisha sehemu tu ya snapshot hiyo. latest hufanya kazi badala ya ID. Restic huunda upya muundo wa directory ya asili chini ya lengo (target), hivyo kurudisha /etc/ssh kutatokea kwenye /some/empty/dir/etc/ssh. Fanya mazoezi haya kabla ya kuihitaji, kwa sababu backup ambayo haijajaribiwa ni uvumi tu.

Ni mara ngapi ninapaswa kuendesha restic backup?

Kufanya kila usiku ni kiwango cha chini kwa server, na deduplication hufanya hili kuwa rahisi: kila awamu inapakia tu chunks ambazo zimebadilika tangu awamu iliyopita. Data inayobadilika haraka, au ambayo itasababisha hasara hata kama itapotea kwa siku moja, inaweza kuendeshwa kila baada ya saa chache kwa mpangilio ule ule. Frequency ni sehemu rahisi; pia endesha restic check mara kwa mara na jaribio la kurejesha (restore drill) kila mwezi, kwa sababu ratiba bila uhakiki ni faraja ya uongo.

Itakuwaje nikipoteza password ya restic repository yangu?

Backups hazitaweza kupatikana tena. Encryption ya Restic haina njia ya nyuma (back door) wala uwezo wa kureset, hivyo password ni muhimu kama backups zenyewe. Weka nakala kwenye password manager yako na mahali popote kudumu ambapo si server inayofanyiwa backup. Wakati bado una ufikiaji, restic key add inaweza kusajili password ya pili kwa ajili ya repository hiyo hiyo, ambayo itakupa nakala ya ziada.