Eiti prie turinio 
Primygtinai reikalauju aiškios 3-2-1 atsarginių kopijų strategijos, skirtos prieglobai su Atsarginė žiniatinklio prieglobos kopija, Atsarginė kopija kitoje vietoje, nekeičiamumo, RPO, RTO, GDPR ir reguliarių atkūrimo bandymų, kad galėčiau kontroliuojamai išgyventi sutrikimus. Reikalauju išmatuojamų tikslų ir atsekamų procesų, kad 3-2-1 atsarginių kopijų kūrimo taisyklė neegzistuotų tik popieriuje, bet greitai duotų rezultatų kritiniu atveju.
Centriniai taškai
- 3-2-1 taisyklėTrys kopijos, dvi laikmenos, viena kopija ne darbo vietoje ir nekeičiama atsarginė kopija kaip papildoma galimybė.
- DažnisKasdienės atsarginės kopijos, valandinės duomenų bazių atsarginės kopijos, versijų kūrimas ir PITR.
- NekintamumasWORM / objekto užraktas apsaugo nuo ištrynimo ar perrašymo, kurį gali atlikti įsilaužėliai.
- RPO/RTOAiškūs tikslai ir išbandyti atkūrimo būdai sumažina prastovas ir duomenų praradimą.
- SkaidrumasProtokolai, SLA, sąnaudų aiškumas ir reguliarūs atkūrimo bandymai.
Ką iš tikrųjų reiškia 3-2-1 žiniatinklio prieglobos srityje?
Planuoju bent tris kopijas: Originalus prieglobą, antrąją atsarginę kopiją kitoje laikmenoje ir trečiąją kopiją kitoje vietoje. Išorinė svetainė-vieta. Du skirtingi saugyklų tipai sumažina riziką, kad vienu metu gali įvykti gedimų dėl aparatinės įrangos, saugyklų tvarkyklių ar išpirkos reikalaujančios programinės įrangos. Geografiškai atskira kopija apsaugo mane nuo duomenų centro problemų, gaisro zonos gedimų ir administratoriaus klaidų. Taip pat pasikliauju 3-2-1-1-0 pratęsimu: nekeičiama kopija (WORM) ir atsarginės kopijos be klaidų kontrolinėje sumoje. Dėl to mano galimybės atkurti sistemą yra didelės, net jei gamybinė sistema buvo visiškai pažeista.
Kontrolinis sąrašas: Ko reikalauju iš šeimininko
Reikalauju visų atsarginių kopijų Failai, Duomenų bazės ir el. laiškus - nuosekliai, su tinkamais ištrynimais arba momentinių kopijų gesinimu, kad programos būtų atkurtos švariai. Be nuoseklių atsarginių duomenų bazių kopijų prarandu operacijas arba sugadinu lenteles. Tikrinu, ar kas valandą daromos atsarginės duomenų bazių kopijos ir kasdien daromos failų sistemos atsarginės kopijos. Versijų kūrimas ir "MySQL" / "MariaDB" atstatymas tašku laiku (PITR) man yra šio proceso dalis. Tai vienintelis būdas patikimai įgyvendinti griežtus RPO tikslus.
Reikalauju, kad būtų atleista iš darbo kitame duomenų centre arba pas nepriklausomą paslaugų teikėją, kad nė viena organizacija netaptų Vienas Taškas nesėkmės. Jei mano prieglobos kompiuteris turi kelis regionus, prašau kopijos kitoje ugnies zonoje. Kruopščiai patikrinu fizinį atskyrimą, tinklo kelius ir administracines ribas. Antra organizacija, skirta ne vietoje esančiai kopijai, sumažina dažniausiai pasitaikančių klaidingų konfigūracijų riziką. Taip pat teiraujuosi, ar saugykloje, esančioje kitoje vietoje, užtikrinamas tikrasis nekintamumas.
Primygtinai reikalauju nekeičiamų atsarginių kopijų per Nekintamumas/WORM, kad būtų išvengta išpirkos reikalaujančios programinės įrangos ir operacinių klaidų, neleidžiančių ištrinti duomenų. Objekto užraktas su išlaikymu ir pasirenkamu teisiniu išlaikymu neleidžia perrašyti duomenų, kol nepasibaigs užrakto laikotarpis. Dokumentuoju išsaugojimo logiką, kad žinočiau, kiek atgal galiu grįžti avariniu atveju. Tai taip pat apsaugo mane nuo vidinių grėsmių. Ypač svarbiems duomenims naudoju ilgesnius saugojimo laikotarpius.
Atsarginės kopijos neturi būti paleistos su tomis pačiomis administratoriaus paskyromis kaip ir gamybinė sistema, todėl reikalauju, kad Mažiausiai Privilegija ir atskiros sąskaitos. MFA/2FA yra privaloma, vaidmenys griežtai atskirti, o raktai saugūs. Patikrinu, ar paslaugų teikėjas siūlo atskirus projektus arba nuomininkus. Reikalauju atsarginių kopijų kūrimo ir atkūrimo veiksmų audito žurnalų. Taip galiu anksti aptikti manipuliacijas ir neteisėtą prieigą.
Visur užtikrinu šifravimą: TLS tranzito metu ir stiprų šifravimą ramybės būsenoje, geriausiai su mano paties Raktai. Vietos turi atitikti BDAR reikalavimus, o aš pasirašau duomenų apsaugos sutartį, kad būtų užtikrinta, jog duomenų tvarkymas atitinka teisės aktus. Dokumentų saugojimo laikotarpius dokumentuoju pagal atitikties reikalavimus. Metaduomenys ir indeksai taip pat turi būti saugomi užšifruotai. Taip užkertamas kelias informacijos nutekėjimui per failų pavadinimus ir struktūras.
Teisingai nustatyti RPO ir RTO
Apibrėžiu didžiausią leistiną duomenų praradimo ribą (RPO) ir maksimalus atsigavimo laikas (RTO) ir abu įrašykite į sutartį. Parduotuvėms ir portalams dažnai tikslinga nustatyti 1 valandos RPO; TVS, kuriose atliekama nedaug operacijų, pakanka ir 4-6 valandų. 4 valandų RTO yra realus daugeliui projektų; kritinėms platformoms reikia greitesnių tikslų. Be aiškių laiko tikslų niekas tinkamai neplanuoja biudžeto ir architektūros. Atkūrimo pratybos parodo, ar tikslai yra pasiekiami.
| Aspektas | Aprašymas | Tipinė vertė | Patikrinimas ir (arba) bandymas |
|---|---|---|---|
| RPO | Didžiausias toleruojamas Duomenų praradimas | 1 valanda (DB su PITR) | Binlogai, laiko žymos, atkūrimas į laiko tašką |
| RTO | Maksimalus Atsigavimo laikas iki produktyvumo | 4 valandos | Žaidimų knygos, chronometras, protokolas |
| Saugykla | Versijos ir išsaugojimas Dienos | 7/30/90 | Planas, gyvavimo ciklo politika, išlaidų apžvalga |
| Bandymų dažnis | Įprasta Atkurti-testai | kas mėnesį/ketvirtį | Ataskaita, hash patikrinimas, ekrano nuotraukos |
Dokumentuoju, kaip renku išmatuotas vertes ir kokias priemones naudoju. Be šio skaidrumo RPO ir (arba) RTO lieka teoriniai ir nepadeda man kritiniu atveju. Be to, fiksuoju, kurie komponentai yra kritiniai, todėl juos atkuriu prioriteto tvarka. Duomenų bazių atveju apibrėţiu PITR ir tinkamai apsaugau binlogus. Žiniasklaidos failų atveju man reikia nustatyti versijas ir aiškų išsaugojimą.
Praktinis neviešos vietos ir nekeičiamumo įgyvendinimas
Trečiąją kopiją nuolat įdedu į kitą Regionas arba nepriklausomam paslaugų teikėjui, kad ugniasienės, administratoriaus paskyros ir atsiskaitymai būtų atskiri. Objektų saugykla su aktyvuotu nekeičiamumu (pvz., Objekto užraktas) neleidžia ištrinti saugyklos viduje. Patikrinu regiono atskyrimą ir patikrinu, ar paslaugų teikėjas naudoja skirtingas ugnies zonas. Gera įžanga yra kompaktiška apžvalga 3-2-1 taisyklė prieglobos srityje. Taip pašalinama rizika, kad klaidinga konfigūracija paveiks visas kopijas.
Atsargines kopijas iš interneto perduodu tik užšifruotas ir su savo Raktai arba slaptažodžių frazes. Taip pat atskiriu prieigos duomenis, kad pažeidus žiniatinklio serverį nebūtų automatiškai atverta neviešoji saugykla. Įtvirtinu atskirus IAM vaidmenis ir MFA. Dokumentuoju apsaugą nuo ištrynimo suprantamai, kad auditas galėtų ją įvertinti. Tik keli žmonės turi teisę prašyti duomenų saugojimo pakeitimų.
Saugumas: prieiga, šifravimas, BDAR
Griežtai atskiriu prieigas ir tik atsarginėms kopijoms suteikiu minimalus būtinos teisės. Nėra vienodos root paskyros, bendro slaptažodžio, bendrų raktų. Taikau MFA su paslaugų teikėju ir su savo debesijos paskyromis. Užšifruoju duomenis kliento arba serverio pusėje naudodamas saugias procedūras. Taip sumažinama rizika, kad vagis perskaitys turinį iš laikmenos.
Atkreipiu dėmesį į BDAR reikalavimus atitinkančius Vietovės ir sudaryti DPS su aiškiu tikslo apribojimu. Patikrinu, ar žurnaluose yra metaduomenų, kurie gali būti laikomi asmeniniais. Raštu fiksuoju saugojimo ir ištrynimo koncepcijas. Man reikalingi suprantami informacijos prašymų ir ištrynimo procesai. Taip esu teisiškai saugus ir išvengiu baudų.
Atkūrimo testas: reguliariai pratinkitės atkurti
Aš ne tik teoriškai išbandau atkūrimą, bet ir reguliariai atlieku Atkurti-pratimai izoliuotoje etapų aplinkoje. Matuoju laiką, fiksuoju veiksmus ir šalinu kliūtis. Lyginu failų kontrolines sumas ir tikrinu programų nuoseklumą naudodamas funkcijų patikras. Atkuriu duomenų bazes į norimą laiko momentą (PITR) ir tikrinu sandorius. Tik šis dokumentas parodo, ar RPO/RTO yra realūs.
Turiu paruoštus žaidimo vadovus: Kaip susisiekti su palaikymo tarnyba, kokioms sistemoms teikiama pirmenybė. Užrašau seką: Pirmiausia duomenų bazė, tada failai, tada konfigūracijos. Saugau svarbius Slaptažodžiai neprisijungus. Po kiekvieno bandymo atnaujinu dokumentaciją ir laikus. Taip manęs nenustebins tikra avarinė situacija.
Kaip sukurti savo 3-2-1 sąranką
Laikausi struktūros: produktyvūs duomenys apie Žiniatinklio serveris, antroji kopija į NAS ar kitą saugyklą, trečioji kopija - ne saugykloje, kur ji yra nekintama. Failams naudoju restic arba BorgBackup su deduplikacija ir šifravimu. Duomenų bazėms naudoju mysqldump, logines atsargines kopijas su nuosekliomis spynomis arba "Percona XtraBackup". Perdavimams naudoju rclone su pralaidumo apribojimu ir pakartojimais.
Išlaikymą planuoju pagal JRC (kasdien / kas savaitę / kas mėnesį) ir rezervuoju pakankamai Atmintis versijoms kurti. "Cronjobs" arba CI organizuoja atsargines kopijas ir patikrinimus. Stebėsena praneša apie klaidas el. paštu arba Webhook. Šiame straipsnyje pateikiamas glaustas kategorijų suskirstymas Atsarginių kopijų kūrimo strategijos prieglobos svetainėse. Tokiu būdu aš išlaikysiu kontrolę, net jei mano prieglobos tarnyba siūlo mažai.
Automatizavimas ir stebėjimas
Automatizuoju visus pasikartojančius Žingsniai ir dokumentuoti tikslias komandas. Skriptai tikrina išėjimo kodus, slaptažodžius ir laiko žymes. Dėl nepavykusių atsarginių kopijų iš karto gaunami pavojaus signalai. Žurnalus saugau centralizuotai ir apsaugotus nuo klastojimo. Taip pat riboju duomenų srauto pralaidumą ir atokiau esančiame taikinyje atlieku būklės patikrinimus.
Su prieglobos tarnyba aptariu API prieigą, SFTP/rsync ir S3 suderinamus galinius taškus, kad galėčiau naudoti nepriklausomus atkūrimo kelius. Registruoju išsiuntimo ir atkūrimo paslaugų išlaidas, kad pabaigoje nebūtų netikėtumų. Patikrinu, ar įmanoma savarankiškai atkurti atskirus Failai ir išsamių ataskaitų. Jei ne, planuoju savo priemones. Tai sutaupo man laiko kritiniu atveju.
Dažniausiai daromos klaidos ir kaip jų išvengti
Niekada nepasikliauju vienu Kopijuoti arba toje pačioje saugojimo sistemoje. Man nepakanka vien tik momentinių kopijų, jei jos nėra nei perkeliamos, nei nekeičiamos. Tikrinu duomenų bazių nuoseklumą, o ne tik kopijuoju failus. Stebėsenos ir atkūrimo testai yra mano kalendoriaus dalis. Dėl neaiškios saugyklos ar trūkstamo versijų nustatymo avariniu atveju tenka patirti ilgas prastovas.
Taip pat tikrinu, ar atkūrimo išlaidos yra skaidrios ir ar nėra jokių mokesčių, dėl kurių vėluotų atkūrimas. Vengiu bendrų administratoriaus paskyrų ir visur naudoju MFA. Įrašau raktų rotacijos procedūras. Bent kartą per ketvirtį atlieku Testas-Atkurti per. Šių pratybų klaidos patenka į mano žaidimų knygas.
SLA, skaidrumas ir sąnaudos
Turiu atsarginę architektūrą su Diagramos ir procesus. Tai apima stebėjimo ataskaitas, pavojaus signalų kelius ir reagavimo laiką. Prašau pateikti visą parą veikiančius skubios pagalbos kontaktus ir nurodyti laiko langus, per kuriuos atstatymui teikiama pirmenybė. Taip pat reikalauju aiškių saugojimo, išėjimo ir paslaugų sąnaudų lentelių. Jei to trūksta, biudžete planuoju papildomus rezervus.
Svarbiems projektams atsargines kopijas derinu su DR-scenarijus ir išvengti vieno gedimo taško. Čia verta atkreipti dėmesį į Atkūrimas po nelaimių kaip paslauga, jei noriu sutrumpinti perjungimo įvykus gedimui laiką. Dokumentuoju eskalavimo grandines ir bandymų datas. Taip pat palaikau perteklinius ryšių kanalus. Taip užtikrinu, kad niekas nepatvirtintų trūkstamų pareigų kritiniu atveju.
Kokią dar atsarginę kopiją, be failų ir duomenų bazių, galiu sukurti?
Apsaugau ne tik žiniatinklio šaknį ir duomenų bazę, bet ir visus mano platformą sudarančius komponentus. Tai apima DNS zonas, TLS sertifikatus, cronjobs, žiniatinklio serverio ir PHP konfigūracijas, .env failus, API raktus, SSH raktus, WAF / ugniasienės taisykles, nukreipimus ir el. pašto filtrus. Taip pat eksportuoju paketų sąrašus, "composer/npm lockfiles" ir programų konfigūracijas. Pašto atveju remiuosi visomis "maildir" aplankų atsarginėmis kopijomis ir atskiru slapyvardžių bei transportavimo taisyklių eksportu. Kelių paskyrų prieglobos atveju taip pat darau atsargines skydelio konfigūracijų kopijas, kad galėčiau atsekamai atkurti visas paskyras.
Aš sąmoningai sprendžiu, ką ne saugus: Siekiant taupyti sąnaudas ir sutrumpinti atkūrimo laiką, palieku talpyklas, sesijas, laikinus įkėlimus ir generuojamus artefaktus (pvz., optimizuotus vaizdus). Paieškos indeksų arba smulkiagrūdžių talpyklų atveju dokumentais patvirtinu, kaip jos automatiškai atkuriamos atkūrimo atveju.
Atsarginio kopijavimo metodų ir topologijų palyginimas
Kiekvienam darbo krūviui pasirenku tinkamą metodą: loginiai ištrynimai (pvz., mysqldump) yra nešiojami, bet užima daugiau laiko. Fizinės karštosios atsarginės kopijos (pvz., naudojant momentinių kopijų mechanizmus) yra greitos ir nuoseklios, tačiau joms reikia tinkamų saugojimo funkcijų. Jei įmanoma, naudoju ramybės palaikymo priemones (fsfreeze/LVM/ZFS) ir saugius "InnoDB" binlogus tikrajam PITR. Atsarginėms failų kopijoms kurti naudoju inkrementinį nuolatinį kopijavimą su deduplikacija.
Sprendžiu tarp "push" ir "pull" topologijos: Naudojant "pull", atsarginės kopijos darymą inicijuoja atsarginių kopijų serveris ir sumažėja rizika, kad bus pažeistos šaltinio sistemos. Naudojant "push" metodą, programų serveriai patys inicijuoja atsargines kopijas - tai paprasčiau, tačiau reikia griežtai atskirti IAM ir vykdyti išėjimo kontrolę. Agentais pagrįsti metodai užtikrina didesnį nuoseklumą, beagentinius metodus lengviau valdyti. Dokumentuoju savo pasirinkimą ir riziką.
Smulkumas ir atkūrimo keliai
Planuoju kelių tipų atkūrimą: atskirų failų, aplankų, atskirų lentelių ir (arba) duomenų įrašų, ištisų duomenų bazių, pašto dėžučių, visų prieglobos paskyrų. TVS ir (arba) parduotuvių sistemoms pirmenybę teikiu „pirmiausia DB, tada įkeliamoms duomenų rinkmenoms ir (arba) laikmenoms, tada konfigūracijai“. Turiu parengęs mėlynąjį ir žaliąjį metodus: atkūrimas stadijoje, patvirtinimas, tada kontroliuojamas perjungimas. Tai sumažina prastovų laiką ir netikėtumų produktyvaus darbo metu.
Užtikrinu, kad būtų galima atkurti savitarnos režimu: Vartotojai gali savarankiškai pasirinkti versiją, ieškoti laiko taškų ir juos tikslingai atkurti. Turiu parengęs „stiklo pertraukimo“ procesą nenumatytiems atvejams: Skubi prieiga su registravimu, ribotu laiku ir pagrįsta dvigubos kontrolės principu.
vientisumas, kontrolinės sumos ir tylusis duomenų sugadinimas
Pasitikiu tik tomis atsarginėmis kopijomis, kurios yra vientisos nuo galo iki galo. Kiekvienas artefaktas gauna kontrolines sumas (pvz., SHA256), kurios saugomos atskirai ir reguliariai tikrinamos. Planuoju valymo užduotis, kurios atsitiktine tvarka arba visiškai nuskaito ne vietoje esančius objektus ir palygina hash'us. Taip galiu anksti aptikti bitų puvimo ar perdavimo klaidas. Taip pat išsaugau manifestų rinkmenas su keliais, dydžiais ir hash'ais, kad galėčiau aptikti spragas.
Automatizuoju bandomuosius atkūrimus kaip vientisumo įrodymą: kasdienį atsitiktinių failų atkūrimą, savaitinį visos DB atkūrimą su PITR, mėnesinį bandymą "nuo galo iki galo", įskaitant programos būklės patikrinimą. Rezultatai pateikiami ataskaitose su laiko žymomis, žurnalų ištraukomis ir ekrano nuotraukomis.
Veikla, laikotarpis ir ištekliai
Nustatau atsarginių kopijų kūrimo laiko langus, kuriais išvengiama apkrovos pikų ir atsižvelgiama į operacijų laiką. Deduplikacija, suspaudimas ir inkrementinės operacijos sumažina perkėlimo ir saugojimo apimtį. Riboju pralaidumą (rclone/restic throttle), remiuosi lygiagrečiu įkėlimu ir dalijimu bei atsižvelgiu į CPU ir IO biudžetus. Dideles laikmenų atsargines kopijas darau diferencijuotai ir daliju jas į segmentus, kad išvengčiau laiko trukmių. Dokumentuoju, kiek laiko trunka pilnas ir inkrementinis paleidimas, ir ar tai atitinka mano RPO/RTO.
Pajėgumų ir sąnaudų planavimas
Apskaičiuoju pajėgumus konservatyviai: duomenų inventorių, kasdienio keitimo dažnį, suspaudimo ir ištrynimo koeficientą, saugojimo lygius (GFS). Pagal tai sudarau mėnesio prognozę ir viršutines biudžeto ribas. Planuoju skirtingas saugojimo klases (karšta/šilta/šalta) ir nustatau gyvavimo ciklo politiką automatiniam perkėlimui pagal išlaikymą. Registruoju išėjimo, API ir atkūrimo išlaidas. Palyginu tikėtinas sutrikimo išlaidas (pajamų praradimas, SLA baudos) su atsarginės kopijos išlaidomis - taip pateikiu biudžetu pagrįstus argumentus.
Organizacija, vaidmenys ir dvigubos kontrolės principas
Griežtai atskiriu vaidmenis: visiems, kurie išsaugo, neleidžiama ištrinti; visiems, kurie keičia išsaugojimą, reikia leidimo. Kritiniai veiksmai (ištrynimas, saugojimo sutrumpinimas, nekeičiamumo išjungimas) atliekami pagal dvigubos kontrolės principą su bilieto nuoroda. Apibrėžiu eskalavimo grandines, pavadavimus ir atsarginius veiksmus. Pertraukiamosios prieigos yra užplombuotos, ribotos laike ir po naudojimo atnaujinamos rotacijos principu. Audito žurnaluose visi veiksmai fiksuojami nekintamai.
Bendrų platformų ypatumai
"WordPress" atveju darau atsarginę DB, wp turinio (įkėlimų, temų, įskiepių), taip pat wp-config.php ir druskų atsarginę kopiją. Parduotuvėms pridedamos eilių ir (arba) darbų būsenos, mokėjimo ir siuntimo įskiepiai bei medijos CDN. Daugiaviečių svetainių sąrankų atveju dokumentais patvirtinu domenų priskyrimą svetainėms. Taip pat apsaugau nukreipimo ir SEO nustatymus, kad būtų išvengta srauto praradimo po atkūrimo. Atkuriu atsargines paieškos indeksų (pvz., "Elasticsearch" / "OpenSearch") kopijas kaip momentines nuotraukas arba atkuriu jas naudodamasis scenarijais, kad po atkūrimo vėl būtų galima greitai naudotis paieškos funkcijomis.
Atkūrimas po nelaimės ir infrastruktūros atkuriamumas
Sumažinu RTO, užtikrindamas, kad infrastruktūra būtų atkuriama: konfigūracija kaip kodas (pvz., serverio ir skydelio nustatymai), pakartotinis diegimas, fiksuotos versijos. Programų paslaptis saugau užšifruotas ir suskirstytas pagal versijas, o po saugumo incidentų jas keičiu. Planuoju alternatyvias DR vietas ir dokumentais patvirtinu, kaip krizės atveju perjungiu DNS, TLS, spartinančiąją atmintį ir pašto maršruto parinkimą. Registruoju priklausomybes (trečiųjų šalių API, mokėjimo paslaugų teikėjai) ir parengiu atsargines priemones.
Teisė ir atitiktis atsarginių kopijų kontekste
suderinu saugojimo laikotarpius su įpareigojimais ištrinti duomenis: Asmens duomenų atveju apibrėšiu procesus, kaip praktiškai įgyvendinti prašymus ištrinti duomenis, nepažeidžiant istorinių atsarginių kopijų vientisumo. Dokumentuoju, kurios duomenų kategorijos patenka į atsargines kopijas, ir mažinu metaduomenų kiekį. Audituojamu būdu aprašau TOM (technines ir organizacines priemones): šifravimą, prieigos kontrolę, registravimą, nekeičiamumą, geografines ribas. Registruoju trečiųjų šalių duomenų perdavimo riziką ir sprendžiu dėl vietų pagal atitikties reikalavimus.
Praktiniai bandymai ir pagrindiniai skaičiai
Apibrėžiau aiškius KPI: sėkmingo atsarginių kopijų kūrimo rodiklis, paskutinės sėkmingos atsarginės kopijos amžius, laikas iki pirmojo atkurto baito, pilno atkūrimo laikas, klaidų lygis pagal šaltinį, patikrintų versijų skaičius, laikas iki įspėjimo. Šiuos rodiklius reguliariai lyginu su savo RPO/RTO tikslais. Planuoju žaidimų dienas: tikslingus, kontroliuojamus gedimus (pvz., tyčia ištrintus aplankus), kad išbandyčiau atsako būdus, įspėjimus ir atkūrimo būdus, esant spaudimui. Rezultatai įtraukiami į mano tobulinimo programą.
DUK trumpai
Kaip dažnai reikia tinkamai kurti atsargines kopijas? Naudoju kasdien Atsarginės kopijos failams ir kas valandą atsarginėms duomenų bazių kopijoms; esant dideliam duomenų srautui renkuosi trumpesnius intervalus. Kiek laiko saugoti versijas? Įprastai 30-90 dienų; taip pat saugau mėnesines ilgalaikes versijas. Kas yra RPO ir RTO? RPO - tai didžiausias mano duomenų praradimas, o RTO - laikas, kol viskas vėl bus tinkle. Sutartyse įrašau abi reikšmes ir jas išbandau.
Kaip apsaugoti el. laiškus? Atskirai ištraukiu maildir/pašto dėžutes ir išbandau Atkurti vieną aplanką. Kaip elgtis su dideliais medijos failais? Deduplikacija ir inkrementinės atsarginės kopijos taupo išlaidas; versijų nustatymas leidžia tikslingai atkurti failus. Ką praktiškai reiškia nekeičiamumas? Apsauga nuo ištrynimo su išsaugojimu neleidžia manipuliuoti iki galiojimo pabaigos. Kaip integruoti "WordPress" arba parduotuves? Darau atsargines failų, DB ir konfigūracijos kopijas ir dokumentais patvirtinu seką.
Trumpa santrauka
Primygtinai reikalauju 3-2-1 su Išorinė svetainė ir nekintamumas, aiškūs RPO/RTO tikslai, reguliarūs testai ir tvarkinga dokumentacija. Įtvirtinu atsakomybę, žaidimų vadovus ir išmatuotas vertes. Reikalauju savitarnos atkūrimo ir atsekamų išlaidų. Laikausi BDAR reikalavimų, įskaitant AVV ir griežtai apsaugotus raktus bei paskyras. Tai leidžia man greitai atkurti tinklą po incidento - su nuspėjamomis pastangomis ir atsekama kokybe.
