Mga naka-encrypt na backup na talagang maibabalik mo.

Piliin ang hangganan ng repository

Gumamit ng hiwalay na destinasyon at credentials mula sa production server. Maaaring protektahan ng client-side encryption ang mga nakaimbak na kopya, ngunit ang repository password o key ay dapat i-back up nang pribado. Kapag nawala ito, maaaring maging hindi magamit ang bawat naka-encrypt na snapshot.

Kumuha ng pare-parehong data

Gumamit ng database-native na mga dump o snapshot procedure na sinusuportahan ng application. I-back up ang configuration, mga tagubilin sa deployment at ang mga protektadong secret na kailangan para sa recovery. Ibukod lamang ang mga transient cache kapag alam mong maaari silang muling buuin.

Pahirapan ang pag-delete

Isaalang-alang ang append-only o immutable na destinasyon kung saan hindi mabubura ng source machine ang bawat makasaysayang kopya. Paghiwalayin ang retention at pruning credentials kung posible. Ang encryption lamang ay hindi pumipigil sa kompromisadong server na magbura ng writable repository.

Mag-iskedyul ng mga check at restore drill

Subaybayan ang exit status ng job at edad ng huling magandang backup. Patakbuhin ang repository integrity checks na sinusuportahan ng tool. Regular na i-restore ang isang sample at magsagawa ng kumpletong recovery rehearsal pagkatapos ng malalaking pagbabago sa application.

Ihiwalay ang pagdaragdag ng kopya sa pagtanggal ng history

Ang append-only na destinasyon ay maaaring payagan ang production server na magdagdag ng mga snapshot habang pinapanatili ang awtoridad sa pagbura sa isang hiwalay na pinagkakatiwalaang makina. Kailangan pa ring maingat na suriin ang retention: ang mga pekeng mas bagong snapshot ay maaaring makasira sa ilang calendar-based selection policy. Suriin ang gabay ng tool, magpatakbo ng retention dry run at subaybayan ang capacity. Pinipili ng forget operation ng Restic ang mga snapshot; inaalis ng pruning ang mga unreferenced na nakaimbak na data.

• Ilayo ang mga kredensyal sa pagpapanatili ng repository sa production machine
• Magpatakbo ng retention dry run bago payagan ang pagtanggal
• Gumamit ng bagong walang laman na target para sa bawat recovery exercise

restic check
restic snapshots
restic restore latest --target /srv/restore-drill

Opisyal na dokumentasyon: Restic retention at pruning

Isang restore drill na may pass condition

Pumili ng isang makatotohanang failure: isang naburang file, nawalang database o kumpletong rebuild ng makina. I-restore sa hiwalay na directory o isolated host. I-verify ang nilalaman ng file, mga permission at kakayahan ng application na gamitin ang mga ito. Itala ang lumipas na oras at anumang manual step na kulang sa runbook. Ang repository check ay nagpapatunay ng ibang katangian kaysa sa gumaganang application restore.

• Huwag mag-restore sa live na application bilang unang pagsubok
• Kumpirmahing nakakabawi nang independiyente ang encryption credentials
• Mag-alerto kung ang pinakabagong matagumpay na backup ay lumampas sa iyong recovery target

Bumuo ng recovery manifest bago pumili ng mga exclusion

Ilista ang mga bagay na hindi maibabalik sa pamamagitan ng muling pag-install ng package: nilalaman ng database, mga upload, konfigurasyon ng application, mga susi sa pag-sign o encryption at mga bersyon ng deployment. Itala ang paraan ng consistency sa tabi ng bawat item. Ang database dump ay kabilang sa isang tiyak na punto ng oras; ang pagkopya ng abalang direktoryo ng database ay maaaring magbunga ng ibang resulta. Itago ang access sa repository, ang passphrase nito at anumang export ng Borg key sa hiwalay at pribadong lokasyon ng recovery. Subukan na mabuksan ng kapalit na makina ang repository bago ito gawing tanging kopya ng recovery.

• Isaalang-alang ang recovery point objective: gaano karaming kamakailang trabaho ang maaaring mawala. Itakda ang iskedyul ayon sa pangangailangang iyon.
• Isaaad ang recovery time objective: gaano katagal ang isang rebuild. Isama ang database import at mga pagbabago sa DNS sa rehearsal.
• Suriin na ang exclusion na para sa caches ay hindi rin nag-aalis ng uploads, container volumes o protektadong configuration.
• Gamitin ang dokumentasyon para sa naka-install na major version ng Borg; hindi mapagpapalit ang mga format ng repository at command sa lahat ng version.

Opisyal na dokumentasyon: Borg: encryption, consistency at restoration

Suriin ang nakaimbak na data gayundin ang metadata ng repository

Magkaibang gawain ang default repository check ng Restic at ang read-through verification. I-iskedyul ang data verification nang isinasaalang-alang ang bandwidth at runtime cost nito. Sinusuri ng halimbawa ang isang tinukoy na ikalimang bahagi ng pack files; dapat gamitin ng mga susunod na naka-iskedyul na check ang iba pang fraction para masakop ang repository. Ang random na piniling subset ay hindi nagbibigay ng parehong coverage guarantee. Wala sa dalawang operasyon ang nagpapatunay na makakapagsimula ang application gamit ang na-restore na data.

restic check --read-data-subset=1/5
restic snapshots --host example-host
restic restore latest --host example-host --target /srv/restore-drill

Opisyal na dokumentasyon: restic: mga repository check at data verification

Panatilihing wala sa abot ng kompromisong kliyente ang maintenance

Pinapanatili ng Borg append-only storage ang naka-commit na segment data, ngunit maaari pa ring baguhin ng client ang nakikitang archive list; ang recovery at compaction ay nangangailangan ng dokumentadong administrative procedure. Ihigpit ang remote backup credential sa server command ng Borg, hindi sa unrestricted shell o filesystem login na maaaring lumampas sa mga proteksyong iyon. Sa restic, suriin ang keep-within guidance para sa append-only retention. Bago ang anumang maintenance na maaaring mag-alis ng history, inspeksyunin ang kalusugan ng repository at i-preview ang selection mula sa isang pinagkakatiwalaang machine.

• Subaybayan ang edad ng huling matagumpay na kopya, paglaki ng repository, espasyo ng cache at libreng kapasidad sa magkabilang dulo.
• Kung mabigo ang isang restore, panatilihin ang orihinal na repository at mga log bago subukan ang pag-aayos o paglilinis.
• Kung nagtagumpay ang job pero kulang ang inaasahang mga file, suriin ang nilalaman ng archive at mga exclusion pattern bago baguhin ang retention.
• Tapusin ang drill sa pagbubukas ng mga file at pagpapatakbo ng application checks nang hiwalay; ilayo ang production destinations sa restore command.

Opisyal na dokumentasyon: Borg: append-only na operasyon at maintenance · restic: retention at append-only na mga konsiderasyon