Inilalarawan ng RPO ang window ng pagkawala ng data na handa kang tanggapin; inilalarawan ng RTO ang pagkaantala na nilalayon mong panatilihin sa loob ng hangganan. Tukuyin ang pareho para sa isang kapaki-pakinabang na business function, pagkatapos patunayan ang pagkakasunod-sunod ng recovery sa isang pagsasanay. Ang iskedyul ng backup o detalye ng server lamang ay hindi nagtatatag ng alinman sa layunin.
Magsimula sa isang serbisyong magagamit ng mga tao
Nagiging kapaki-pakinabang ang mga layunin sa recovery kapag inilalarawan nila ang isang business function sa halip na isang hiwalay na makina. Maaaring mag-boot ang isang server habang hindi pa rin makapag-sign in, makakuha ng file o makumpleto ng mga customer ang isang kahilingan. Isulat ang kondisyon ng pagtatapos sa ordinaryong wika: ang mga awtorisadong user ay makaka-access sa application at ang kinakailangang data ay pare-pareho. Ginagawa nitong masusubok ang target ng isang tao sa labas ng infrastructure team.
Itanong sa may-ari ng application kung ano ang pipigilan ng isang pagkaantala at ano ang halaga ng nawawalang data. Ang isang lingguhang publikasyon at isang application na nagpoproseso ng transaksyon ay maaaring may magkaibang sagot. Ituring ang mga resultang layunin bilang mga target sa pagpaplano, hindi mga pangakong naimbento mula sa catalogue ng hardware. Itala kung sino ang nag-apruba sa mga ito at kung aling mga senaryo ng pagkasira ang saklaw ng plano.
Ihiwalay ang dalawang orasan
Ang RPO ay tungkol sa kung gaano kalayo pabalik ang na-recover na data na maaaring nauugnay sa pagkaantala. Ang RTO ay tungkol sa kung gaano katagal maaaring manatiling hindi available ang function. Ang isang kamakailang backup ay maaaring mapabuti ang window ng pagkawala ng data habang ang mabagal na restore ay hindi pa rin umabot sa target na oras ng recovery. Sa kabaligtaran, ang mabilis na reboot ay maaaring magbalik ng access sa isang application na ang pinakabagong data ay hindi nakaligtas.
Tukuyin ang mga reference point. Magpasya kung kailan magsisimula ang orasan ng insidente, ano ang itinuturing na naibalik na operasyon at kung paano makikilala ang magagamit na data point. Panatilihing hiwalay ang mga target sa mga nasusukat na resulta: ang layunin ay ang hinahanap mo; ang pagsasanay ay nagpapakita ng nakamit ng kasalukuyang proseso. Balikan ang alinman kapag nagbago ang application o dataset.
Badyetin ang bawat hakbang ng recovery
Kasama sa isang praktikal na badyet ng RTO ang pagtuklas, pagtatasa, awtorisasyon, pag-access sa recovery environment, pagpapanumbalik, pagpapatunay ng application at muling pagbubukas. Ang oras ng pagkopya ng file ay isang bahagi lamang. Kung ang taong may hawak ng recovery key ay hindi available, ang isang teoretikal na mabilis na backup ay maaaring hindi pa rin magamit. Ilista ang mga dependency at tiyakin na maaabot ng recovery team ang mga ito sa panahon ng pagkasirang isinasaalang-alang.
Magtalaga ng pansamantalang oras sa bawat hakbang, pagkatapos palitan ang mga pagtatantya ng mga obserbasyon. Sa ilustratibong dalawang oras na badyet na ito, ang pagpapanumbalik ay tumatanggap ng pinakamalaking allotment ngunit ang pagpapatunay ay may protektadong oras pa rin. Inilalarawan ng mga numero ang isang halimbawa ng pagpaplano, hindi ang paghahatid ng serbisyo ng SwissOctet. Kung ang kabuuan ay walang margin, kailangan ng pagpapabuti ang disenyo bago maging kapani-paniwala ang layunin.
| Hakbang sa recovery | Ilustratibong allotment | Ebidensyang kokolektahin |
|---|---|---|
| Tuklasin at tasahin | 15 minuto | Pagdating ng alerto at desisyon sa insidente |
| Ihanda ang recovery environment | 20 minuto | Available ang access at configuration |
| Ibalik ang data at serbisyo | 50 minuto | Nakumpletong restore na may pare-parehong data |
| Patunayan at muling buksan | 25 minuto | Nagtagumpay ang paglalakbay ng user |
| Margin para sa contingency | 10 minuto | Naitala ang hindi inaasahang gawain |
Suriin ang tunay na window ng pagkawala ng data
Ang trabahong naka-iskedyul bawat oras ay hindi awtomatikong naghahatid ng isang oras na RPO. Ang nabigong trabaho, naantalang upload o hindi magamit na kopya ay maaaring gawing mas luma ang pinakabagong maibabalik na punto. Obserbahan ang matagumpay na pagkumpleto at ang estado na talagang maibabalik. Para sa isang application na may ilang data store, kumpirmahin na compatible ang kanilang mga recovery point sa halip na basahin ang bawat timestamp nang hiwalay.
Pumili ng reference event sa panahon ng pagsasanay, tulad ng isang awtorisadong test record na ginawa sa alam na oras. Pagkatapos ng pagpapanumbalik, tukuyin ang pinakabagong valid na record at sukatin ang agwat. Gumamit ng hindi mapanganib na test data. Nagbibigay ito ng praktikal na resulta at naglalantad ng mga palagay na maaaring itago ng dashboard na nagpapakita lamang ng tagumpay ng trabaho.
Pumili ng estratehiya sa loob ng badyet
Ang backup-and-restore, inihandang standby environment at replicated application design ay nagpapalitan ng gastos at pagiging kumplikado kapalit ng bilis ng recovery. Ang replication ay maaaring magbawas ng ilang pagkaantala ngunit maaari ring magparami ng aksidenteng pagtanggal o pagkakamali sa application. Ang standby na nalihis mula sa gumaganang configuration ay lumilikha ng sarili nitong panganib. Pumili ng estratehiya batay sa mga senaryo ng pagkasira at layuning naidokumento mo.
Isaalang-alang ang isang maliit na serbisyo na may apat na oras na target at isang mas malaking dataset na ang restore lamang ay tumatagal ng anim na oras sa isang pagsasanay. Ang pagbili ng mas mabilis na network port ay isang hypothesis lamang: ang pagbasa ng storage, pagtanggap ng writes at recovery ng application ay maaaring mangibabaw. Pagbutihin ang nasusukat na hakbang na naglilimita, bawasan ang recovery set o baguhin ang estratehiya, pagkatapos magsanay muli.
Magsanay nang hindi isinasapanganib ang production
Gumamit ng hiwalay na recovery environment at tinukoy na window ng pagsasanay. Tiyakin na ang mga naibalik na trabaho ay hindi makakapagpadala ng tunay na notification, tumatanggap ng pampublikong bayad o sumusulat sa production integration. Subukan ang access, integridad ng data at mga kinatawan ng paglalakbay ng user bago ituring na kumpleto ang pagsasanay. Isama ang isang taong hindi sumulat ng orihinal na pamamaraan upang ilantad ang mga nawawalang tagubilin.
Panatilihin ang timeline ng pagsasanay, ang nakamit na recovery point at bawat pagkaantalang dulot ng hindi available na impormasyon. Ang kapaki-pakinabang na ulat ay nagsasaad ng nasusukat na resulta, ang agwat sa layunin at isang tiyak na corrective action. Ulitin pagkatapos ng makabuluhang pagbabago at sa pagitan na angkop sa kahalagahan ng proyekto.
Panatilihing magagamit ang plano sa panahon ng pagkasira
Itago ang pamamaraan ng recovery kung saan maa-access ito ng team nang hindi umaasa lamang sa nabigong application. Panatilihin ang mga credential at encryption key sa protektadong lokasyon na may nasubok na proseso ng pag-access. I-update ang mga contact, laki ng dataset at dependency habang umuunlad ang proyekto. Ang lipas na plano ay maaaring ubusin ang margin ng oras bago pa man magsimula ang pagpapanumbalik.
Kapag inihahambing ang mga configuration ng SwissOctet, ihiwalay ang iyong recovery architecture mula sa mga opsyonal na pagpipilian sa backup ng catalogue. Kumpirmahin kung ano ang saklaw ng isang opsyon, saan hawak ang recovery data at sino ang nagsasagawa ng pagpapanumbalik. Hindi nagtatatag ang catalogue ng RPO o RTO ng application. Ang iyong nasusukat na proseso at ang aktwal na mga tuntunin ng serbisyo ang nagbibigay ng batayan para sa desisyong iyon.
Ang iyong praktikal na checklist.
- Tukuyin ang naibalik na business function.
- Aprubahan ang magkahiwalay na target na RPO at RTO.
- Badyetin ang pagtuklas, pag-access, restore at pagpapatunay.
- Sukatin ang pinakabagong magagamit na data point.
- Magsanay sa hiwalay na environment.
- Itala ang mga agwat at ulitin pagkatapos ng kaugnay na pagbabago.
Ang mga detalyeng mahalaga.
Pareho ba ang RTO at uptime?+
Hindi. Ang RTO ay target sa recovery para sa isang senaryo ng pagkaantala. Sinusukat ng uptime ang availability sa isang panahon; hindi nagtatatag ang isa sa isa pa.
Ginagarantiya ba ng oras-oras na backup ang isang oras na RPO?+
Hindi. Suriin ang mga nakumpleto at magagamit na kopya at ang mga kinakailangan sa consistency ng application. Ang mga nabigong trabaho at naantalang paglilipat ay maaaring magpalawak ng agwat ng maibabalik na data.
Dapat bang gumamit ng standby server ang bawat proyekto?+
Pumili ng estratehiya batay sa mga layunin sa recovery ng proyekto at nasusukat na proseso ng restore. Ang standby ay nagdaragdag ng gastos at pagiging kumplikado sa pagpapatakbo at hindi awtomatikong kailangan.
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.
- NIST SP 800-34 Rev. 1: Gabay sa Pagpaplano ng Contingency nvlpubs.nist.gov
- AWS Well-Architected: Tukuyin ang mga layunin sa recovery docs.aws.amazon.com
- Microsoft Learn: Business continuity, high availability at disaster recovery learn.microsoft.com
Editorial guidance ni SwissOctet. Ang mga halimbawa ay ilustratibo. Ang service specifications, available options at contractual conditions ay dapat beripikahin nang hiwalay.