RTO RPO: mennyibe kerül valójában a két szám

Az RTO RPO páros két különböző kérdésre válaszol: meddig állhat a működés és mennyi munka veszhet el. Az RTO — helyreállítási idő célkitűzés — az incidenstől előre futó óra addig a pillanatig, amíg a kollégák újra dolgozni tudnak. Az RPO — helyreállítási pont célkitűzés — visszafelé fut: az utolsó pillanat, amikor az adat még tiszta volt, és minden, ami utána történt, elveszett. Két külön szám, két külön dolgot kell vásárolni értük — és a Microsoft 365, a Google Workspace, a Slack és az Atlassian Cloud esetében a szervezetek többsége egyiket sem állította be. A platform állította be helyettük, alapértelmezés szerint, és a valódi értékek először egy incidens közben válnak láthatóvá.

A két fogalom pontos jelentése

Mindkét kifejezés a formális üzletmenet-folytonossági szakirodalomból származik, nem a szállítóktól — érdemes tudni, amikor egy szállító lazán bánik velük. A NIST szójegyzéke a NIST SP 800-34 Rev. 1 alapján így határozza meg őket:

Recovery time objective (RTO): az az összesített időtartam, ameddig egy információs rendszer komponensei a helyreállítási fázisban lehetnek anélkül, hogy az negatívan érintené a szervezet küldetését, illetve üzleti folyamatait.

Recovery point objective (RPO): az az időpont, amelyre az adatokat egy kiesés után vissza kell állítani.

Két dolog következik ebből, és mindkettőn könnyű átsiklani. Az egyik, hogy mindkettő célkitűzés: azt rögzíti, mit kíván meg az üzlet, nem azt, amire az eszközei éppen képesek. Leírni pontosan azért érdemes, hogy össze lehessen vetni a valósággal, és látszódjon a rés. A másik, hogy az RTO meghatározása üzleti hatásra hivatkozik, nem technológiára. Az RTO nem az, hogy „milyen gyorsan tudunk visszaállítani", hanem az, hogy „mennyi idő múlva kezd ez valóban fájni".

A gyakorlatra fordítva:

• Az RPO arra válaszol: ha visszaállunk, mennyi munka tűnik el? A 24 órás RPO azt jelenti, hogy Önök elfogadják akár egy nap elvesztését.
• Az RTO arra válaszol: meddig korlátozott vagy áll a működés? A négyórás RTO azt jelenti, hogy elfogadnak egy fél munkanapnyi kiesést.

A kettőt külön kell megvásárolni. A szorosabb RPO ára a sűrűbb helyreállítási pont. A szorosabb RTO ára a gyorsabb és begyakorolt visszaállítási útvonal. Az egyikre költött pénz a másikon nem javít — ezért keveredik a két fogalom, és ezért drága a keveredés.

RTO RPO: miért ez a különbség dönti el, mire van szüksége

Vegyünk két szervezetet, ugyanazzal a zsarolóvírus-incidenssel.

Az elsőnél az üzleti tárgyalások e-mailben zajlanak egy forgalmas Exchange Online bérlőben. Négy óra levelezés elvesztése komoly üzleti kár: nekik szoros RPO kell. Az, hogy egy napig csak olvasni tudnak, miközben helyreáll a rend, elviselhető.

A másodiknál az ügyfélszolgálat Slackben és Jirában dolgozik. Egy óra üzenet elvesztése kellemetlenség. Az, hogy egy napig nem tudnak dolgozni, olyan kiesés, amit az ügyfelek észrevesznek, és amit a szolgáltatási megállapodás akár szankcionálhat is: nekik szoros RTO kell.

Ugyanaz az incidens, két különböző beszerzés. Ennek a felcserélése a leggyakoribb tervezési hiba ezen a területen — és érdemes látni, hogy egy mentési termék közvetlenül mindig csak az egyiket adja el. A helyreállítási pont funkció. A helyreállítási idő nagyrészt a visszaállítási útvonal, a méret és a gyakorlottság tulajdonsága.

Mit ad valójában a Microsoft 365

A négy platform közül egyedül a Microsoft teszi közzé mindkét számot, és ezt el kell ismerni: a Microsoft 365 Backup kiegészítő dokumentációjában a funkciótáblázat egyik sorának címe egyenesen „Restore speeds (RTO)".

Az RPO oldalán a Microsoft OneDrive és SharePoint esetében 10 perces helyreállítási pontokat dokumentál a megelőző két hétre, majd heti pillanatfelvételeket a 2–52. hétre, Exchange Online esetében pedig 10 perces pontokat a megelőző teljes 52 hétre. Ezt érdemes figyelmesen olvasni, mert a görbe alakja többet mond a főszámnál. Két héten belül a OneDrive RPO-ja tíz perc. Három hétnél viszont már egy hét: egy heti pillanatfelvételre visszaállva akár hét napnyi változás vész el. Az Exchange Online a teljes évre megtartja a tízperces bontást, ami érezhetően erősebb garancia, mint amit a fájlalapú munkaterhek kapnak.

Maga a helyreállítási ablak mentési szabályzatonként állítható 3 hónapra, 6 hónapra, 1 évre vagy 2 évre, a meglévő szabályzatok alapértelmezése pedig 1 év.

Az RTO oldalán a Microsoft medián visszaállítási várakozásokat tesz közzé, nem ígéretet: egyetlen OneDrive- vagy SharePoint-egység nagyjából 30 perc alatt egy express helyreállítási ponttal (azzal a megjegyzéssel, hogy egyetlen egység visszaállítása mérettől függően durván 10 és 120 perc között szóródik), egyetlen Exchange-postafiók nagyjából két óra, 250 egység három–négy óra, 1000 egység felett pedig óránként legfeljebb 250 védelmi egység. A postafiókok elemszintű helyreállítását percenként nagyjából 100–500 elemre teszi.

Számolja végig a saját bérlőjére, mielőtt késznek tekinti a védelmet. Kétezer postafiók ezekkel az ütemekkel nem egy délután. És vannak dokumentált plafonok is: munkaterhenként legfeljebb 1 000 000 elem, mentési szabályzatonként legfeljebb 100 000 elem.

Egy részlet, amely az RTO-beszélgetésbe tartozna, mégis ritkán kerül szóba. A OneDrive- és SharePoint-visszaállítást a dokumentáció olyan visszagörgetésként írja le, amely felülír minden tartalmat és metaadatot, ami az adott korábbi időpont óta keletkezett — a fájlszintű, verzió alapú visszaállítás pedig „hamarosan" jelöléssel szerepel. A visszaállítás tehát nem fájl-, hanem site-méretű: a tegnapi zsarolóvírus-esemény helyreállítása a ma délelőtti jogos munkát is eldobhatja. Ez inkább tervezési döntés, mint hiba, de megváltoztatja, mit jelent a „helyreállt" szó — és a tervbe való, nem az incidensbe. A kiegészítő tágabb korlátait a Microsoft 365 mentésről szóló írásban vettük végig.

A másik három platform egyáltalán nem ad RPO-t

Ez az a pont, amely a legtöbb szervezetet meglepi, és egyenesen következik abból, ahogyan a natív helyreállítás működik.

A natív SaaS-helyreállítás nem időpont alapú. Lomtár, határidővel. Nem mondhatja azt, hogy „állítsa vissza ezt a Google Drive-ot a 9:00-s állapotára"; azt állíthatja vissza, amit töröltek, ha az ablakon belül van, és ha be tudja azonosítani. Az RPO tehát nem is időtartam — hanem esemény. A törlés előtti pillanatra áll vissza, vagy sehogy.

Zsarolóvírus ellen, amely nem töröl, hanem felülír, ez a különbség döntő: a titkosított fájl nem törölt fájl, hanem a fájl új verziója — így gyakran nincs is mit visszaállítani a lomtárból.

• A Google Workspace korlátozott ablakot ad a rendszergazdáknak egy törölt felhasználó adatainak visszaállítására, dátumtartományként és nem elemenként, a Vault pedig exportál, nem állít vissza. A négy lehetséges útvonalat és hiányosságaikat külön írásban vettük végig.
• A Slack és az Atlassian Cloud exportot ad: időbélyeges fájlt, amelyhez nem tartozik visszaállítási útvonal a termékbe. Az RPO az export futtatásának pillanata. Az RTO pedig annyi, amennyi idő alatt egy ember kézzel újraépíti a munkaterületet — ez nem olyan szám, amelyre bárki kötelezettséget vállalhat.

Ha az Önök katasztrófa-helyreállítási dokumentuma ma RPO-t és RTO-t rögzít ezekre a munkaterhekre, akkor vágyat rögzít. A becsületes változat vagy a valós számokat írja le, vagy azt, hogy a kitűzött értékekhez független másolat kell — és itt lesz a zsarolóvírus helyreállítási terv papírmunkából valódi terv.

A kompromisszum, ami sosem kerül a diára

Az izoláció és a helyreállítási idő egymás ellen dolgozik, és az érvet maga a Microsoft mondja ki: a saját, szolgáltatáshatáron belüli mentésének gyorsaságát azzal szemben hirdeti, hogy az adatokat „egy távoli, air gap-es helyről nagy mennyiségben másolva hetekbe vagy akár hónapokba telhet visszaállítani a működést".

Kezelje a megfogalmazást a helyénvaló fenntartással — egy szállító érvel a saját architektúrája mellett —, de a mögöttes fizika valós. A bérlőhöz közel tartott másolat gyorsan visszaáll, és osztozik a bérlő sorsában. A távol tartott másolat túléli a bérlő sorsát, és tovább tart hazahozni. Pontosan ez a feszültség jelenik meg az air gap mentésről szóló írásban, most az RTO felől nézve.

Ezért kell a két számot együtt meghatározni. Aki csak az RTO-ra optimalizál, gyors másolatokat kap a kárterületen belül. Aki csak az izolációra, érintetlen másolatot kap és kéthetes visszaállítást. Egyik sem terv.

Hogyan határozzon meg értelmes számokat

1. Munkaterhenként állítsa be, ne cégszinten. A levelezés, a fájlok, a csevegés és a feladatkövetés tűréshatára valóban különbözik. Az egyetlen, céges szintű RTO olyan szám, amelyet senki nem vállal magáénak.
2. Üzleti hatásból induljon ki, ne az eszközeiből. Először azt határozza meg, mikortól válik valódivá a kár; utána mérje meg a távolságot a jelenlegi képességtől. Ha a célt a meglévő képességből vezeti le, mindig teljesíteni fogja — és semmit nem tud meg.
3. Írja a célok mellé a mai tényleges értékeket. A legtöbb natív SaaS-környezetben az őszinte bejegyzés az RPO oszlopban „az utolsó törlési esemény", az RTO oszlopban pedig „ismeretlen".
4. Egységeket számoljon, ne gigabájtokat. A közzétett visszaállítási ütemek a site-ok, fiókok és postafiókok számával skálázódnak. A legrosszabb eset a bérlő egészét érintő esemény — így is kell méretezni.
5. Az RTO-t tesztelje, mert csak ezt lehet észrevétlenül elrontani. Az RPO dokumentációból ellenőrizhető. Az RTO viszont állítás a szervezetről nyomás alatt, és erre az egyetlen bizonyíték a próba.

Hol jövünk mi a képbe

Nem mi vagyunk a platform, és nem mi üzemeltetjük az Ön bérlőjét. Amit csinálunk: ezt a kérdést munkaterhenként két olyan számmá alakítjuk, amellyel az üzlet is egyetért — mennyi lehet a helyreállítási pont és a helyreállítási idő, mit adnak ma a natív ablakok, és hol a rés —, majd segítünk kiválasztani a rendszeréhez illő megoldást, és üzembe helyezni. Onnantól Ön birtokolja és üzemelteti.

Ha a jelenlegi RTO- és RPO-értékei inkább feltételezések, mint mérések, egy helyreállítási felmérés végigveszi a munkaterheit, az egyes ablakok mögötti dokumentált korlátokat, és azt, hogy egy valósághű, bérlőszintű visszaállítás mennyi időt venne igénybe.