Ugrás a tartalomra 
Ragaszkodom egy világos 3-2-1 biztonsági mentési stratégia web hosting a Web hosting biztonsági mentés, Helyszínen kívüli biztonsági mentés, változtathatatlanság, RPO, RTO, GDPR és rendszeres helyreállítási tesztek, hogy ellenőrzött módon túlélhessem a kieséseket. Mérhető célokat és nyomon követhető folyamatokat követelek, hogy a 3-2-1 biztonsági mentési szabály ne csak papíron létezzen, hanem vészhelyzetben gyorsan eredményt hozzon.
Központi pontok
- 3-2-1 szabályHárom másolat, két adathordozó, egy másolat külső helyszínen - plusz egy nem módosítható biztonsági másolat extraként.
- FrekvenciaNapi biztonsági mentések, óránkénti adatbázissal kapcsolatos biztonsági mentések, verziókezelés és PITR.
- MegváltozhatatlanságA WORM/Object Lock megakadályozza a támadók általi törlést vagy felülírást.
- RPO/RTOAz egyértelmű célkitűzések és a tesztelt helyreállítási útvonalak minimalizálják az állásidőt és az adatvesztést.
- ÁtláthatóságJegyzőkönyvek, SLA, költségtisztaság és rendszeres helyreállítási tesztek.
Mit jelent a 3-2-1 a webtárhelyeken?
Legalább három példányt tervezek: a Eredeti tárhelyen, egy második biztonsági másolat egy másik adathordozón és egy harmadik másolat egy másik helyen. Offsite-helyszín. A két különböző tárolótípus csökkenti a hardver, a tárolóillesztőprogramok vagy a zsarolóprogramok miatti egyidejű meghibásodás kockázatát. A földrajzilag különálló másolat védelmet nyújt az adatközponti problémák, tűzszakaszhibák és adminisztrátori hibák ellen. A 3-2-1-1-1-0 kiterjesztésre is támaszkodom: egy megváltoztathatatlan másolat (WORM) és az ellenőrző összeg hibája nélküli biztonsági másolatok. Így a helyreállítási esélyeim magasak maradnak, még akkor is, ha a termelési rendszer teljesen veszélybe került.
Ellenőrző lista: Mit követelek a hostertől
Teljes biztonsági másolatokat kérek a következőkről Fájlok, Adatbázisok és e-mailek - következetesen, megfelelő dömperekkel vagy pillanatképek nyugalomba helyezésével, hogy az alkalmazások tisztán álljanak helyre. Következetes adatbázis-biztosítások nélkül elveszítek tranzakciókat vagy sérült táblákat. Ellenőrzöm, hogy rendelkezésre állnak-e az óránkénti adatbázis-biztosítások és a napi fájlrendszer-biztosítások. A MySQL/MariaDB esetében a verziókezelés és a point-in-time restore (PITR) ennek része számomra. Ez az egyetlen módja annak, hogy megbízhatóan teljesíthessem a szigorú RPO-célokat.
Szükségem van offsite redundanciára egy másik adatközpontban vagy egy független szolgáltatónál, hogy egyetlen szervezet se váljon Egyetlen Pont a kudarc. Ha a tárhelyem több régióval rendelkezik, másolatot kérek egy másik tűzzónában. Alaposan megvizsgálom a fizikai elkülönítést, a hálózati útvonalakat és a közigazgatási határokat. Egy második szervezet a külső másolathoz csökkenti a gyakori félrekonfigurálások kockázatát. Azt is megkérdezem, hogy az offsite tárolóhely valódi megváltoztathatatlanságot biztosít-e.
Ragaszkodom a megváltoztathatatlan biztonsági mentésekhez a Megváltozhatatlanság/WORM, hogy megakadályozza, hogy a zsarolóprogramok és a működési hibák töröljék az adatokat. Az objektumzár megőrzéssel és opcionális jogi várakoztatással megakadályozza a felülírást a záridőszak lejártáig. Dokumentálom a megőrzési logikát, hogy tudjam, vészhelyzetben meddig mehetek vissza. Ez megvéd engem a bennfentes fenyegetésekkel szemben is. A különösen kritikus adatok esetében hosszabb megőrzési időszakokat használok.
A biztonsági másolatok nem futhatnak ugyanazokkal az adminisztrátori fiókokkal, mint a termelő rendszer, ezért van szükségem a Legkevésbé Privilege és elkülönített számlák. Az MFA/2FA kötelező, a szerepek szigorúan elkülönülnek, és a kulcsok biztonságosak. Ellenőrzöm, hogy a szolgáltató kínál-e külön projekteket vagy bérlőket. A biztonsági mentési és visszaállítási műveletekhez auditnaplókat kérek. Ez lehetővé teszi számomra, hogy a manipulációt és a jogosulatlan hozzáférést korai szakaszban észleljem.
Mindenhol érvényesítem a titkosítást: TLS tranzitban és erős titkosítás nyugalmi állapotban, ideális esetben a saját Kulcsok. A helyszíneknek meg kell felelniük a GDPR-nak, és alá kell írnom egy adatvédelmi nyilatkozatot, hogy biztosítsam, hogy a feldolgozás megfelel a jogszabályoknak. Dokumentálom a megőrzési időszakokat a megfelelőségi követelményeknek megfelelően. A metaadatokat és az indexeket is titkosított formában kell tárolni. Ez megakadályozza az információ kiszivárgását a fájlneveken és struktúrákon keresztül.
RPO és RTO helyes beállítása
Meghatározok egy maximálisan megengedett adatveszteséget (RPO) és a maximális helyreállítási idő (RTO), és mindkettőt rögzítse a szerződésben. Üzletek és portálok esetében gyakran 1 órás RPO-nak van értelme; kevés tranzakciót tartalmazó CMS esetében 4-6 óra is elegendő. A 4 órás RTO sok projekt esetében reális; a kritikus platformoknak gyorsabb célokat kell kitűzniük. Egyértelmű időcélok nélkül senki sem tervezi megfelelően a költségvetést és az architektúrát. A helyreállítási gyakorlatok bizonyítják, hogy a célok elérhetők-e.
| Aspect | A leírás a | Tipikus érték | Ellenőrzés/tesztelés |
|---|---|---|---|
| RPO | Maximálisan tolerálható Adatvesztés | 1 óra (DB a PITR-rel) | Binlogok, időbélyegek, visszaállítás egy adott időpontra |
| RTO | Maximális Helyreállítási idő amíg produktív | 4 óra | Játszmafüzetek, stopperóra, protokoll |
| Tárolás | Verziók és megtartás Napok | 7/30/90 | Terv, életcikluspolitika, költségáttekintés |
| Vizsgálati gyakoriság | Rendszeres Visszaállítás-tesztek | havonta/negyedévente | Jelentés, hash-ellenőrzés, képernyőképek |
Dokumentálom, hogyan gyűjtöm a mért értékeket, és milyen eszközöket használok. E nélkül az átláthatóság nélkül az RPO/RTO elméleti marad, és vészhelyzetben nem segít. Azt is rögzítem, hogy mely komponensek kritikusak, és ezért prioritásként állítom helyre őket. Az adatbázisok esetében megfelelően definiálom a PITR-t és biztosítom a binlogokat. A médiafájlok esetében verziószámozásra és egyértelmű megőrzésre van szükségem.
Az offsite és a megváltoztathatatlanság gyakorlati megvalósítása
A harmadik példányt következetesen egy másik Régió vagy egy független szolgáltatóhoz, hogy a tűzfalak, az adminisztrátori fiókok és a számlázás elkülönüljön. Az objektumtárolás aktivált megváltoztathatatlansággal (pl. Object Lock) megakadályozza a megőrzésen belüli törlést. Ellenőrzöm a régiók elkülönítését, és ellenőrzöm, hogy a szolgáltató különböző tűzvédelmi zónákat használ-e. Jó bevezetést nyújt a kompakt áttekintés a 3-2-1 szabály a vendéglátásban. Ez kiküszöböli annak kockázatát, hogy a hibás konfiguráció minden példányt érint.
Én csak offsite biztonsági mentéseket viszek át titkosított formában és a saját Kulcsok vagy jelszavak. A hozzáférési adatokat is elkülönítem, hogy a webszerver megsértése ne nyissa meg automatikusan a külső tárhelyet. Külön IAM-szerepköröket és MFA-t alkalmazok. A törlési védelmet érthető módon dokumentálom, hogy az ellenőrzések kiértékelhessék. Csak néhány személy jogosult a megőrzés módosítását kérni.
Biztonság: hozzáférés, titkosítás, GDPR
Szigorúan elkülönítem a hozzáféréseket, és csak a biztonsági mentéseknek adom meg a minimális szükséges jogok. Nincs azonos root fiók, nincs közös jelszó, nincsenek közös kulcsok. Az MFA-t a szolgáltatónál és a saját felhőfiókjaimnál is érvényesítem. Az adatokat kliens- vagy szerveroldalon biztonságos eljárásokkal titkosítom. Ez minimálisra csökkenti annak kockázatát, hogy egy tolvaj kiolvassa a tartalmat a tárolóeszközökről.
Figyelek a GDPR-kompatibilitásra Helyszínek és egyértelmű célhoz kötni az adatvédelmi megállapodást. Ellenőrzöm, hogy a naplók tartalmaznak-e személyesnek tekinthető metaadatokat. Írásban rögzítem a megőrzési és törlési koncepciókat. Érthető folyamatokra van szükségem az információkérések és törlések esetében. Így jogilag biztonságban vagyok, és elkerülhetők a bírságok.
Visszaállítási teszt: gyakorolja a rendszeres helyreállítást
Nemcsak elméletileg tesztelem a helyreállítást, hanem rendszeresen végzek is. Visszaállítás-gyakorlatok egy izolált előkészítő környezeten. Időket mérek, dokumentálom a lépéseket és kijavítom az akadályokat. Összehasonlítom a fájlok ellenőrző összegeit és ellenőrzöm az alkalmazás konzisztenciáját funkcióellenőrzéssel. Visszaállítom az adatbázisokat egy kívánt időpontra (PITR) és ellenőrzöm a tranzakciókat. Csak ez a dokumentum mutatja meg, hogy az RPO/RTO reális-e.
Készen vannak a játékkönyvek: Hol vannak a hozzáférési adatok, hogyan lépjek kapcsolatba a támogatással, mely rendszerek élveznek prioritást. Leírom a sorrendet: Először az adatbázis, aztán a fájlok, majd a konfigurációk. Megőrzöm a fontos Jelszavak offline. Minden teszt után frissítem a dokumentációt és az időpontokat. Így nem lepődöm meg egy valódi vészhelyzetben.
Hogyan építsd fel a saját 3-2-1 beállításodat
Tartom magam a struktúrához: produktív adatok a Webszerver, második másolat egy NAS-ra vagy más tárolóba, harmadik másolat a helyszínen, megváltoztathatatlanul. Fájlokhoz restic vagy BorgBackup deduplikációval és titkosítással. Adatbázisokhoz mysqldumpot, logikai biztonsági mentéseket konzisztens zárakkal vagy Percona XtraBackupot használok. Átvitelre az rclone-t használom sávszélességkorlátozással és ismétlésekkel.
A megtartást a JRC szerint tervezem (napi/heti/havi), és elegendő időt foglalok le. Memória a verziókezeléshez. A Cronjobs vagy a CI szervezi a mentéseket és ellenőrzéseket. A felügyelet e-mailben vagy webhookkal jelzi a hibákat. Ez a cikk a következők tömör kategorizálását tartalmazza Biztonsági mentési stratégiák a web hostingban. Így megtarthatom az irányítást, még akkor is, ha a tárhelyszolgáltatóm keveset kínál.
Automatizálás és felügyelet
Automatizálom az összes visszatérő Lépések és dokumentálja a pontos parancsokat. A szkriptek ellenőrzik a kilépési kódokat, a hash-okat és az időbélyegeket. A sikertelen biztonsági mentések azonnali riasztást váltanak ki. A naplókat központilag és manipulációbiztosan tárolom. Korlátozom a sávszélességet és állapotellenőrzéseket végzek a külső célponton.
Az API-hozzáférést, az SFTP/rsync és S3-kompatibilis végpontokat megbeszélem a hosztolóval, hogy független visszaállítási útvonalakat használhassak. Feljegyzem a kilépési és visszaállítási szolgáltatások költségeit, hogy a végén ne érjenek meglepetések. Ellenőrzöm, hogy az önkiszolgáló visszaállítások lehetségesek-e az egyes Fájlok és teljes körű elszámolások állnak rendelkezésre. Ha nem, akkor saját eszközöket tervezek. Ezzel vészhelyzetben időt takarítok meg.
Gyakori hibák - és hogyan kerüljük el őket
Soha nem támaszkodom egyetlen Másolás vagy ugyanabban a tárolórendszerben. A pillanatfelvételek önmagukban nem elegendőek számomra, ha nem offsite és nem megváltoztathatatlanok. Az adatbázisok konzisztenciáját ellenőrzöm ahelyett, hogy csak úgy kimásolnám a fájlokat. A naptáram része a megfigyelés és a visszaállítási tesztek. A nem egyértelmű tárolás vagy a hiányzó verziókezelés vészhelyzetben hosszú leállási időt okoz.
Azt is ellenőrzöm, hogy a helyreállítási költségek átláthatóak-e, és hogy a helyreállítást nem késleltetik-e díjak. Kerülöm a megosztott admin-fiókokat, és mindenhol MFA-t használok. Feljegyzem a kulcsok rotációjára vonatkozó eljárásokat. Legalább negyedévente elvégzek egy Teszt-Restore keresztül. Az ezekből a gyakorlatokból származó hibák beáramlanak a játékkönyveimbe.
SLA, átláthatóság és költségek
A biztonsági architektúra a következővel van meg Diagramok és folyamatok. Ez magában foglalja a felügyeleti jelentéseket, a riasztási útvonalakat és a válaszidőket. A 24/7-es vészhelyzeti kapcsolattartást kérem, és olyan időablakokat kérek, amelyekben a helyreállítások prioritást élveznek. Egyértelmű költségtáblázatokat követelek a tárolásra, a kijutásra és a szolgáltatásokra vonatkozóan is. Ha ez hiányzik, további puffereket tervezek a költségvetésbe.
Kritikus projektek esetén a biztonsági mentéseket kombinálom DR-forgatókönyvek és az egyetlen hibapontok elkerülése. Itt érdemes megnézni Katasztrófa-helyreállítás szolgáltatásként, ha csökkenteni akarom a failover-időket. Dokumentálom az eszkalációs láncokat és a tesztelési dátumokat. Redundáns kapcsolattartási csatornákat is fenntartok. Így biztosítom, hogy vészhelyzetben senki sem erősíti meg a hiányzó felelősséget.
Mit kell még biztonsági mentést készíteni - a fájlokon és adatbázisokon kívül?
Nemcsak a webrootot és az adatbázist, hanem a platformomat alkotó összes komponenst is biztosítom. Ez magában foglalja a DNS zónákat, TLS tanúsítványokat, cronjobokat, webszerver és PHP konfigurációkat, .env fájlokat, API kulcsokat, SSH kulcsokat, WAF/firewall szabályokat, átirányításokat és e-mail szűrőket. Exportálok csomaglistákat, composer/npm lockfile-okat és alkalmazáskonfigurációkat is. A levelek esetében a maildir mappák teljes biztonsági mentésére, valamint az aliasok és a szállítási szabályok külön exportálására támaszkodom. Több fiókos tárhely esetén a panelkonfigurációkról is készítek biztonsági másolatot, hogy a teljes fiókokat nyomon követhető módon visszaállíthassam.
Tudatos döntéseket hozok arról, hogy mit nem biztonságos: Kihagyom a gyorsítótárakat, munkameneteket, ideiglenes feltöltéseket és generálható artefaktumokat (pl. optimalizált képek), hogy költségeket takarítsak meg és lerövidítsem a visszaállítási időt. A keresési indexek vagy finomabb cache-ek esetében dokumentálom, hogy visszaállítás esetén hogyan épülnek fel automatikusan újra.
A tartalékolási módszerek és topológiák összehasonlítása
Minden munkaterheléshez a megfelelő módszert választom: A logikai dömperek (pl. mysqldump) hordozhatóak, de több időt vesznek igénybe. A fizikai forró biztonsági mentések (pl. pillanatkép-mechanizmusokon keresztül) gyorsak és konzisztensek, de megfelelő tárolási funkciókat igényelnek. Ahol lehetséges, nyugalomba helyezést (fsfreeze/LVM/ZFS) és biztonságos InnoDB binlogokat használok a valódi PITR-hez. A fájlmentésekhez a deduplikációval kiegészített inkrementális örökre történő mentésre támaszkodom.
Döntés a push és pull topológia között: pull esetén a biztonsági mentést egy mentési kiszolgáló kezdeményezi, és csökkenti a veszélyeztetett forrásrendszerek kockázatát. Push esetén az alkalmazáskiszolgálók maguk kezdeményezik a biztonsági mentéseket - ez egyszerűbb, de szigorú IAM elkülönítést és kilépési ellenőrzéseket igényel. Az ügynökalapú módszerek nagyobb konzisztenciát kínálnak, az ügynök nélküli módszerek egyszerűbben üzemeltethetők. Dokumentálom a választásomat és a kockázatokat.
Granularitás és helyreállítási útvonalak
Többféle helyreállítást tervezek: egyedi fájlok, mappák, egyedi táblák/adatrekordok, teljes adatbázisok, postafiókok, teljes webtárhely-fiókok. CMS/shop rendszerek esetében a „DB először, aztán a feltöltések/média, majd a konfiguráció“ prioritást tartom szem előtt. Készen van egy kék/zöld megközelítésem: visszaállítás a stagingben, validálás, majd ellenőrzött váltás. Ez minimalizálja az állásidőt és csökkenti a meglepetéseket a produktív működés során.
Gondoskodom arról, hogy az önkiszolgáló helyreállítások lehetségesek legyenek: A felhasználók önállóan kiválaszthatnak egy verziót, kereshetnek időpontokat és célzottan visszaállíthatják azokat. Vészhelyzetekre készenlétben tartok egy „üvegszilárdságú“ folyamatot: Vészhelyzeti hozzáférés naplózással, időkorlátozással és a kettős ellenőrzés elvén alapulva.
Integritás, ellenőrző összegek és csendes adatrongálás
Csak a végponttól végpontig tartó integritással rendelkező biztonsági mentésekben bízom. Minden artefaktum ellenőrző összegeket kap (pl. SHA256), amelyeket külön tárolnak és rendszeresen ellenőriznek. Olyan súrolási feladatokat tervezek, amelyek véletlenszerűen vagy teljesen beolvassák az offsite objektumokat, és összehasonlítják a hash-eket. Ez lehetővé teszi számomra, hogy a bitrohadást vagy az átviteli hibákat korai szakaszban észleljem. Manifeszt fájlokat is mentek az elérési utakkal, méretekkel és hashekkel, hogy felismerhessem a hiányosságokat.
Automatizálom a teszt-visszaállításokat az integritás bizonyítékaként: napi véletlenszerű fájl-visszaállítások, heti teljes DB-visszaállítások PITR-rel, havi végponttól végpontig tartó teszt, beleértve az alkalmazás állapotának ellenőrzését. Az eredmények időbélyegekkel, naplókivonatokkal és képernyőképekkel ellátott jelentésekben jelennek meg.
Teljesítmény, időkeret és erőforrások
Olyan biztonsági mentési időablakokat határozok meg, amelyek elkerülik a terhelési csúcsokat és tiszteletben tartják a tranzakciós időket. A deduplikáció, a tömörítés és az inkrementális futtatások csökkentik az átviteli és tárolási mennyiséget. Korlátozom a sávszélességet (rclone/restic throttle), párhuzamos feltöltésekre és chunkingra támaszkodom, és figyelembe veszem a CPU és IO költségvetést. A nagy médiakészleteket differenciáltan mentem, és szegmensekre osztom őket az időkiesések elkerülése érdekében. Dokumentálom, hogy mennyi ideig tart egy teljes és egy inkrementális futtatás - és hogy ez összhangban van-e az RPO/RTO-immal.
Kapacitás- és költségtervezés
A kapacitásokat konzervatív módon számolom ki: adatállomány, napi változtatási arány, tömörítési/törlési tényező, megőrzési szintek (GFS). Ebből havi előrejelzést és felső költségvetési korlátokat készítek. Különböző tárolási osztályokat tervezek (forró/meleg/hideg), és életciklus-irányelveket állítok be a megőrzésen belüli automatikus váltásokhoz. Nyilvántartom a kilépési, API- és visszaállítási költségeket. Összehasonlítom a kiesés várható költségeit (bevételkiesés, SLA büntetések) a mentési költségekkel - így hozok költségvetési alapú érveket.
Szervezet, szerepek és a kettős ellenőrzés elve
Szigorúan elkülönítem a szerepeket: aki ment, az nem törölhet; aki változtat a megőrzésen, annak engedélyre van szüksége. A kritikus műveletek (törlés, megőrzés lerövidítése, megváltoztathatatlanság kikapcsolása) a kettős ellenőrzés elve alapján futnak, jegyre hivatkozással. Meghatározom az eszkalációs láncokat, helyettesítéseket és készenléteket. A törésüveges hozzáférések le vannak zárva, időbeli korlátozással rendelkeznek, és használat után rotációs alapon megújulnak. Az ellenőrzési naplók minden műveletet változatlanul rögzítenek.
A közös platformok sajátosságai
A WordPress esetében biztonsági másolatot készítek a DB-ről, a wp-tartalomról (feltöltések, témák, bővítmények), valamint a wp-config.php-ról és a sókról. Az üzletek esetében a várólisták/munkahelyek állapota, a fizetési és szállítási pluginek és a média CDN-ek kerülnek hozzá. Multisite beállítások esetén dokumentálom a domainek hozzárendelését az oldalakhoz. Biztosítom az átirányítási és SEO-beállításokat is, hogy elkerüljük a forgalomveszteséget a visszaállítások után. A keresési indexekről (pl. Elasticsearch/OpenSearch) biztonsági mentést készítek pillanatfelvételként, vagy szkriptek segítségével rekonstruálom őket, hogy a keresési funkciók gyorsan újra rendelkezésre álljanak a visszaállítás után.
Katasztrófa utáni helyreállítás és az infrastruktúra reprodukálhatósága
Az RTO-t az infrastruktúra reprodukálhatóvá tételével minimalizálom: konfiguráció kódként (pl. szerver- és panelbeállítások), megismételhető telepítések, rögzített verziók. Az alkalmazástitkokat titkosítva és verziózva tartom, és biztonsági incidensek után rotálom őket. Alternatív helyeket tervezek a DR számára, és dokumentálom, hogyan váltom át a DNS-t, a TLS-t, a gyorsítótárat és a levelek útválasztását válsághelyzet esetén. Feljegyzem a függőségeket (harmadik féltől származó API-k, fizetési szolgáltatók), és felkészülök a visszaesésekre.
Jog és megfelelés a biztonsági mentés kontextusában
Összehangolom a megőrzési időszakokat a törlési kötelezettségekkel: A személyes adatok esetében folyamatokat határozok meg arra vonatkozóan, hogy a törlési kérelmeket hogyan tudom gyakorlatilag végrehajtani anélkül, hogy veszélyeztetném a korábbi biztonsági mentések integritását. Dokumentálom, hogy mely adatkategóriák kerülnek a biztonsági mentésekbe, és minimalizálom a metaadatokat. A TOM-okat (technikai és szervezeti intézkedések) ellenőrizhető módon írom le: titkosítás, hozzáférés-ellenőrzés, naplózás, megváltoztathatatlanság, földrajzi határok. Feljegyzem a harmadik országokba történő átvitel kockázatait, és a megfelelőségi követelményeimnek megfelelően döntök a helyszínekről.
Gyakorlati tesztek és számadatok
Egyértelmű KPI-ket határozok meg: a biztonsági mentés sikerességi aránya, az utolsó sikeres biztonsági mentés kora, a visszaállítás első bájtjáig eltelt idő, a teljes visszaállítás ideje, a forrásonkénti hibaarányok, az ellenőrzött verziók száma, a riasztásig eltelt idő. Ezeket a mérőszámokat rendszeresen összehasonlítom az RPO/RTO céljaimmal. Játéknapokat tervezek: célzott, ellenőrzött hibák (pl. szándékosan törölt mappák) a válaszútvonalak, riasztások és visszaállítási útvonalak nyomás alatti tesztelésére. Az eredmények beépülnek a fejlesztési programomba.
GYIK rövid
Milyen gyakran készítsek megfelelő biztonsági mentést? Naponta használom Biztonsági mentések a fájlok esetében és óránkénti biztonsági mentések az adatbázisok esetében; nagy forgalom esetén rövidebb időközöket választok. Mennyi ideig tartsam meg a verziókat? Általában 30-90 nap; én havi hosszú távú verziókat is őrzök. Mi az RPO vs. RTO? Az RPO a maximális adatvesztésem, az RTO az az idő, amíg minden újra online lesz. Mindkettőt szerződésekben írom meg, és tesztelem az értékeket.
Hogyan védhetem az e-maileket? Külön húzom a maildir/mailboxokat, és tesztelem. Visszaállítás egyetlen mappa. Hogyan kezeljem a nagy médiafájlokat? A deduplikáció és a növekményes biztonsági mentések költséget takarítanak meg; a verziószámozás lehetővé teszi a célzott helyreállítást. Mit jelent a gyakorlatban a megváltoztathatatlanság? A megőrzéssel ellátott törlési védelem megakadályozza a manipulációt a lejáratig. Hogyan integrálhatom a WordPress-t vagy a boltokat? Biztonsági mentést készítek a fájlokról, a DB-ről és a konfigurációról, és dokumentálom a sorrendet.
Röviden összefoglalva
Ragaszkodom a 3-2-1-hez Offsite és megváltoztathatatlanság, egyértelmű RPO/RTO célok, rendszeres tesztek és tiszta dokumentáció. Horgonyozom le a felelősségeket, a playbookokat és a mért értékeket. Önkiszolgáló helyreállításokat és nyomon követhető költségeket követelek. Megfelelek a GDPR követelményeinek, beleértve az AVV-t és a szigorúan biztonságos kulcsokat és fiókokat. Ez lehetővé teszi számomra, hogy egy incidens után gyorsan újra online legyek - kiszámítható erőfeszítéssel és nyomon követhető minőséggel.
