# Muunna RPO ja RTO palautusbudjetiksi, jonka voit testata | SwissOctet Insights https://swissoctet.com/fi/insights/rpo-rto-recovery-budget/ SwissOctet / Näkemykset / Toisen päivän toiminnot Toisen päivän toiminnot Sovellettu · 4 min luku Muunna RPO ja RTO palautusbudjetiksi, jonka voit testata Muunna hyväksyttävä tietojen menetys ja keskeytys ajastetuksi palautussuunnitelmaksi, jossa on riippuvuudet, palautuskapasiteetti ja mitattava harjoitus. Kirjoittaja SwissOctet Editorial Tallenna opas Kopioi linkki TÄLLÄ SIVULLA 01 Aloita palvelusta, jota ihmiset voivat käyttää 02 Erota kaksi kelloa 03 Budjetoi palautuksen jokainen vaihe 04 Tarkista todellinen tietojen menetyksen ikkuna 05 Valitse strategia budjetin puitteissa 06 Harjoittele vaarantamatta tuotantoa 07 Pidä suunnitelma käyttökelpoisena vian aikana Käytännön tarkistuslistasi Lähteet ja lisälukemisto Takaisin kirjastoon SUORA VASTAUS RPO kuvaa tietojen menetyksen ikkunaa, jonka olet valmis hyväksymään; RTO kuvaa keskeytystä, jonka pyrit pitämään sen sisällä. Määritä molemmat hyödylliselle liiketoimintatoiminnolle ja todista sitten palautusjärjestys harjoituksessa. Pelkkä varmuuskopiointiaikataulu tai palvelinmääritys ei vahvista kumpaakaan tavoitetta. 01 Aloita palvelusta, jota ihmiset voivat käyttää Palautustavoitteista tulee hyödyllisiä, kun ne kuvaavat liiketoimintatoimintoa yksittäisen koneen sijaan. Palvelin voi käynnistyä, vaikka asiakkaat eivät vieläkään voi kirjautua sisään, noutaa tiedostoja tai suorittaa pyyntöä loppuun. Kirjoita lopputila tavallisella kielellä: valtuutetut käyttäjät voivat käyttää sovellusta ja tarvittavat tiedot ovat yhdenmukaisia. Tämä tekee tavoitteesta testattavan myös infrastruktuuritiimin ulkopuoliselle henkilölle. Kysy sovelluksen omistajalta, mitä keskeytys estäisi ja mitä puuttuvat tiedot maksaisivat. Viikoittaisella julkaisulla ja tapahtumankäsittelysovelluksella voi olla erilaiset vastaukset. Käsittele syntyviä tavoitteita suunnittelutavoitteina, ei laiteluettelosta keksittyinä lupauksina. Kirjaa, kuka ne hyväksyi ja mitkä vikaskenaariot suunnitelma kattaa. 02 Erota kaksi kelloa RPO koskee sitä, kuinka kauas taaksepäin palautetut tiedot voivat olla suhteessa häiriöön. RTO koskee sitä, kuinka kauan toiminto voi olla poissa käytöstä. Tuore varmuuskopio voi parantaa tietojen menetyksen ikkunaa, kun taas hidas palautus voi silti jäädä palautusaikatavoitteesta. Toisaalta nopea uudelleenkäynnistys voi palauttaa pääsyn sovellukseen, jonka uusimmat tiedot eivät ole säilyneet. Määritä vertailukohdat. Päätä, milloin tapahtuman kello alkaa, mikä lasketaan palautetuksi toiminnaksi ja miten käyttökelpoinen tietopiste tunnistetaan. Pidä tavoitteet erillään mitatuista tuloksista: tavoite on se, mitä tavoittelet; harjoitus näyttää, mitä nykyinen prosessi saavutti. Palaa kumpaankin, kun sovellus tai tietoaineisto muuttuu. 03 Budjetoi palautuksen jokainen vaihe Käytännöllinen RTO-budjetti sisältää havaitsemisen, arvioinnin, valtuutuksen, pääsyn palautusympäristöön, palautuksen, sovelluksen validoinnin ja uudelleenavaamisen. Tiedostojen kopiointiaika on vain yksi osa. Jos palautusavaimen haltija ei ole käytettävissä, teoreettisesti nopea varmuuskopio voi silti olla käyttökelvoton. Luettele riippuvuudet ja varmista, että palautustiimi voi tavoittaa ne tarkasteltavan vian aikana. Anna jokaiselle vaiheelle alustava aika ja korvaa sitten arviot havainnoilla. Tässä havainnollistavassa kahden tunnin budjetissa palautus saa suurimman osuuden, mutta validointiin jää silti suojattua aikaa. Luvut kuvaavat suunnitteluesimerkkiä, eivät SwissOctet-palvelun toimitusta. Jos kokonaisuudessa ei ole marginaalia, suunnittelua on parannettava ennen kuin tavoite on uskottava. Palautusvaihe Havainnollistava osuus Kerättävä todiste Havaitse ja arvioi 15 minuuttia Hälytyksen saapuminen ja tapahtumapäätös Valmistele palautusympäristö 20 minuuttia Pääsy ja kokoonpano käytettävissä Palauta tiedot ja palvelu 50 minuuttia Suoritettu palautus yhdenmukaisilla tiedoilla Validoi ja avaa uudelleen 25 minuuttia Käyttäjän polku onnistuu Varautumismarginaali 10 minuuttia Odottamaton työ kirjattu 04 Tarkista todellinen tietojen menetyksen ikkuna Joka tunti ajastettu työ ei automaattisesti tuota yhden tunnin RPO:ta. Epäonnistunut työ, viivästynyt siirto tai käyttökelvoton kopio voi tehdä viimeisimmästä palautettavasta pisteestä paljon vanhemman. Tarkkaile onnistunutta suoritusta ja tilaa, joka voidaan todella palauttaa. Jos sovelluksessa on useita tietovarastoja, varmista, että niiden palautuspisteet ovat yhteensopivia sen sijaan, että lukisit jokaista aikaleimaa erikseen. Valitse harjoituksen aikana viitetapahtuma, kuten valtuutettu testitietue, joka on luotu tunnetulla hetkellä. Tunnista palautuksen jälkeen uusin kelvollinen tietue ja mittaa ero. Käytä vaaratonta testidataa. Tämä antaa käytännöllisen tuloksen ja paljastaa oletukset, jotka vain työn onnistumisen näyttävä koontinäyttö saattaisi jättää piiloon. 05 Valitse strategia budjetin puitteissa Varmuuskopiointi ja palautus, valmiit varaympäristöt ja replikoidut sovellusmallit vaihtavat kustannuksia ja monimutkaisuutta palautusnopeuteen. Replikointi voi vähentää joitakin viiveitä, mutta voi myös toistaa vahingossa tapahtuneen poiston tai sovellusvirheen. Varaympäristö, joka on ajautunut pois toimivasta kokoonpanosta, luo oman riskinsä. Valitse strategia dokumentoimiesi vikaskenaarioiden ja tavoitteiden perusteella. Harkitse pientä palvelua, jonka tavoite on neljä tuntia, ja suurempaa tietoaineistoa, jonka pelkkä palautus kestää harjoituksessa kuusi tuntia. Nopeamman verkkoportin ostaminen on vain hypoteesi: tallennuksen luvut, vastaanottavat kirjoitukset ja sovelluksen palautus voivat hallita tilannetta. Paranna mitattua rajoittavaa vaihetta, pienennä palautusjoukkoa tai vaihda strategiaa ja harjoittele uudelleen. 06 Harjoittele vaarantamatta tuotantoa Käytä eristettyä palautusympäristöä ja määriteltyä harjoitusikkunaa. Varmista, että palautetut työt eivät voi lähettää oikeita ilmoituksia, vastaanottaa julkisia maksuja tai kirjoittaa tuotannon integraatioihin. Testaa pääsy, tietojen eheys ja edustavat käyttäjäpolut ennen kuin katsot harjoituksen valmiiksi. Ota mukaan henkilö, joka ei kirjoittanut alkuperäistä menettelyä, jotta puuttuvat ohjeet paljastuvat. Pidä aikajanaa harjoituksesta, saavutetusta palautuspisteestä ja jokaisesta keskeytyksestä, jonka puuttuva tieto aiheutti. Hyödyllinen raportti ilmoittaa mitatun tuloksen, eron tavoitteeseen ja konkreettisen korjaavan toimenpiteen. Toista merkityksellisten muutosten jälkeen ja projektin tärkeyteen sopivin väliajoin. 07 Pidä suunnitelma käyttökelpoisena vian aikana Säilytä palautusmenettelyä paikassa, johon tiimi pääsee käsiksi ilman, että se on kokonaan epäonnistuneen sovelluksen varassa. Pidä tunnistetiedot ja salausavaimet suojatussa paikassa, jossa on testattu käyttöoikeusprosessi. Päivitä yhteystiedot, tietoaineistojen koot ja riippuvuudet projektin kehittyessä. Vanhentunut suunnitelma voi kuluttaa aikamarginaalin ennen kuin palautus edes alkaa. Kun vertailet SwissOctet-kokoonpanoja, erota palautusarkkitehtuurisi luettelon valinnaisista varmuuskopiointivaihtoehdoista. Varmista, mitä vaihtoehto kattaa, missä palautustiedot säilytetään ja kuka suorittaa palautuksen. Luettelo ei vahvista sovelluksen RPO:ta tai RTO:ta. Mitattu prosessisi ja todelliset palveluehdot muodostavat perustan tälle päätökselle. MUUNNA SE TOIMINNAKSI Käytännön tarkistuslistasi. ✓ Määritä palautettu liiketoimintatoiminto. ✓ Hyväksy erilliset RPO- ja RTO-tavoitteet. ✓ Budjetoi havaitseminen, pääsy, palautus ja validointi. ✓ Mittaa uusin käyttökelpoinen tietopiste. ✓ Harjoittele eristetyssä ympäristössä. ✓ Kirjaa puutteet ja toista olennaisten muutosten jälkeen. Lataa tarkistuslista YLEISET KYSYMYKSET Olennaiset yksityiskohdat. Onko RTO sama kuin käytettävyysaika? + Ei. RTO on palautustavoite keskeytysskenaariolle. Käytettävyysaika mittaa saatavuutta tietyllä ajanjaksolla; toinen ei vahvista toista. Takaako tunneittainen varmuuskopiointi yhden tunnin RPO:n? + Ei. Tarkista valmiit, käyttökelpoiset kopiot ja sovelluksen yhdenmukaisuusvaatimukset. Epäonnistuneet työt ja viivästyneet siirrot voivat kasvattaa palautettavissa olevien tietojen eroa. Täytyykö jokaisen projektin käyttää varapalvelinta? + Valitse strategia projektin palautustavoitteiden ja mitatun palautusprosessin perusteella. Varapalvelin lisää kustannuksia ja toiminnallista monimutkaisuutta, eikä se ole automaattisesti tarpeen. ENSISIJAISET LÄHTEET Mene lähteelle. Nämä lähteet tukevat tämän oppaan teknisiä käsitteitä. Noudata ajantasaisia dokumentaatioita ennen tuotantojärjestelmän muuttamista. NIST SP 800-34 Rev. 1: Contingency Planning Guide nvlpubs.nist.gov AWS Well-Architected: Määritä palautustavoitteet docs.aws.amazon.com Microsoft Learn: Liiketoiminnan jatkuvuus, korkea käytettävyys ja katastrofipalautus learn.microsoft.com Toimituksellinen ohjaus: SwissOctet. Esimerkit ovat havainnollistavia. Palvelumääritykset, saatavilla olevat vaihtoehdot ja sopimusehdot on tarkistettava erikseen. YHDISTÄ TIETO Aiheeseen liittyvä infrastruktuuri. Vector VPS Sveitsi Vault Storage Sveitsi Metal Atlas Sveitsi PIDÄ LANGANPÄÄ Seuraavat kenttämuistiinpanosi. Tutustu kaikkiin oppaisiin KENTTÄMUISTIINPANO / 01 + Toisen päivän toiminnot Sovellettu Rakenna varmuuskopio, jonka voit todella palauttaa Valitse palautustavoite, suojaa riippumaton kopio ja harjoittele palauttamista ennen kuin häiriö pakottaa asian. 4 min luku Lue opas KENTTÄMUISTIINPANO / 02 + Toisen päivän toiminnot Sovellettu Käytännön uhkamalli isännöidylle projektillesi Kartoita omaisuus ja luottamusrajat, valitse muutama realistinen vikaskenaario ja muunna ne kontrolleiksi, joita voit testata. 6 min lukuaika Lue opas KENTTÄMUISTIINPANO / 03 + Toisen päivän toiminnot Sovellettu Turvallinen Windows RDP -ylläpito menettämättä pääsyä Erota verkon tavoitettavuus, todennus ja käyttöoikeudet ja varmista sitten palautusreitti ennen etäkäytön kiristämistä. 6 min lukuaika Lue opas