Záloha je užitečná pouze tehdy, pokud zůstane dostupná v okamžiku, kdy původní systém nelze použít. Právě tento jednoduchý princip je důvodem, proč off-site zálohování patří do každé seriózní strategie obnovy po havárii. Druhá kopie na stejném serveru, NAS nebo v jednom racku může pomoci při náhodném smazání, ale příliš nepomůže, když požár, krádež, povodeň, ransomwarový útok nebo kompromitace administrátora zasáhne celé prostředí.
Off-site zálohování vytváří fyzický i logický odstup mezi produkčními daty a jejich kopií pro obnovu. Pro firmu může toto oddělení znamenat rozdíl mezi obnovením serveru během několika hodin a jeho rekonstrukcí z neúplných záznamů během několika dní. Mění také způsob, jakým společnost o zálohovací strategii přemýšlí: nejde jen o rutinní kopírování souborů, ale o provozní opatření podporující kontinuitu podnikání.
To je důležité zejména pro agentury a malé firmy, které samy spravují webové, aplikační, databázové, virtualizační nebo zákaznicky orientované servery. Tyto organizace možná nemají velký infrastrukturní tým, ale čelí stejným typům selhání jako větší podniky. Pokud je produkční server pod kontrolou zákazníka, musí být jeho zálohy chráněny stejně pečlivě jako samotný server.
Co off-site zálohování skutečně znamená
Off-site zálohování je kopie firemních dat uložená na jiném fyzickém místě, než se nachází chráněný systém. Kopie může být v jiné budově, samostatném datovém centru nebo vyhrazeném úložném prostředí v jiném regionu. Důležitá není pouze vzdálenost měřená v kilometrech. Záloha musí být od produkčního prostředí oddělena tak, aby jedna událost nemohla snadno zničit, zašifrovat nebo smazat obě kopie.
Typický proces zálohování serveru podle plánu zachycuje vybraná data, stav systému, aplikace nebo kompletní obrazy počítače. Výsledná záloha se obvykle přenáší mimo produkční lokalitu přes šifrované spojení. Poté se uchovává po stanovenou dobu a v případě potřeby je k dispozici pro obnovu.
Kvalitní off-site záloha má několik odlišných vlastností:
- Oddělení lokality: Záloha není závislá na stejných prostorách, racku, napájení ani lokálním úložišti jako produkce.
- Oddělení přístupu: Běžní administrátoři serveru nemohou automaticky měnit nebo odstranit každou kopii určenou k obnově.
- Důvěrnost: Data jsou šifrována při přenosu i v klidovém stavu a je jasně určeno, kdo spravuje dešifrovací klíč.
- Retence: Zálohy zůstávají dostupné dostatečně dlouho, aby pokryly provozní chyby, pozdě odhalené problémy a požadavky vyplývající z předpisů nebo smluv.
- Obnovitelnost: Organizace ví, jak data získat, a ověřila, zda je obnovený systém použitelný.
Tyto vlastnosti spolu souvisejí, ale nelze je zaměňovat. Off-site kopie, kterou může administrátor smazat stejnými přihlašovacími údaji jako produkční server, je sice geograficky oddělená, ale není dobře izolovaná. Silně šifrovaná záloha, kterou nikdo nedokáže dešifrovat, je v jednom smyslu bezpečná, ale v krizi nepoužitelná. Dlouhá retenční doba nenahradí zálohu, která nikdy nebyla obnovena a může být neúplná.
Proč samotná lokální kopie nestačí
Lokální zálohování je stále cenné. Může nabídnout rychlou cestu k obnově smazaného souboru, poškozené databáze nebo vadného disku. Obnova z úložiště ve stejné budově bývá často rychlejší než stahování velkého obrazu serveru přes internet. Lokální kopie proto mohou tvořit důležitou vrstvu širší zálohovací strategie.
Problém nastává, když je lokální kopie považována za celý plán obnovy po havárii. Produkční systémy a lokální zálohy často sdílejí stejná rizika:
Selhání hardwaru
Disky selhávají, RAID pole degradují a zálohovací zařízení mohou mít poruchy. Pokud produkční i zálohovaná data využívají stejný subsystém úložiště, může jediný incident s hardwarem zasáhnout obě kopie. I když je záloha na samostatném lokálním zařízení, výpadek napájení nebo problém s prostředím může poškodit produkční server i zařízení obsahující data pro obnovu.
Krádež a fyzická ztráta
Server a jeho lokální zálohovací zařízení jsou při vloupání atraktivním cílem. Přenosné disky lze snadno odnést a útočník nemusí datům rozumět, pokud lze hardware prodat nebo použít jako prostředek k vydírání. Fyzická ztráta také vytváří riziko pro důvěrnost, pokud zálohy nejsou správně šifrovány.
Požár, povodeň a další události zasahující celou lokalitu
Požár, prasklé potrubí, silná bouře nebo evakuace budovy mohou současně znepřístupnit všechna zařízení v serverovně. Lokální záloha může být zcela v pořádku, ale přesto nebude dostupná, pokud do prostor nelze vstoupit. Obnova po havárii předpokládá, že samotná primární lokalita může být nedostupná, nikoli jen to, že selhal jeden disk.
Ransomware a destruktivní malware
Ransomware často cílí na připojená úložiště, namapované disky a rozhraní pro správu záloh. Pokud je lokální záloha stále připojená a dostupná pomocí kompromitovaného administrátorského účtu, malware ji může zašifrovat nebo smazat společně s produkčními daty. Záloha, která existuje pouze jako další zapisovatelný cíl ve stejném prostředí, není spolehlivou poslední obrannou linií.
Kompromitovaní administrátoři a odcizené přihlašovací údaje
Ne každý destruktivní incident začíná malwarem. Odcizené privilegované heslo, zneužitý účet nebo náhodně spuštěný příkaz může odstranit produkční data i jejich lokální kopie. Zálohy potřebují ochranu před stejnými přihlašovacími údaji a vztahy důvěry, které řídí chráněné systémy. Jinak může útočník ovládající server ovládat také možnosti obnovy.
Při porovnávání lokálního a off-site zálohování v rámci strategie obnovy po havárii není praktická otázka, zda je lokální záloha užitečná. Jde o to, zda má organizace alespoň jednu kopii, která zůstane mimo dosah incidentu zasahujícího celou lokalitu i kompromitovaného produkčního prostředí.
Porovnání lokálních, off-site a cloudových kopií
Výrazy lokální, off-site a cloudové popisují různé aspekty návrhu zálohování. Neměly by být chápány jako vzájemně se vylučující kategorie a samotné označení „cloud“ nedokazuje, že je záloha izolovaná nebo obnovitelná.
Lokální zálohování
Lokální záloha je uložena v blízkosti chráněného serveru, například na druhém disku, NAS, vyměnitelném disku nebo zálohovacím zařízení ve stejných prostorách. Její hlavní výhodou je rychlost. Lokální obnova může být praktická, když firma potřebuje rychle jediný soubor nebo nedávnou kopii databáze.
Jejími slabinami jsou vystavení rizikům a závislost na lokalitě. Lokální kopie může zasáhnout požár, krádež, povodeň, problém s napájením, ransomware i kompromitace administrátora. Během stěhování lokality nebo modernizace hardwaru se na ně také může zapomenout. Lokální zálohu je nejlepší chápat jako rychlou vrstvu obnovy, nikoli jako jediný mechanismus obnovy po havárii.
Off-site zálohování
Off-site záloha je uložena mimo produkční lokalitu a měla by být chráněna samostatnými přístupovými pravidly. Je určena pro situace, kdy lokálnímu prostředí nelze důvěřovat nebo k němu nelze získat přístup. Dobře navržená off-site služba může malým organizacím nabídnout také strukturovaný způsob správy retence, šifrování a postupů obnovy, aniž by si musely budovat vlastní druhé zařízení.
Off-site záloha se může obnovovat pomaleji než lokální kopie v závislosti na dostupné kapacitě připojení, objemu dat a způsobu obnovy. Tento kompromis je přijatelný, pokud alternativou po incidentu zasahujícím celou lokalitu není žádná použitelná kopie. Službu je třeba vybírat s ohledem na požadovanou dobu obnovy, nikoli pouze podle místa uložení.
Cloudové zálohování
Cloudové zálohování znamená, že jsou zálohovaná data uložena v infrastruktuře přístupné přes síť, často v datovém centru provozovaném poskytovatelem. Může být off-site, ale tyto dva pojmy nejsou totožné. Cloudová záloha může být stále špatně izolovaná, pokud ji mohou produkční přihlašovací údaje smazat, pokud lze bez ochrany měnit její retenci nebo pokud jsou všechny kopie ve stejné doméně selhání.
Při hodnocení cloudové nebo hostované zálohovací služby se ptejte, kde jsou data uložena, kdo k nim může přistupovat, jak jsou spravovány šifrovací klíče, zda jsou zálohy neměnné a jak probíhá obnova. „V cloudu“ je model poskytování, nikoli úplná bezpečnostní specifikace.
Jak přístup 3-2-1 podporuje obnovu po havárii
Přístup 3-2-1 zůstává užitečným základem zálohovací strategie:
- 3 kopie dat: produkční kopie a nejméně dvě záložní kopie.
- 2 různé typy úložiště nebo médií: menší závislost na jedné technologii nebo typu selhání.
- 1 kopie mimo lokalitu: ochrana před ztrátou primárního místa.
Model je záměrně jednoduchý. Podporuje organizace v tom, aby neumísťovaly všechny kopie na stejný server, diskové pole nebo do stejné budovy. Zároveň ponechává prostor pro pokročilejší opatření, například neměnné úložiště, offline kopie a samostatné administrátorské identity.
Moderní výklad často přidává další „1“: jedna kopie by měla být izolovaná nebo neměnná. Neměnnost znamená, že zálohovaná data nelze během stanovené ochranné doby změnit ani smazat, i když dojde ke kompromitaci účtu nebo produkčního serveru. Je zvlášť důležitá pro odolnost proti ransomwaru a pro incidenty, při nichž se útočník pokouší vymazat důkazy nebo odstranit body obnovy.
Neměnnost neznamená, že každá záloha zůstane zachována navždy. Obvykle platí po nakonfigurované retenční období. Po jeho skončení může záloha podle pravidel automaticky vypršet. Proto musí být nastavení retence promyšlené a nesmí zůstat pouze pohodlným výchozím nastavením.
RPO a RTO: jak proměnit cíle obnovy v rozhodnutí o zálohování
Frekvence zálohování a návrh obnovy by měly vycházet z požadavků firmy. Dvě metriky pomáhají převést tyto požadavky do praktických rozhodnutí: cíl bodu obnovy neboli RPO a cíl doby obnovy neboli RTO.
Cíl bodu obnovy
RPO popisuje, kolik aktuálních dat si může firma po incidentu dovolit ztratit. RPO 24 hodin může znamenat, že organizace akceptuje ztrátu jednoho dne transakcí nebo aktualizací. RPO jedna hodina vyžaduje častější zachytávání a přenos. RPO v řádu minut může vyžadovat jinou architekturu než běžné plánované zálohy serveru.
RPO není pouze nastavení v zálohovací konzoli. Závisí na tom, jak často zálohy běží, zda úlohy úspěšně dokončí práci, jak rychle lze data přenést a zda jsou zdrojová data konzistentní. Záloha databáze pořízená během zápisu transakcí nemusí poskytnout čistý bod obnovy, pokud není aplikace správně obsloužena.
Cíl doby obnovy
RTO popisuje, jak rychle musí být služba po výpadku obnovena. Malá interní aplikace může tolerovat denní odstávku. Agentura hostující zákaznické aplikace nebo firma zpracovávající objednávky může potřebovat výrazně kratší dobu obnovy.
RTO ovlivňuje typ zálohy i proces obnovy. Obnovení kompletního obrazu serveru může být rychlejší než instalace operačního systému a každé aplikace od začátku, stále však vyžaduje vhodnou cílovou infrastrukturu. Služba s náročným RTO může potřebovat předem naplánovanou náhradní kapacitu, zdokumentované změny DNS nebo sítě a otestovaný postup pro opětovné spuštění závislostí ve správném pořadí.
RPO a RTO by měly být přiřazeny jednotlivým službám, nikoli odhadnuty pro celou organizaci. Databáze, web, souborový server a interní monitorovací systém mohou mít odlišné priority. Sepsání těchto priorit pomáhá malé firmě zaměřit úsilí tam, kde by odstávka a ztráta dat způsobily největší škody.
Retence je součástí návrhu obnovy
Retence určuje, jak daleko do minulosti se může organizace vrátit při obnově. Měla by zohledňovat více než jen interval mezi dvěma zálohami. Firmy často odhalí poškození dat, neoprávněné změny nebo náhodné smazání až několik dní či týdnů po původní události. Pokud zálohovací systém uchovává jen několik posledních kopií, může každý bod obnovy obsahovat stejný problém.
Rozumná retenční politika zohledňuje:
- Jak dlouho může zůstat náhodné smazání bez povšimnutí.
- Jak dlouho může malware zůstat skrytý před odhalením.
- Smluvní, regulační nebo klientské požadavky.
- Stáří dat potřebných pro finanční, provozní nebo právní šetření.
- Náklady na úložiště a přenos při uchovávání starších bodů obnovy.
- Zda jsou potřeba různé denní, týdenní nebo měsíční body obnovy.
Retence by měla odpovídat také povaze serveru. Vývojový server může potřebovat krátkodobé body obnovy, zatímco produkční databáze nebo úložiště klientských projektů může vyžadovat delší historii. Pravidla by měla být zapsána srozumitelným jazykem, aby osoba odpovědná za obnovu věděla, co ve skutečnosti poskytuje „30 dní“ nebo „12 měsíců“.
Neměnnost dává retenčnímu období větší význam, protože brání změně bodů obnovy v době, kdy jsou potřeba. Neodstraňuje však nutnost monitorování. Úloha zálohování může být technicky dokončena, přesto může vynechat požadovaný svazek, používat nesprávný plán nebo vytvořit data, která nelze obnovit.
Šifrování a otázka, kdo drží klíč
Off-site data je třeba chránit nejen před zničením, ale také před neoprávněným zveřejněním. Šifrování pomáhá zajistit, aby odcizený disk, zachycený přenos nebo nesprávně zpřístupněné úložiště neodhalily firemní či zákaznické informace.
Existují dvě samostatné otázky týkající se šifrování. Za prvé: jsou data šifrována při cestě ze zákazníkova serveru do umístění zálohy? Za druhé: jsou šifrována během uložení? Obojí je důležité. Šifrování při přenosu nechrání uloženou zálohu, která je čitelná pro neoprávněné operátory, a šifrování v klidovém stavu nechrání data odesílaná přes nezabezpečené spojení.
Stejně důležité je vlastnictví klíče. Pokud jediný dešifrovací klíč drží poskytovatel, může mít zákazník omezenou kontrolu nad důvěrností. Pokud klíč spravuje zákazník a poskytovatel ho nikdy nemá, míra vystavení se snižuje, ale odpovědnost se stává vážnější: zákazník musí klíč chránit a zajistit, aby ho oprávnění pracovníci mohli v případě potřeby použít.
Vzniká tak praktická rovnováha. Kontrola nad klíčem může podpořit silnější oddělení zálohovací služby od chráněných dat, ale ztracený klíč může obnovu znemožnit. Správa klíčů proto musí být zdokumentována, přístup omezen a postup obnovy musí vysvětlovat, jak oprávněný tým klíč během mimořádné události získá a použije. Šifrování nenahrazuje provozní plánování.
Proč neměnnost a izolace mění obnovu po ransomwaru
Obnova po ransomwaru není jen otázkou existence nedávné kopie. Jde o to mít kopii, kterou útočník po získání kontroly nad produkčním prostředím nemohl zašifrovat ani smazat.
Izolace omezuje cesty, jimiž se útočník může dostat k zálohovaným datům. Užitečná opatření zahrnují samostatné přihlašovací údaje, omezený síťový přístup, omezená rozhraní pro správu a úložiště, do kterého chráněný server nemůže nepřetržitě zapisovat. Tato opatření snižují pravděpodobnost, že kompromitovaný administrátorský účet ovlivní každou vrstvu systému obnovy.
Neměnnost přidává pravidlo, které po stanovenou dobu brání změnám zálohovaných objektů. Pokud se útočník pokusí smazat nedávné body obnovy, pravidla úložiště je mohou uchovat až do konce retenčního období. Organizace tak získá čas incident identifikovat, omezit jeho dopady a vybrat čistý bod obnovy.
Žádné z těchto opatření samo o sobě nezaručuje úspěšnou obnovu. Útočník může zdroj kompromitovat ještě před vytvořením zálohy nebo může organizace zjistit, že záloha vynechala kritickou aplikaci. Testování obnovy je proto zásadní. Firma by měla vědět, které body obnovy jsou k dispozici, jak se k nim dostat, jak poskytnout šifrovací klíč a jak ověřit obnovený server před jeho opětovným připojením do produkce.
Co to znamená pro agentury a malé firmy
Agentury a malé firmy často spravují infrastrukturu s omezeným počtem pracovníků. Jeden člověk může mít na starosti klientské projekty, aktualizace serverů, přístupy uživatelů, monitoring i upozornění na zálohy. Technické prostředí může zahrnovat hostingový ovládací panel, virtuální stroje, databáze, repozitáře zdrojového kódu, sdílené složky a několik zákaznických služeb.
Tato koncentrace odpovědnosti vytváří praktická rizika. Úloha zálohování může být jednou nastavena a poté ignorována. Upozornění mohou chodit do staré schránky. Bývalý spolupracovník může mít stále přístup. Lokální NAS může být plný. Obraz serveru může existovat, ale nikdo nemusí vědět, zda ho lze obnovit na náhradní hardware.
Off-site zálohování pomáhá tím, že odděluje kopii pro obnovu od každodenní správy serveru. Neodstraňuje potřebu kompetentního řízení, může však snížit počet kritických bodů selhání. Agentuře také poskytuje věrohodnější odpověď ve chvíli, kdy se klient zeptá, jak by po vážném incidentu obnovila jeho aplikaci, databázi nebo projektová data.
Prvním krokem pro firmy provozující produkční servery je určit, co musí být obnoveno a v jakém pořadí. Webová aplikace může záviset na databázi, objektovém úložišti, záznamech DNS, tajných klíčích, certifikátech a externích integracích. Záloha, která obnoví pouze webové soubory, nemusí obnovit celou službu. Plán obnovy by měl tyto závislosti zdokumentovat a rozlišovat mezi obnovou dat a obnovou kompletní služby.
Safenix je určen pro servery kontrolované zákazníkem. Poskytuje off-site zálohování firemních serverů, data ukládá v Německu, šifruje je pomocí klíče, který Safenix nikdy nedrží, a zachovává je neměnná po dobu nastaveného retenčního období. Není to zálohovací plán pro web běžící na sdíleném hostingu. Zákazník musí mít kontrolu nad chráněným serverem; účet na sdíleném hostingu neposkytuje stejnou úroveň přístupu k serveru ani kontroly nad zálohováním.
Hodnocení off-site zálohovací služby
Správná služba musí odpovídat systémům, cílům obnovy a odpovědnostem firmy. Cena je důležitá, ale nízké náklady na úložiště nepomohou, pokud není jasná obnova nebo pokud přístupový model poskytovatele oslabuje izolaci.
Při hodnocení možností off-site zálohování pro firmou kontrolované servery, retenci a testování obnovy se ptejte, jak služba odpovídá požadovanému RPO a RTO, kde jsou data uložena, kdo kontroluje šifrovací klíče a jak se uplatňuje neměnná retence. Ověřte, že je služba navržena pro servery, které firma skutečně spravuje, a nepředpokládejte, že web na sdíleném hostingu lze zapojit stejným způsobem.
Stručný kontrolní seznam
- Rozsah: Dokáže služba chránit operační systémy, aplikace, databáze a datové svazky, na kterých záleží?
- Umístění: Je místo uložení jasné a poskytuje smysluplné oddělení od produkční lokality?
- Šifrování: Jsou data šifrována při přenosu i v klidovém stavu? Kdo vytváří, kontroluje a chrání dešifrovací klíč?
- Izolace: Může kompromitovaný administrátor serveru smazat nebo změnit všechny zálohy?
- Neměnnost: Jsou body obnovy neměnné po celé nastavené retenční období?
- Retence: Dokáže politika pokrýt pozdě odhalené problémy, požadavky klientů a RPO organizace?
- Obnova: Jak se obnovují soubory, databáze a celé servery a jaká infrastruktura je k tomu zapotřebí?
- Testování: Může firma provést test obnovy bez čekání na skutečný incident?
- Provoz: Kdo dostává upozornění na selhání, kontroluje je a reaguje, když se zálohovací úloha nedokončí?
- Odpovědnost: Které úkoly patří poskytovateli a které zůstávají na zákazníkovi?
Plánování prvního testu obnovy
První test obnovy nemusí být dramatickým cvičením simulujícím zničení celé lokality. Měl by být kontrolovaný, zdokumentovaný a odpovídat skutečné obchodní potřebě. Cílem je prokázat, že organizace dokáže ze zálohy získat použitelná data nebo použitelný server.
- Vyberte realistický scénář. Například zvolte náhodné smazání kritické složky, poškození databáze nebo ztrátu produkčního serveru.
- Definujte očekávaný výsledek. Uveďte, který bod obnovy bude použit, jaká data musí být k dispozici a jak rychle má test skončit.
- Ověřte přístupy a klíče. Zajistěte, aby se oprávněný pracovník pro obnovu mohl připojit k zálohovací službě a měl požadovaný šifrovací klíč prostřednictvím zdokumentovaného postupu.
- Použijte izolovaný cíl. Obnovte data na testovací server nebo do prostředí, které nemůže přepsat produkci ani zbytečně zpřístupnit obnovená data.
- Ověřte více než pouhou existenci souborů. Zkontrolujte oprávnění, konzistenci databáze, spuštění aplikace, konfiguraci, závislosti a reprezentativní uživatelské scénáře.
- Změřte výsledek. Zaznamenejte čas potřebný k nalezení bodu obnovy, přenosu dat, dokončení obnovy a zprovoznění služby.
- Zdokumentujte problémy a aktualizujte plán. Opravte chybějící přihlašovací údaje, nejasné instrukce, síťová omezení, nekompatibilní hardware nebo nereálné předpoklady.
Po úspěšné technické obnově proveďte také obchodní kontrolu. Dostanou se ke znovuobnovenému systému správní lidé? Jsou zákaznické záznamy čitelné? Fungují naplánované úlohy, integrace a certifikáty? Odpovídají obnovená data požadovanému okamžiku? Server, který naběhne, nemusí být službou, která se skutečně obnovila.
Začlenění off-site zálohování do kontinuity podnikání
Kontinuita podnikání závisí na více než na tom, že jsou data uložena někde jinde. Vyžaduje dohodnutý sled rozhodnutí pro pokračování klíčových operací v době, kdy běžná infrastruktura není dostupná. Off-site záloha poskytuje jeden z nejdůležitějších stavebních kamenů: kopii pro obnovu oddělenou od události, která zasáhla produkci.
Proces by měl propojit technická nastavení zálohování s obchodními prioritami. Určete kritické služby, přiřaďte RPO a RTO, nastavte retenci podle rizika pozdního odhalení a zdokumentujte, kdo může obnovu schválit. Uveďte kontaktní údaje, inventář serverů, závislosti a umístění instrukcí k šifrovacím klíčům. Dokumentaci uchovávejte tak, aby byla dostupná i při výpadku primárního prostředí.
Po významných změnách plán přezkoumejte. Nová databáze, větší úložný svazek, migrovaná aplikace nebo změna klientské smlouvy mohou ovlivnit délku zálohování a potřebnou retenci. Změny personálu mohou také ovlivnit, kdo dokáže reagovat. Zálohovací strategie, která odpovídala firmě před dvěma lety, už nemusí podporovat její současné pracovní zatížení.
Nejlepší návrh obvykle kombinuje rychlou lokální obnovu s izolovanou off-site kopií. Lokální úložiště může rychle řešit běžné incidenty, zatímco neměnná off-site záloha chrání před událostmi, které lokální úložiště nepřežije. Pravidelné testy obnovy pak obě vrstvy propojí se skutečným procesem obnovy.
Praktický standard zálohování serveru
Spolehlivé řešení pro server kontrolovaný firmou by mělo jasně odpovědět na pět otázek:
- Kolik aktuálních dat si firma může dovolit ztratit?
- Jak rychle se musí vrátit každá důležitá služba?
- Kde je uložena kopie pro obnovu a může ji zasáhnout stejný incident?
- Může ji kompromitovaný administrátor změnit nebo zničit?
- Kdy proběhl poslední úspěšný test obnovy a co prokázal?
Pokud jsou odpovědi neurčité, může mít firma zálohy, ale nikoli skutečnou obnovu po havárii. Off-site zálohování řeší problém umístění, avšak o důvěryhodnosti kopie v nejkritičtější chvíli rozhodují izolace, šifrování, retence a testování.
Pro agentury a malé firmy není taková úroveň přípravy přehnaná. Jeden produkční server může zajišťovat zákaznický portál, internetový obchod, interní pracovní postup nebo aplikaci generující příjmy. Jeho ochrana znamená plánovat běžné chyby i vzácné katastrofy. Lokální kopie může obnovu urychlit, ale off-site, šifrovaná a neměnná kopie poskytuje firmě realistickou cestu zpět v situaci, kdy bylo lokální prostředí kompromitováno nebo ztraceno.