Restic: Hamisha Backup za VPS Nje ya Seva

Kwa nini backup iliyo kwenye seva hiyo hiyo si backup

Restic ni zana ya backup isiyolipishwa na yenye msimbo huria inayotuma snapshots zilizotiwa encryption na kuondolewa nakala zinazorudiwa za faili zako kwenye repository iliyo mahali pengine: VPS ya pili, mashine ya nyumbani, au object storage inayooana na S3. Mwongozo huu unasetup kwenye Ubuntu 24.04, kuanzia usakinishaji hadi repository kupitia SFTP, backup ya kwanza, systemd timer ya kila usiku, sera ya retention, na zoezi la restore linalothibitisha kuwa kila kitu kinafanya kazi. Destination lazima iwe mashine nyingine, kwa sababu nakala iliyo kwenye seva hiyo hiyo hupotea pamoja na seva inapoharibika.

backup/ directory kwenye mashine inayofanyiwa backup hukulinda dhidi ya jambo moja tu: kufuta faili kimakosa. Haiokoki baada ya disk kushindwa, kwa sababu ilikuwa kwenye disk hiyo hiyo. Haiokoki baada ya mshambulizi mwenye root, kwa sababu hufuta nakala hizo kwanza. Haiokoki baada ya kosa la akaunti linaloondoa VPS yenyewe. Kituo cha data kisicho na ufanisi zaidi duniani hufanya mzaha kuhusu tarball inayoitwa backup_final_v2_REAL iliyokaa kwenye array hiyo hiyo na data, na mzaha huo unaeleweka kwa sababu wengi wetu tumewahi kufanya hivyo. Nje ya mashine ndiyo kanuni, na restic ndiyo njia yenye usumbufu mdogo zaidi ya kuifuata.

Restic katika mawazo manne

Repository. Hapa ndipo restic huandika data. Ni saraka yenye muundo wa restic yenyewe, iliyojaa blobs zilizosimbwa kwa njia fiche, na restic pekee ndiyo inayoweza kuisoma. Usiihariri kamwe kwa mikono; unawasiliana nayo kupitia amri za restic na anwani ya -r.

Snapshot. Hii ni picha ya wakati mmoja ya faili ulizocheleza (backup). Kila backup huunda snapshot, kila snapshot inaweza kurejeshwa kivyake, na kila moja hufanya kazi kama nakala kamili ya data yako wakati huo.

Deduplication. Restic hugawanya faili katika vipande kulingana na maudhui yake na kupakia tu vipande ambavyo repository haijawahi kuviona. Backup ya kwanza hupakia kila kitu; kila backup inayofuata hupakia kile kilichobadilika tu. Snapshot ya kila siku ya 20 GB ambapo 50 MB pekee zimebadilika hugharimu takriban 50 MB, ndiyo maana kuhifadhi snapshot nyingi ni nafuu.

Encryption by default. Repository ya restic husimbwa kila wakati (AES-256). Restic hukataa kuunda au kufungua repository yenye nenosiri tupu isipokuwa utumie --insecure-no-password (restic 0.17.0 na kuendelea), kwa hivyo repository iliyosanidiwa kama ilivyo katika mwongozo huu inahitaji nenosiri lake kwa kila amri. Seva ya backup au mtoa huduma wa hifadhi huona tu blobs zilizosimbwa. Matokeo yake ni makali: ukipoteza nenosiri, data imepotea kabisa na kwa makusudi. Hifadhi nakala ya nenosiri mahali ambapo si seva hii. Hili ni muhimu kiasi kwamba linatajwa mara mbili zaidi hapa chini.

Sakinisha restic kwenye Ubuntu 24.04

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

Kwenye Ubuntu 24.04, hii husakinisha restic 0.16.4, huku toleo la sasa la upstream likiwa 0.19.1. Tofauti hii ipo kwa sababu toleo la LTS (long term support) hugandisha matoleo ya vifurushi vyake, na hilo halina umuhimu hapa: 0.16.4 hufanya kila kitu katika mwongozo huu. Ikiwa unataka toleo jipya zaidi kwa maboresho yake ya kasi, pakua build rasmi ya single-binary kutoka ukurasa wa GitHub releases wa mradi wa restic, ifungue kwa bunzip2, kisha isakinishe kwenye /usr/local/bin/restic; hakuna hatua nyingine ya kusakinisha restic.

Unda hazina kwenye seva nyingine kupitia SFTP

Unahitaji mashine ya kulengwa: VPS ndogo ya pili ndiyo chaguo la kawaida, na mashine yoyote yenye seva ya SSH pamoja na nafasi ya ziada kwenye diski itafanya kazi. Restic hutumia SFTP (uhamishaji wa faili kupitia SSH), kwa hiyo huhitaji kusakinisha chochote kwenye mwenyeji wa nakala rudufu. Katika mwongozo huu, mwenyeji wa nakala rudufu ni 10.0.0.12 na mtumiaji anaitwa restic. Usimpe mtumiaji huyo jina backup: Ubuntu na Debian husafirisha akaunti ya mfumo iliyohifadhiwa inayoitwa backup (uid 34, bila shell ya kuingia) kwenye kila usakinishaji, kwa hiyo adduser backup hushindwa na ssh backup@... huwekwa kwenye nologin.

Kazi ya kila usiku itaendeshwa kama root kwenye seva inayohifadhiwa nakala, kwa hiyo root inahitaji kuingia kwa kutumia key kwenye mwenyeji wa nakala rudufu. Unda key maalumu bila passphrase, kwa sababu hakuna mtu atakayekuwepo saa 3 asubuhi kuandika passphrase, kisha iinakili:

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

Ikiwa bado hujazoea keys, Misingi ya usimamizi wa SSH keys inaeleza mfumo huu, permissions, na jinsi ya kubatilisha key baadaye.

Ifuatayo ni password ya hazina. Tengeneza password imara ndani ya faili inayoweza kusomwa 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. VPS hii ikiharibika, hazina pamoja na password hii vinaweza kurejesha kila kitu; hazina bila password hiyo haiwezi kurejesha chochote.

Anzisha hazina:

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

Chaguo jingine la kulengwa ni object storage inayooana na S3. Hili ndilo chaguo linalofaa ikiwa hutaki kuendesha mashine ya pili. Bucket yoyote inayooana na S3 hufanya kazi kwa njia hiyo hiyo; hubadilika tu anwani na variables mbili za credentials:

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 maeneo yote mawili ya kulengwa. Sehemu iliyobaki ya mwongozo huu inaonyesha anwani ya SFTP; badilisha iwe yako.

Hifadhi rudufu ya kwanza, bila kujumuisha

Hifadhi rudufu ya data ambayo huwezi kusakinisha tena, si mfumo mzima wa faili. Mfumo wa uendeshaji hurudi baada ya kusakinishwa upya; usanidi na data yako haurudi. Kwa VPS ya kawaida, hiyo inamaanisha /etc, /home, na mahali ambapo programu zako huhifadhi hali yake, kama vile /srv au /var/www. Usijumuishe cache, kwa sababu ni kubwa, hubadilika kila siku, na hujijenga upya:

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

Uendeshaji wa kwanza hupakia kila kitu, kwa hiyo huchukua muda. Endesha amri hiyo hiyo tena, na itakamilika kwa sekunde chache huku ikiripoti faili chache zilizobadilika na MiB chache zilizoongezwa, kwa sababu deduplication hupakia vipande vipya pekee. Orodhesha ulicho nacho:

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

Kila snapshot huonyesha kitambulisho, muda, na njia ilizo nazo. Vitambulisho hivyo ndivyo unavyotumia kurejesha data.

Kuendesha kazi kila usiku kwa kutumia systemd timer

Kuandika anwani ya repository kwenye kila command kunachosha, na backup unayoendesha kwa mkono huacha kufanyika ndani ya mwezi mmoja. Matatizo yote mawili yanaisha kwa script moja na timer moja. Script huweka environment variables mbili ambazo restic husoma, RESTIC_REPOSITORY na RESTIC_PASSWORD_FILE, hivyo kila command ndani yake hubaki 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 imeelezwa katika sehemu mbili zinazofuata. Sasa tuweke ratiba: service ya oneshot inayoendesha script, na timer inayoianzisha saa 03:00 kila usiku. Timer ni bora kuliko mstari wa cron hapa kwa sababu mchakato huandikwa kwenye journal, na Persistent=true huendesha backup iliyokosa mara tu seva inaporudi mtandaoni baada ya kukaa chini.

# /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 na ufuatilie 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 huonyesha wakati wa utekelezaji unaofuata. Unaweza pia kuzalisha unit files hizo mbili badala ya kuziandika:

Muundo kamili wa files hizi mbili, ukiwemo muundo wa kalenda na directives za hardening ambazo service inaweza kuwa nazo, umeelezwa katika kuendesha programu kama systemd service kwenye VPS.

Backup ni uvumi hadi utakapoiirejesha

Chukulia sentensi hiyo kama amri. Kazi ya backup inayokamilika kila usiku inathibitisha tu kwamba kazi imefanyika; haithibitishi kuwa data yako itarudi. Uchunguzi mbili hufunga pengo hili.

Kwanza, restic check, ambayo hati (script) tayari huiendesha kila usiku. Inathibitisha muundo wa repository na index, ili uharibifu wa kimyakimya kwenye seva ya backup ugundulike usiku unaofuata badala ya siku ya kurejesha data. Mara moja kwa mwezi, endesha toleo la kina zaidi, ambalo hupakua na kuthibitisha kwa njia ya kriptografia 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 sehemu ndogo huchaguliwa kwa nasibu kila wakati, nyaraka za restic zinasema wazi kuwa uendeshaji wa mara kwa mara hauhakikishi kufunika kila faili ya pack, hata ufanye mara ngapi. Ikiwa unataka uendeshaji wa kila mwezi ufanye kazi kupitia repository nzima bila kulipia upakuaji kamili, tumia fomu ya kikundi maalum: --read-data-subset=1/10 mwezi mmoja, 2/10 mwezi unaofuata, na kadhalika hadi 10/10. Restic hugawanya faili za pack katika vikundi kumi sawa na huangalia tu kikundi n, kwa hivyo mzunguko kamili wa mara kumi husoma kila kikundi mara moja.

Pili, mazoezi ya kurejesha data (restore drill). Ukiwa bado kwenye root shell kutoka hapo juu, rejesha saraka moja halisi kutoka kwa snapshot ya hivi karibuni kwenye eneo la muda na uilinganishe na faili zilizopo:

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

diff kutochapisha chochote inamaanisha kila byte imerudi ikiwa sawa, ambayo ndiyo ushahidi pekee unaohesabika. Futa /srv/restore-drill baadaye. Fanya mazoezi haya kila mwezi, na mara moja au mbili kwa mwaka fanya toleo kamili: rejesha snapshot nzima ya hivi karibuni kwenye VPS ya muda na uangalie kama programu yako inaanza kutoka hapo. Siku utakapohitaji hili lifanye kazi chini ya shinikizo, unataka liwe utaratibu ambao tayari umeshaufanya.

Uhifadhi: sahau pamoja na prune

Bila sera, snapshots zitaendelea kujikusanya na repository itaendelea kukua. Mstari wa forget wa script hutekeleza sera kila usiku: --keep-daily 7 huhifadhi 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 snapshot ambayo hailindwi na sheria husahaulika.

forget peke yake huondoa rekodi za snapshot tu; data chunks hubaki kwenye repository hadi kitu kizung'ue. Hilo ndilo linalofanywa na --prune: hutafuta chunks ambazo hazirejelewi tena na snapshot yoyote na kuzifuta. Hapo ndipo nafasi ya disk inapopatikana tena. Prune hufanya kazi halisi kwenye repository, kwa hiyo kwenye repository kubwa baadhi ya watu huendesha forget kila usiku na --prune kila wiki; kwa ukubwa wa kawaida wa VPS, kuendesha kila usiku kunatosha.

Databases: fanya dump kwanza, kisha hifadhi dump hiyo

Restic hunakili files inapozisoma, huku database ikiendelea kuandika kwenye files zake. File ya database iliyonakiliwa wakati wa kuandika hurejeshwa ikiwa imeharibika, kwa sababu nakala hiyo huchanganya pages za kabla na baada ya uandishi. Suluhisho ni la kawaida: ifanye database engine itengeneze export thabiti kwenye file, kisha iache restic ihifadhi file hiyo.

Kwa PostgreSQL, ongeza mstari wa dump mwanzoni mwa restic-backup.sh, kabla ya command ya restic backup, na ujumuishe directory ya dump kwenye paths za backup:

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

mysqldump hutimiza kazi hiyo hiyo kwa MariaDB na MySQL. Kwa mfano kamili wa utaratibu huu, sehemu ya backup ya Nextcloud huwasha maintenance mode, hufanya dump ya Postgres, na kunakili files kama seti moja thabiti, yaani seti ambayo restic inapaswa kuitoa kwenye server kila usiku. SQLite hutumia wazo hilo hilo kwa njia rahisi zaidi: mwongozo wa Vaultwarden husimamisha container kwa sekunde chache ili kutengeneza nakala ya baridi ya db.sqlite3, kisha archive hiyo ndiyo ambayo restic huitoa kwenye server.

FAQ

Je, backups za restic zimesimbwa kwa njia fiche?

Ndiyo, daima. Kila repository ya restic husimbwa kwa AES-256 na hakuna hali ya kutokusimba. Restic pia hukataa nenosiri tupu isipokuwa utumie --insecure-no-password (inapatikana tangu restic 0.17.0), kwa hivyo repository iliyosanidiwa kama ilivyo katika mwongozo huu inahitaji nenosiri lake kwa kila amri. Mashine au mtoa huduma anayehifadhi repository anashikilia tu blobs zilizosimbwa, kwa hivyo seva ya backup iliyoathiriwa haifichui faili zako. Badala yake ni kamili: bila nenosiri data haiwezi kurejeshwa na mtu yeyote, kwa hivyo hifadhi nakala yake mbali na seva.

Je, restic hufanya backups za nyongeza (incremental)?

Kila snapshot ya restic hufanya kazi kama backup kamili, huku ikigharimu hifadhi ya nyongeza. Restic hugawanya faili katika vipande na kupakia tu vipande ambavyo repository haijahifadhi, kwa hivyo uendeshaji wa kila usiku huhamisha kile kilichobadilika siku hiyo. Tofauti na mifumo ya kawaida ya nyongeza, hakuna mnyororo wa kurudia: snapshot yoyote hurejesha moja kwa moja na kufuta snapshot ya zamani hakuvunji snapshot mpya zaidi.

Ninawezaje kurejesha faili kutoka kwa backup ya restic?

Endesha restic snapshots ili kupata ID ya snapshot, kisha restic restore <id> --target /some/empty/dir ili kuirejesha, ukiongeza --include /path ili kurejesha sehemu yake tu. latest hufanya kazi badala ya ID. Restic huunda upya muundo wa saraka asilia chini ya lengo, kwa hivyo kurejesha /etc/ssh huishia kwenye /some/empty/dir/etc/ssh. Fanya mazoezi haya kabla hujayahitaji, kwa sababu backup isiyojaribiwa ni uvumi tu.

Ni mara ngapi ninapaswa kuendesha backup ya restic?

Kila usiku ni kiwango cha chini kinachofaa kwa seva, na deduplication hufanya iwe nafuu: kila uendeshaji hupakia tu vipande vilivyobadilika tangu ule wa mwisho. Data inayobadilika haraka, au ambayo kupoteza hata siku moja kungeleta madhara, inaweza kuendeshwa kila baada ya saa chache kwa kutumia muundo uleule wa timer. Marudio ni nusu rahisi; pia endesha restic check mara kwa mara na mazoezi ya kurejesha data kila mwezi, kwa sababu ratiba bila uthibitisho ni faraja ya uongo.

Nini kitatokea nikipoteza nenosiri la repository ya restic?

Backups haziwezi kurejeshwa. Usimbaji wa restic hauna mlango wa nyuma wala uwezekano wa kuweka upya, kwa hivyo nenosiri ni muhimu kama backups zenyewe. Hifadhi nakala kwenye meneja wako wa nenosiri na mahali popote pengine pa kudumu ambapo si seva inayochelezwa. Ukiwa bado na ufikiaji, restic key add inaweza kusajili nenosiri la pili kwa repository ileile, jambo linalokupa akiba.