Snímek je reprezentace stavu v určitém okamžiku, jejíž ochrana je dána jeho implementací. Zálohovací strategie přidává záměrnou retenci, oddělení přístupu a testovanou obnovu. Některé snímky jsou zálohy; jiné závisí na původním úložišti. Ptejte se, co přežije smazání, kompromitaci nebo ztrátu primárního prostředí.
Popište kopii dříve, než ji pojmenujete
Slovo snímek vám říká, že byl zachycen určitý okamžik, ale ne kde jsou obnovitelná data uložena nebo kdo je může smazat. Snímek souborového systému na původním úložišti a poskytovatelem spravovaný snímek bloku mohou mít různé hranice poruch. Začněte implementací, místo abyste označení považovali za univerzální příslib.
AWS dokumentuje snímky EBS jako inkrementální zálohy svých svazků v určitých okamžicích. To je konkrétní implementace, nikoli důkaz, že se všechny možnosti snímků chovají stejně. U každé služby se ptejte, zda obnovení závisí na původním svazku, zda kopie opouštějí primární doménu poruch a co se stane, když je zdroj odstraněn.
Porovnejte poruchy, které očekáváte, že přežijete
Rychlé vrácení po aktualizaci a obnova po ztrátě účtu jsou různé problémy. Místní snímek může být vhodný pro první případ, zatímco pro druhý nabízí jen malé oddělení. Nezávislé kopie mohou přidat ochranu, ale pouze pokud jsou jejich cesty k úložišti, přístupu a smazání dostatečně oddělené od incidentu, na který se připravujete.
Zapište poruchu a požadovaný výsledek. Toto ilustrativní srovnání je pomůcka pro rozhodování, nikoli seznam funkcí pro SwissOctet. Podporuje otázky o kopiích a kontrole, místo tvrzení, že jedna technologie je vždy lepší. Skutečný výsledek závisí na konfiguraci a dokumentovaném procesu obnovy operátora.
| Scénář | Otázka pro snímek | Otázka pro zálohu |
|---|---|---|
| Špatná aktualizace aplikace | Mohu se vrátit k zamýšlenému bodu? | Jak dlouho trvá použitelné obnovení? |
| Ztráta primárního disku | Závisí kopie na tomto disku? | Mohu obnovit na nové úložiště? |
| Kompromitace administrátorského účtu | Může tento účet smazat všechny kopie? | Jsou práva ke smazání oddělena? |
| Chyba zjištěná o týdny později | Je tento bod stále uchován? | Pokrývá retence zpoždění při zjištění? |
Zkontrolujte konzistenci aplikace
Disk může zachytit soubory, zatímco je aplikace stále mění. V závislosti na softwaru a procesu snímku může výsledek představovat stav konzistentní s pádem, nikoli koordinovaný stav aplikace. Nepředpokládejte, že čitelné soubory znamenají, že databáze a související nahrané soubory jsou v souladu. Použijte metodu zálohování dokumentovanou aplikací nebo databází.
Návrh průběžného archivování u PostgreSQL ilustruje rozdíl: obnovení vyžaduje vhodnou základní zálohu a průběžnou posloupnost požadovaných souborů write-ahead log. Adresář zkopírovaný bez rozmyslu za běhu databáze není rovnocenný postup. Pokud aplikace ukládá soubory i mimo databázi, naplánujte, jak se obě tyto datové sady obnovují společně.
Berte retenci jako okno obnovy
Retence by měla zohlednit, jak dlouho může chyba zůstat nezjištěna. Desetidenní okno nepomůže u náhodného smazání zjištěného po měsíci. Uchovávání všech kopií neomezeně vytváří jiný problém: náklady, rostoucí vystavení citlivých dat a nejasnou politiku mazání. Zvolte retenci na základě konkrétních provozních a datových požadavků.
Označte body obnovy užitečným kontextem, jako je verze aplikace a čas dokončení úlohy, ale nevkládejte do nich tajné údaje. Uchovávejte dostatek historie, abyste odlišili dobrý stav od poškozeného. Před čištěním ověřte, jak zvolený systém zachází se sdílenými nebo inkrementálními daty; smazání označeného bodu nemusí odpovídat smazání jednoduchého samostatného souboru.
Oddělte úspěšné úlohy od ověřených dat
Nástroj pro zálohování hlásící úspěch potvrzuje, že jeho proces dokončil podle svých pravidel. Automaticky to neprokazuje, že byla vybrána všechna důležitá data aplikace, že každý uložený bajt zůstává neporušený nebo že výsledek dokáže použít nový server. To jsou různé kontroly. Do provozního plánu zahrňte stav úložiště, revizi výběru a reprezentativní obnovení.
Restic dokumentuje rozdíl mezi výchozí kontrolou úložiště a ověřením, které čte uložená data pack. Úplná kontrola čtoucí data může spotřebovat více času a šířky pásma. Tento příklad konkretizuje plánovací bod: rozhodněte, co ověření skutečně čte, a naplánujte práci. Použijte dokumentaci nástroje, místo abyste předpokládali, že každý příkaz nazvaný check má stejné pokrytí.
Otestujte malou, úplnou obnovu
Představte si publikaci s databází, nahranými obrázky a konfigurací. Obnovte všechny tři do soukromého testovacího prostředí, poté otevřete článek a ověřte jeho přílohy. Během cvičení ponechte vypnuté plánované integrace pro poštu, platby a publikování. Testování pouze náhodného textového souboru by minulo vztahy, které činí aplikaci užitečnou.
Změřte potřebný čas a zaznamenejte, které přihlašovací údaje, verze balíčků nebo externí závislosti chyběly. Zkontrolujte oprávnění obnovených souborů, nejen jejich obsah. Cvičení obnovy často odhalí, že data existují, ale pokyny nebo přístup potřebné k jejich použití nebyly nikdy uchovány spolu s provozním plánem.
Čtěte volitelné zálohy jako konkrétní službu
Při konfiguraci SwissOctet se podívejte na přesnou možnost zálohování a dobu retence pro danou rodinu. Zeptejte se, které svazky a data aplikace pokrývá, zda je obnovení samoobslužné a co se stane, když se změní primární konfigurace. Samotné označení možnosti neprokazuje nezávislou kopii, neměnné úložiště ani bod obnovy konzistentní s databází.
Používejte snímky tam, kde vyhovují zátěži, a udržujte širší zálohovací strategii pro poruchy, které nepokrývají. Zaznamenejte nezávislou cestu obnovy pro důležitá data, chraňte přihlašovací údaje, které mohou kopie smazat, a postup testujte. Nejsilnější volbou je ta, která přežije váš definovaný scénář, nikoli ta s nejuklidňujícím názvem.
Váš praktický kontrolní seznam.
- Určete, kde jsou uložena obnovitelná data.
- Vypište poruchy, které musí kopie přežít.
- Použijte metodu konzistence podporovanou aplikací.
- Zvolte retenci pro okno zjištění.
- Chraňte práva ke smazání odděleně.
- Obnovte úplnou aplikaci v izolaci.
Podrobnosti, na kterých záleží.
Není snímek nikdy záloha?+
Některé implementace snímků jsou zálohy. Užitečným rozlišením je jejich závislost na úložišti, retence, model přístupu a testované obnovení, nikoli samotné označení.
Prokazuje úspěšná kontrola integrity, že aplikace bude fungovat?+
Prokazuje pouze to, co daná kontrola pokrývá. Samostatně otestujte obnovení aplikace, konfiguraci, oprávnění a vztahy mezi daty.
Mám zálohu uchovávat na stejném serveru?+
Kopie na stejném serveru může pomoci u omezených chyb, ale sdílí důležité poruchy. Důležitá data potřebují cestu obnovy mimo hranici poruchy, kterou hodláte přežít.
Jděte ke zdroji.
Tyto zdroje podporují technické koncepty v tomto průvodci. Před změnou produkčního systému se řiďte aktuální dokumentací.
- Amazon EBS: Snímky docs.aws.amazon.com
- PostgreSQL: Průběžné archivování a obnova k určitému okamžiku www.postgresql.org
- Restic: Práce s úložišti a kontrolami integrity restic.readthedocs.io
Redakční vedení od SwissOctet. Příklady jsou ilustrativní. Specifikace služeb, dostupné možnosti a smluvní podmínky je nutné ověřit samostatně.