Ang snapshot ay representasyon sa isang punto ng oras na ang proteksyon ay tinutukoy ng implementasyon nito. Ang estratehiya ng backup ay nagdadagdag ng sinadyang retention, paghihiwalay ng access at nasubok na recovery. Ang ilang snapshot ay backup; ang iba ay umaasa sa orihinal na storage. Itanong kung ano ang nakakaligtas sa pagtanggal, compromise o pagkawala ng pangunahing environment.
Ilarawan ang kopya bago ito pangalanan
Sinasabi sa iyo ng salitang snapshot na may nairepresenta sa isang punto ng oras, ngunit hindi kung saan hawak ang maibabalik na data o kung sino ang makakapagtanggal nito. Ang filesystem snapshot sa orihinal na storage at provider-managed block snapshot ay maaaring may magkaibang hangganan ng failure. Magsimula sa implementasyon sa halip na ituring ang label bilang pangkalahatang pangako.
Idinodokumento ng AWS ang EBS snapshots bilang incremental point-in-time backups ng mga volume nito. Iyon ay partikular na implementasyon, hindi patunay na ang bawat opsyon ng snapshot ay kumikilos nang pareho. Para sa anumang serbisyo, itanong kung ang restoration ay umaasa sa orihinal na volume, kung ang mga kopya ay lumalabas sa pangunahing failure domain at kung ano ang nangyayari kapag tinanggal ang source.
Ihambing ang mga failure na inaasahan mong malampasan
Ang mabilis na rollback pagkatapos ng update at recovery pagkatapos mawala ang account ay magkaibang problema. Ang lokal na snapshot ay maaaring maginhawa para sa una habang nag-aalok ng kaunting paghihiwalay para sa pangalawa. Ang mga independiyenteng kopya ay makakapagdagdag ng proteksyon, ngunit kung ang kanilang storage, access at mga landas ng pagtanggal ay sapat na hiwalay mula sa insidenteng inihahanda mo.
Isulat ang failure at ang kinakailangang resulta. Ang halimbawang paghahambing na ito ay pantulong sa desisyon, hindi listahan ng feature para sa SwissOctet. Hinihikayat nito ang mga tanong tungkol sa mga kopya at kontrol sa halip na pag-aangkin na ang isang teknolohiya ay palaging mas mahusay. Ang aktwal na resulta ay nakasalalay sa configuration at dokumentadong proseso ng recovery ng operator.
| Senaryo | Tanong para sa snapshot | Tanong para sa backup |
|---|---|---|
| Masamang update ng application | Maaari ba akong bumalik sa nilalayong punto? | Gaano katagal ang magagamit na restore? |
| Nawala ang pangunahing disk | Umaasa ba ang kopya sa disk na iyon? | Maaari ba akong mag-restore sa bagong storage? |
| Na-compromise ang administrative account | Maaari bang tanggalin ng account na ito ang bawat kopya? | Hiwalay ba ang mga karapatan sa pagtanggal? |
| Natuklasan ang error pagkalipas ng mga linggo | Nakareten pa ba ang puntong iyon? | Sakop ba ng retention ang pagkaantala sa pagtuklas? |
Suriin ang consistency ng application
Maaaring makuha ng disk ang mga file habang binabago pa ng application ang mga ito. Depende sa software at proseso ng snapshot, ang resulta ay maaaring kumakatawan sa crash-consistent na estado sa halip na coordinated na estado ng application. Huwag ipagpalagay na ang nababasang mga file ay nangangahulugang nagkakasundo ang database at ang kaugnay na mga upload. Gamitin ang paraan ng backup na dokumentado ng application o database.
Inilalarawan ng continuous-archiving na disenyo ng PostgreSQL ang pagkakaiba: ang recovery ay nangangailangan ng angkop na base backup at tuloy-tuloy na pagkakasunod-sunod ng mga kinakailangang write-ahead log file. Ang direktoryong basta kinopya habang tumatakbo ang database ay hindi katumbas na pamamaraan. Kung nag-iimbak din ang application ng mga file sa labas ng database, planuhin kung paano sabay na mare-recover ang dalawang dataset na iyon.
Ituring ang retention bilang window ng recovery
Dapat isaalang-alang ng retention kung gaano katagal maaaring manatiling hindi napapansin ang isang error. Ang sampung araw na window ay hindi nakakatulong sa aksidenteng pagtanggal na natuklasan pagkalipas ng isang buwan. Ang pagpapanatili ng bawat kopya nang walang hanggan ay lumilikha ng ibang problema: gastos, lumalaking pagkakalantad ng sensitibong data at hindi malinaw na patakaran sa pagtanggal. Piliin ang retention mula sa konkretong operational at data-handling na mga kinakailangan.
Lagyan ng label ang mga recovery point ng kapaki-pakinabang na konteksto, tulad ng bersyon ng application at oras ng natapos na trabaho, nang hindi isinasama ang mga secret. Panatilihin ang sapat na kasaysayan para makilala ang mabuting estado mula sa nasirang estado. Bago mag-prune, kumpirmahin kung paano hinahawakan ng napiling sistema ang shared o incremental na data; ang pagtanggal ng may label na punto ay maaaring hindi katumbas ng pagtanggal ng simpleng standalone na file.
Ihiwalay ang matagumpay na trabaho mula sa na-verify na data
Ang pag-uulat ng tagumpay ng tool sa backup ay nagpapatunay na natapos ang proseso nito sa ilalim ng mga patakaran nito. Hindi nito awtomatikong pinapatunayan na napili ang lahat ng mahalagang data ng application, nananatiling buo ang bawat nakaimbak na byte o magagamit ng bagong server ang resulta. Magkaibang pagsusuri ang mga iyon. Isama sa operational plan ang kalusugan ng repository, pagsusuri ng selection at representatibong restoration.
Idinodokumento ng Restic ang pagkakaiba ng default na repository check nito at ng verification na nagbabasa ng nakaimbak na pack data. Ang buong data-reading check ay maaaring gumamit ng mas maraming oras at bandwidth. Ginagawang konkretong punto ng pagpaplano ang halimbawang iyon: magpasya kung ano talaga ang binabasa ng verification at i-budget ang gawain. Gamitin ang dokumentasyon ng tool sa halip na ipagpalagay na ang bawat command na tinatawag na check ay may parehong saklaw.
Subukan ang maliit ngunit kumpletong recovery
Isipin ang isang publikasyon na may database, mga na-upload na larawan at configuration. I-restore ang lahat ng tatlo sa isang pribadong test environment, pagkatapos buksan ang isang artikulo at i-verify ang mga attachment nito. Panatilihing naka-disable ang naka-iskedyul na mail, payment at publishing integrations habang isinasagawa ang ehersisyo. Ang pagsubok lamang sa random na text file ay makakaligtaan ang mga ugnayang nagpapahalaga sa application.
Sukatin ang oras na kailangan at itala kung aling mga credential, bersyon ng package o panlabas na dependency ang nawawala. Suriin ang mga pahintulot sa mga na-recover na file, hindi lamang ang nilalaman ng mga ito. Madalas natutuklasan ng ehersisyo sa recovery na umiiral ang data ngunit ang mga tagubilin o access na kailangan para gamitin ito ay hindi kailanman napanatili kasama ng operating plan.
Basahin ang mga opsyonal na backup bilang partikular na serbisyo
Kapag nagko-configure ng SwissOctet, tingnan ang eksaktong opsyon sa backup at panahon ng retention para sa pamilya. Itanong kung aling mga volume at data ng application ang sakop nito, kung self-service ang recovery at kung ano ang nangyayari kapag nagbago ang pangunahing configuration. Ang label ng opsyon lamang ay hindi nagpapatunay ng independiyenteng kopya, immutable na repository o database-consistent na recovery point.
Gamitin ang mga snapshot kung saan umaangkop ang mga ito sa workload at panatilihin ang mas malawak na estratehiya ng backup para sa mga failure na hindi nila sinasaklaw. Itala ang independiyenteng ruta ng recovery para sa mahalagang data, protektahan ang mga credential na makakapagbura ng mga kopya at subukan ang pamamaraan. Ang pinakamalakas na pagpipilian ay ang nakakaligtas sa tinukoy mong senaryo, hindi ang may pinaka-nakaaaliw na pangalan.
Ang iyong praktikal na checklist.
- Tukuyin kung saan nakatira ang maibabalik na data.
- Ilista ang mga failure na dapat malampasan ng kopya.
- Gumamit ng paraan ng consistency na sinusuportahan ng application.
- Piliin ang retention para sa window ng pagtuklas.
- Protektahan nang hiwalay ang mga karapatan sa pagtanggal.
- I-restore ang kumpletong application nang nakahiwalay.
Ang mga detalyeng mahalaga.
Hindi ba kailanman backup ang isang snapshot?+
Ang ilang implementasyon ng snapshot ay backup. Ang kapaki-pakinabang na pagkakaiba ay ang dependency sa storage, retention, modelo ng access at nasubok na recovery, hindi ang label lamang.
Pinapatunayan ba ng matagumpay na integrity check na gagana ang application?+
Pinapatunayan lamang nito ang sakop ng check na iyon. Subukan nang hiwalay ang restoration ng application, configuration, mga pahintulot at mga ugnayan ng data.
Dapat ko bang itago ang backup sa parehong server?+
Ang kopya sa parehong server ay maaaring makatulong sa limitadong pagkakamali ngunit nagbabahagi ng mahahalagang failure. Ang mahalagang data ay nangangailangan ng ruta ng recovery sa labas ng hangganan ng failure na nilalayon mong malampasan.
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.
- Amazon EBS: Mga Snapshot docs.aws.amazon.com
- PostgreSQL: Continuous archiving at point-in-time recovery www.postgresql.org
- Restic: Paggawa sa mga repository at integrity check restic.readthedocs.io
Editorial guidance ni SwissOctet. Ang mga halimbawa ay ilustratibo. Ang service specifications, available options at contractual conditions ay dapat beripikahin nang hiwalay.