Tukuyin ang katanggap-tanggap na data loss at recovery time, panatilihin ang consistent na independiyenteng kopya at i-test ang pag-restore ng aktwal na application nang hiwalay. Ang natapos na backup job o integrity check lamang ay hindi nagpapatunay na naroroon ang bawat dependency na kailangan para sa recovery.
Magsimula sa recovery na kailangan mo
Ang backup plan ay nagsisimula sa dalawang praktikal na tanong: gaano karaming kamakailang trabaho ang maaari mong mawala, at gaano katagal maaaring hindi available ang serbisyo? Ang mga sagot na iyon ay tumutukoy sa schedule, data na isasama at paraan ng restoration. Ang araw-araw na kopya ay maaaring angkop sa bihirang nababagong website habang nag-iiwan ng masyadong malaking agwat para sa abalang application.
Ilista ang mga bagay na nagpapagana sa serbisyo, hindi lamang ang pinakamalaking folder nito. Ang application data, nilalaman ng database, configuration, mga na-upload na file at impormasyong kailangan upang muling buuin ang kapaligiran ay maaaring lahat mahalaga. Panatilihin ang pribadong inventory ng mga dependency at recovery key. Ang backup ay dapat sumuporta sa gumaganang sistema, hindi lamang gumawa ng archive na nakalimutan na ang layunin.
Panatilihin ang kopya sa labas ng failure boundary
Ang pangalawang directory sa parehong machine ay makakatulong sa pag-recover mula sa maling edit, ngunit nananatili itong nakalantad sa pagkawala ng machine na iyon. Ang mga local snapshot ay maaaring mahalaga para sa mabilis na rollback at nangangailangan pa rin ng independiyenteng kopya para sa mas malawak na insidente. Pumili ng hiwalay na recovery destination at magpasya kung aling access ang dapat makabasa, makasulat o makapag-alis ng backup.
Kung ang production credentials ay maaaring magbura ng bawat recovery copy, ang nakompromisong application account ay maaaring talunin ang buong estratehiya. Paghiwalayin ang access kung posible at protektahan ang storage credentials. Nakakatulong ang encryption na protektahan ang nakaimbak na nilalaman, ngunit ang recovery process ay umaasa rin sa ligtas na pagpapanatili ng key nito sa labas ng nasirang kapaligiran.
Kumuha ng consistent na application state
Ang pagkopya ng mga bukas na database file nang walang angkop na paraan ay maaaring makakuha ng hindi magagamit na state. Gumamit ng backup approach na sinusuportahan ng application o database, at unawain kung nangangailangan ito ng consistent snapshot, logical export o maikling paghinto sa writes. I-coordinate ang kaugnay na data upang ang upload directory at ang mga database reference nito ay naglalarawan ng parehong punto sa workflow.
Isadokumento nang sinasadya ang mga exclusion. Ang mga cache at temporary build file ay maaaring maulit; ang mga customer upload ay karaniwang hindi. Suriin ang listahan pagkatapos magdagdag ng feature o maglipat ng directory. Ang matagumpay na backup job ay hindi mapapanatili ang path na hindi kailanman isinama.
I-test ang restoration sa isolated na kapaligiran
I-restore ang representatibong data sa hiwalay na lokasyon at beripikahin na bubukas ito nang tama. Para sa isang application, i-test ang na-recover na serbisyo pati na ang mga file. I-disable ang outgoing email, scheduled jobs at external integrations sa test environment upang ang rehearsal ay hindi kumilos sa tunay na user o magduplicate ng production tasks.
Ang repository integrity checks at restore test ay sumasagot sa magkaibang tanong. Maaaring suriin ng tool ang nakaimbak na structure at data habang ang application ay nangangailangan pa rin ng nawawalang configuration o nakalimutang key. Itala kung gaano katagal ang recovery, anong manual steps ang kailangan at saan kailangan ng pagpapabuti ang procedure. Ulitin ang ehersisyo pagkatapos ng makabuluhang pagbabago.
Isang praktikal na senaryo: sanayin ang recovery bago ang launch
Isaalang-alang ang isang application na may database, user uploads at maliit na hanay ng private configuration files. Gumagawa ang may-ari ng recovery inventory at pumipili ng database-supported consistency method. Ang hiwalay na backup destination ay nag-iimbak ng mga kinakailangang kopya, habang ang recovery key ay pinananatili sa labas ng production machine. Ang unang test ay nagsisimula sa walang laman na isolated environment, kaya hindi maaaring hiramin ang mga nakatagong dependency mula sa gumaganang server.
Ine-restore ng may-ari ang data at configuration, pagkatapos ay sinusuri ang login, isang representatibong record at isang na-upload na file. Ang outgoing email, scheduled jobs at external actions ay nananatiling disabled sa panahon ng rehearsal. Kung magsisimula ang database ngunit nawawala ang upload path o secret, natagpuan ng test ang agwat na hindi isisiwalat ng matagumpay na archive job. Itinatama ng may-ari ang inventory at inuulit ang apektadong recovery check.
Sa huli, itinatala ng may-ari ang oras ng restoration at ang mga manual step. Ang schedule at retention policy ay inihahambing sa kung gaano karaming kamakailang trabaho ang maaaring mawala at gaano katagal maaaring hindi available ang serbisyo. Ang mga ito ay desisyong partikular sa proyekto sa halip na mga garantiyang ibinibigay ng storage label. Ang nasubok na procedure ay gumagawa ng opsyonal na backup o storage product na kapaki-pakinabang bilang bahagi ng mas malawak na recovery strategy.
| Katibayan ng pagpapanumbalik | Ano ang sinusuri nito | Natitirang tanong |
|---|---|---|
| Natapos ang backup job | Nag-ulat ng tagumpay ang job | Kasama ba ang lahat ng kinakailangang path? |
| Pagsusuri ng integridad ng repository | Mga nakaimbak na structure o data check | Nasa application ba ang bawat dependency? |
| Hiwalay na pagpapanumbalik ng application | Gumagana ang isang representatibong recovery | Natutugunan ba ng naobserbahang oras ang iyong layunin? |
Gawing nakikita ang failure at sinasadya ang retention
Ang backup na tahimik na humihinto ay sorpresa sa hinaharap. Subaybayan ang pagkumpleto ng job, available na capacity at edad ng pinakabagong magagamit na recovery point. Panatilihin ang sapat na history upang makabawi mula sa problemang natuklasan sa ibang pagkakataon, at unawain kung paano naaapektuhan ng pruning ang history na iyon. Suriin nang maingat ang mga deletion operation dahil ang mga pagkakamali sa retention ay maaaring mag-alis ng tanging kapaki-pakinabang na bersyon.
Basahin ang saklaw ng anumang opsyon sa backup sa napili mong serbisyong SwissOctet at kumpirmahin ang proseso ng pagpapanumbalik. Maaaring ituring ang Vault Storage bilang bahagi ng kapasidad, ngunit ang isang produktong imbakan lamang ay hindi isang kumpletong patakaran sa pagbawi. Magpasya kung ano ang kailangan mong ibalik, panatilihing independyente ang kopya at patunayan ang pamamaraan bago maging kritikal ang serbisyo.
Ang iyong praktikal na checklist.
- Itakda ang katanggap-tanggap na pagkawala ng data at oras ng pagbawi.
- Isama ang mga database, upload at impormasyon para sa muling pagbuo.
- Panatilihin ang isang independyenteng kopya at hiwalay na mga susi sa pagbawi.
- Ibalik sa isang nakahiwalay na kapaligiran at subukan ang aplikasyon.
- Subaybayan ang edad, kapasidad at pananatili ng backup.
Ang mga detalyeng mahalaga.
Ang isang pangalawang direktoryo sa parehong server ba ay isang independyenteng backup?+
Hindi. Nananatili itong nakalantad sa pagkawala ng server na iyon, bagama't makakatulong ito sa pagbawi mula sa isang lokal na pagkakamali.
Pinapalitan ba ng pagsusuri ng integridad ang isang pagsubok sa pagpapanumbalik?+
Hindi. Ang isang wastong repositoryo ay maaari pa ring magkulang ng configuration, mga susi o data na kailangan ng aplikasyon.
Bakit hindi paganahin ang mga integrasyon sa panahon ng pagsubok sa pagpapanumbalik?+
Upang maiwasan ang test environment na magpadala ng email sa mga tunay na user, ulitin ang mga trabaho o mag-trigger ng mga aksyon sa production.
Pumunta sa pinagmulan.
Sinusuportahan ng mga sangguniang ito ang mga teknikal na konsepto sa gabay na ito. Sundin ang kasalukuyang dokumentasyon bago baguhin ang isang production system.
- restic: Pagpapanumbalik mula sa backup restic.readthedocs.io
- restic: Paggawa gamit ang mga repositoryo restic.readthedocs.io
- PostgreSQL: Backup at Pagpapanumbalik www.postgresql.org
Editorial guidance ni SwissOctet. Ang mga halimbawa ay ilustratibo. Ang service specifications, available options at contractual conditions ay dapat beripikahin nang hiwalay.