# Mga snapshot at backup: piliin ang failure na kailangan mong malampasan | SwissOctet Insights https://swissoctet.com/fil/insights/snapshots-backups-consistency/ SwissOctet / Mga Insight / Imbakan at pagbawi Imbakan at pagbawi Praktikal · 4 minutong pagbasa Mga snapshot at backup: piliin ang failure na kailangang malampasan Ihambing ang mga recovery point, failure boundary at consistency ng application sa halip na ipagpalagay na ang snapshot at independiyenteng backup ay nagbibigay ng parehong proteksyon. Ni SwissOctet Editorial I-save ang gabay Kopyahin ang link SA PAHINANG ITO 01 Ilarawan ang kopya bago ito pangalanan 02 Ihambing ang mga failure na inaasahan mong malampasan 03 Suriin ang consistency ng application 04 Ituring ang retention bilang window ng recovery 05 Ihiwalay ang matagumpay na trabaho mula sa na-verify na data 06 Subukan ang maliit ngunit kumpletong recovery 07 Basahin ang mga opsyonal na backup bilang partikular na serbisyo Ang iyong praktikal na checklist Mga pinagmulan at karagdagang babasahin Bumalik sa library ANG DIREKTANG SAGOT 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. 01 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. 02 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? 03 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. 04 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. 05 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. 06 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. 07 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. GAWIN ITONG AKSYON 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. I-download ang checklist MGA KARANIWANG TANONG 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. MGA PANGUNAHING SANGGUNIAN 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. IKONEKTA ANG KAALAMAN Kaugnay na infrastructure. Vault Storage Switzerland Pulse NVMe Switzerland Metal Zenith Switzerland PANATILIHIN ANG SINULID Ang iyong susunod na field notes. Tuklasin ang bawat gabay TALA SA PRAKTIKA / 01 + Imbakan at pagbawi Pundasyon Kung kailan may pagkakaiba ang NVMe sa iyong application Ibahin ang capacity, latency at throughput upang ang mas mabilis na storage label ay sumagot sa tunay na problema ng application. 4 minutong pagbasa Basahin ang gabay TALA SA PRAKTIKA / 02 + Imbakan at pagbawi Abansado Sukatin ang performance ng NVMe nang hindi nililinlang ang sarili Tukuyin ang I/O pattern, kontrolin ang cache effect at suriin ang latency distribution bago gumawa ng konklusyon sa application mula sa disk test. 6 min na pagbabasa Basahin ang gabay TALA SA PRAKTIKA / 03 + Imbakan at pagbawi Pundasyon Object, file o block storage: piliin ang interface na kailangan ng iyong aplikasyon Ibahin ang mga interface ng imbakan, semantika ng access at mga responsibilidad sa pagpapatakbo bago gawing arkitektura ng aplikasyon ang isang kinakailangan sa kapasidad. 4 minutong pagbasa Basahin ang gabay