Biztonsági mentés¶
Műszaki TL;DR
5-5-5
szintű remote backup repo + immutable restic backend, végponti titkosítással, tömörítéssel és deduplikációval, LTO szalagos mentésekkel, pull-mode online mirrorral, offline másolatokkal és archiválással.
Egy jó biztonsági mentés megoldhat sokféle informatikai vészhelyzetet, de csak előzetesen alkalmazva.
Önmagában a mentés nem akadályozza meg, hogy tönkremenjen a számítógéped vagy ellopják, mint ahogy azt sem, hogy zsarolóvírus kerüljön rá és betitkosítson minden adatot. Ellenben garantálja, hogy az adataid ne vesszenek el, azaz lehetőség szerint minden helyreállítható legyen. Viszont ez igényel némi előregondolkodást, törődést.
Ahogy a vállalati IT mondás is tartja:
Eső után köpönyeg?
"A legjobb mentési eljárások mindig a legnagyobb adatvesztések után kerülnek bevezetésre".
A gond az, hogy ekkorra már elveszhetett egy csomó adatod, és/vagy kifizettél súlyos pénzeket sérült adathordozóról adatok helyreállításért. Megelőzni az adatvesztést csak töredékébe (minimum egy kis figyelembe, törődésbe) kerül. Természetesen a lentiek mind megoldhatóak saját erőből, saját eszközökkel; ekkor is ajánljuk figyelmedbe ezt a szolgáltatást - ha másért nem, ötletek merítésére.
Mentés - kőbe vésve
Nem teljesen szó szerint értendő, de amit egyszer feltöltesz hozzánk, az már tényleg úgy marad. Te sem, mi sem, egy rosszindulatú támadó sem tudja megváltoztatni, letörölni.
Backup as a Service¶
Szolgáltatásunkat a nagyvállalati IT tanácsadói és üzemeltetői tapasztalatunkból építettük fel, de nem milliókba kerülő enterprise szoftverrendszerekkel, hanem válogatott, ellenőrizhető működésű, nyílt forrású, mégis kiválóan működő, bevált, kvázi iparági szabvány eszközökkel.
A dokumentációban részletesen felsoroljuk ezeket az eszközöket, forráskódjuk a GitHub-on ellenőrizhető. A kliensoldalon ezekből csak egyre van szükség: a restic végzi a mentést, benne a deduplikációt, tömörítést, titkosítást, feltöltést és visszaolvasást.
Szolgáltatásunk lényege egy megbízható restic backend biztosítása, néhány extrával:
- A mentéseket a 3-2-1 védelem helyett 5-5-5 szinten végezzük.
- A restic által használt online backup tárhelyet további mentésekkel védjük (mentések mentései):
- tükrözés másik szerverre másik országban
- napi/heti szalagos mentések külön helyszíneken,
- szalagok offsite archiválása MNB-engedélyes széfszolgáltatónál.
- A tárhely append-only, ha úgy tetszik
immutable
, tehát feltöltés után megváltoztathatatlan: nem lehet törölni belőle, vagy módosítani. A napi szalagos mentéseket pedig WORM LTO szalagra írjuk, itt a kiírás után fizikailag lehetetlen az adatmódosítás.
Élő státuszoldal
Nézz rá a demo státuszoldalra naponta többször (óránként frissül), hogy lásd az ötszintű mentés működését:
- crontab mentés 4 óránként
- repo tükrözés 4 óránként
- WORM szalag naponta
- offline szalag hetente
- offsite archiválás havonta.
Demo¶
Backup státuszoldal mutatja az egyes mentések biztonsági szintjét. Így néz ki élőben:
Demo backup státuszoldal - élő
A fenti backup tárhely egy nagyobb VPS-ünk mentéseit tartalmazza, 4 óránkénti teljes filerendszer (40G) pillanatfelvételeivel és adatbázisdumpjaival.
Mikor kell külső biztonsági mentés?¶
Gyakorlatilag mindig, amikor adataid elvesztésének mértékét és valószínűségét minimalizálni szeretnéd.
Mi ellen véd egy jó biztonsági mentés?¶
- hardverhiba
- adathordozó (SSD, flash tároló, merevlemez) sérülés
- emberi véletlen hiba, tévedés
- elrabolt számítógép, telefon
- rosszindulatú támadás, vírusfertőzés
- zsarolóvírus általi titkosítás
- belső szabotázs, elbocsátott munkatárs bosszúja
- megtámadott alvállalkozók, üzleti partnereken keresztüli károkozás (supply chain attack)
- szolgáltatói hiba
- természeti katasztrófák
Szolgáltatói gyorsteszt¶
Pénteken 20 órakor küldd el ezt az információkérést a szerverszolgáltatódnak:
"Tönkrement valami a rendszerem frissítéskor ma 19:53-kor, melyik lenne az utolsó állapot, amire vissza tudnánk állni mentésből? Még nem kérek tényleges adatvisszaállítást, csak információt első körben."
Ha a fejlesztőd intézi a szerveredet, akkor tőle kérd ezt az információt. Ne fogadj el felajánlást a rendszer rendberakására / kijavítására, várj el érdemi választ a kérdésre. Miért pont péntek 20 órakor? Mert a szolgáltatók általában éjszaka indítják a mentéseiket, amikor az átlagos rendszerterhelés alacsonyabb. Ha csak hetente mentenek, akkor pedig hétvégén. A kérdésre adott válaszból egyértelműen ki fog derülni, hogy mennyi adatvesztéssel számolhatsz, ha csak a szolgáltatói mentést veszed igénybe.
Audit követelmények¶
Egy NIS2 előadáson hallottuk
"Nálunk évente van biztonsági mentés, ezért a múltkori szerverhibánál csak fél évnyi adat veszett el, ezeket kézi adatbevitellel pótoltuk."
Nem tudom, az informatikus kolléga mit kapott ezért, de lehet, hogy itt lenne az idő "kicsit" professzionálisabb mentés beüzemelésére..
A megbízható biztonsági mentés minden komolyabb szabályrendszer kulcsfontosságú eleme, úgy mint:
- NIS2 (EU kiberbiztonsági szabályozás) - most ez aktuális sokunknál
- GDPR (EU általános adatvédelmi rendelet)
- ISO 27001 (nemzetközi szabvány az információbiztonsági irányítási rendszerekre)
- PCI-DSS (a bankkártyás fizetési rendszerek biztonságát garantáló globális szabvány)
- TISAX (autóipari információbiztonsági szabvány)
- NIST CSF (USA kiberbiztonsági keretrendszer)
- HIPAA (egészségügyi adatok védelmére vonatkozó szabályozás)
- SOX (Sarbanes-Oxley Act, USA törvény a pénzügyi adatok megőrzéséről)
- DORA (EU szabályozás a pénzügyi szektor digitális biztonságára)
Teljesíthető audit megfelelés
Mentési megoldásunkkal a fenti szabályozások adatbiztonsági követelményei auditálható módon megvalósíthatóak.
Weboldal tárhely / VPS¶
A weboldaltulajdonosok fixa ideája, hogy bérelve egy webtárhelyet vagy VPS-t, annak megfelelő mentéséről a szolgáltató gondoskodik. Persze, létezik valamiféle mentés, de az általában épphogy csak arra elég, hogy a VPS beinduljon, vagy a tárhely ne legyen üres. Jó esetben napi mentéseket készítenek a tárhelyszolgáltatók, de néhány helyen a VPS-ekről csak heti mentés készül (ráadásul az is egy működés közbeni, valószínűleg inkonzisztens állapotú VM image mentés).
Ahhoz, hogy egy webshop vagy egy gyakran változó oldal mindenkori aktuális adatai megbízhatóan megmaradjanak, rendszeres (minél nagyobb gyakoriságú) filerendszer- és adatbázismentésre van szükség.
Szerver, NAS¶
Manapság nagyon könnyű megoldani egy kisvállalkozás helyi szerverigényét: üzembehelyezel egy NAS-t, ami mindenre jó: egymagában lehet fileszerver, levelezőszerver, címtár, csoportmunkaszoftver, sőt mentő (backup) szerver. Nos, itt van a probléma: ez mindentudó kis NAS szerver máris szűk keresztmetszetté válik adatbiztonsági szempontból. Egy-két merevlemez meghibásodását még elviseli a RAID miatt, de egy vírustámadást, vagy szándékos, sőt akár véletlen károkozást már nem.
Ráadásul ezeken a NAS eszközökön rengeteg sérülékenységet fedeznek fel, és megfelelő üzemeltetés nélkül könnyen válhatunk áldozattá / károsulttá. Nézd csak meg a legnépszerűbb NAS gyártók oldalán, mennyi (és milyen komoly) biztonsági incidens történt az elmúlt időszakban.
Természetesen ezzel nem azt mondjuk, hogy ne használj NAS szervert, mert ezek nagyon praktikus eszközök, csak mindig gondolj az adatok biztonságára:
- ha a NAS a szerver is, mindig legyen két aktuális mentés róla (egyik lehet egy másik eszközön házon belül, a másik kívül).
- ha a NAS csak mentő szerver (és az élő adataink máshol vannak), akkor is legyen egy külső másolatod a mentésről (és ez ne a NAS saját cloudja legyen, mert sérülékenység esetén ez azonnal hozzáférhető és törölhető)
- ha egy felhasználó fel tud csatlakozni a NAS-ra mentés céljából, akkor a gépéről egy vírus kódja is; tehát törölhet, letitkosíthat.
PC, laptop, munkaállomás¶
A legtöbb kisvállalkozásnál még szerver sincs, minden adatot és dokumentumot a számítógépeken tárolnak, maximum néhány dolog fel van szinkronizálva a "felhőbe".
- De vajon mi történik, ha ellopják a laptopot?
- Vagy ha bejut egy zsarolóvírus a gépre és letitkosít mindent, mit érünk a mentéssel a felhőben, ha a fileok ott is csak letitkosítva lesznek meg (merthogy a változások oda is átszinkronizálódnak)?
- És ha a vírus hozzáfér a felhőtárhelyhez (pedig valószínűleg hozzáfér, hiszen a kulcs a gépen van), akkor nem logikus, hogy törölheti a mentéseket is?
Hamis biztonságérzet
Ha a mentendő gépre fel van csatlakoztatva a mentés, tehát helyben tudod törölni a mentéseket (NAS-ról, külső diszkről, felhőtárhelyről), akkor annak a mentésnek az adatbiztonsági értéke közel nulla (hiszen a megvédendő rendszer hozzáfér). Ez a probléma kétféle módon oldható meg:
-
úgynevezett
pull-backup
mentést használunk: a backup szervert ellátjuk kiemelt védelemmel, és ez "nyúl le" az adatokért kívülről; -
vagy pedig
append-only
mentési tárhelyekre dolgozunk (mint ennél a szolgáltatásnál is), amelyekhez eleve csak hozzáírni lehet, módosítani és törölni nem.
Fejlesztői környezet¶
Az egyik legfájdalmasabb adatvesztés az, amikor a nehezen elvégzett munkánk veszik el. Fejlesztőként természetesen mindenki használ valamilyen verziókezelő rendszert (pl. Git
), és egy távoli forráskód repository-ba (GitHub, GitLab, céges repo) rendszeresen menti a módosításokat és az új kódokat. A kérdés igazából az, hogy két commit
(és persze push
) között mennyi idő telik el. Ha minden apró változtatás kvázi azonnal felkerül a repo-ba, akkor az extra mentés valóban nem feltétlenül indokolt. De ha olyan stratégiánk van, hogy csak a nagyobb változtatásokat "küldjük fel", adott esetben több nap is eltelik két commit/push
között, akkor már nagyon hiányozna, ha valami elveszne.
Ilyenkor praktikus egy, a verziókezelőtől független mentési megoldás használata. A mi rendszerünket használva nagyon egyszerű beállítani akár 5 percenkénti mentést. Nagyon gyorsan lefut, és ha nincs változás, természetesen nincs helyfoglalás sem a backup repo-ban:
# crontab
*/5 * * * * dev restic -q backup /home/dev/src
Nem mindegy a sorrend
Mivel a deduplikáció csak akkor tud hatékonyan működni, ha ez eredeti adatfolyamot tudja elemezni (és abban megtalálni az ismétlődéseket), praktikus tömörítetlen formában ráküldeni az adatokat, és rábízni a tömörítést (a már deduplikált adatfolyamon).
Integrációs lehetőségek¶
Mivel a backup eszköz (restic)
képes stdin
-ről fogadni adatot, gyakorlatilag bármilyen rendszer mentéséhez tudjuk integrálni a szolgáltatást, akár LXD/Docker konténerekhez vagy virtuális gépekhez. Itt érdemes figyelni arra, hogy a deduplikáció megtörténhessen a tömörítés előtt.
Az optimális mentési folyamat (mindent a restic végez):
graph LR
A([export])-->Z;
Z([restic])-->B;
B[deduplikáció]-->C;
C[tömörítés]-->D;
D[titkosítás]-->E;
E[feltöltés];
Előre tömörített/titkosított adatfolyam mentése, deduplikáció nélkül:
graph LR
B([külső<br>tömörítés+<br>titkosítás])-.->|Nem deduplikálható adatfolyam|Z;
Z([restic])-->C;
C[hatástalan<br>tömörítés]-->D;
D[felesleges<br>titkosítás]-->E;
E[nagyobb<br>méretű<br> feltöltés];
A Te döntésed
Természetesen semmi akadálya annak, hogy mentési szolgáltatásunkat ne az általunk javasolt módon használd: a titkosítást és tömörítést még a resticbe csatornázás előtt egy másik eszközzel is megoldhatod, lemondva ezzel a deduplikáció előnyeiről. Kérlek figyelj arra, hogy a restic mindenképpen fog titkosítani, így a titkosító kulcsára mindenképp vigyáznod kell. A tömörítés viszont kikapcsolható, lásd a dokumentációban.
Milyen egy jó biztonsági mentés?¶
Áttekinthető¶
Felhasználóként nyilván fontos, hogy mindig látható legyen a mentéseid aktuális állapota. Mi ezt így oldottuk meg:
Kitettük publikus elérésre az egyik nagyobb VPS szerverünk backup státusz oldalát élő demoként, hogy megrendelés nélkül is beleláthass egy kicsit a backup szolgáltatásunk működésébe:
Demo backup státuszoldal - élő
Biztonságos¶
Főszabály: 3-2-1
Aki az adatbiztonságot komolyan veszi, bizonyára hallott már a 3-2-1 mentési szabályról: 3 példány, 2-féle adathordozón, 1 házon kívül.
Saját hatáskörben ezt tisztességesen megoldani nem túl gazdaságos. Mi ezért létrehoztunk egy olyan szolgáltatást, amely a teljes 3-2-1 mentési folyamatot (sőt, annak továbbfejlesztett 5-5-5 változatát) egyszerűen és elérhető áron biztosítja.
BaaS
A Backup as a Service
nem egyszerű felhőtárhely, hanem a teljes mentési folyamatot biztosító szolgáltatás.
Fontos tulajdonsága, hogy a mentési tárhely immutable
, azaz megváltoztathatatlan: ezekből a tárhelyekből semmilyen módon nem lehet törölni, ha már egy mentés elkészült.
- 5 példányban vannak meg az adataid (a forrás példányon kívül):
- elsődleges mentésként az online repo-ban, amit tetszőleges gyakorissággal frissíthetsz az élő adatokból (és persze minden korábbi változat is megmarad, a feltöltött mentések változtathatlanok),
- a mentések mentéseként pedig:
- folyamatosan, pull-szinkronizált tükör adatterületen (másik országban)
- egyszer írható, törölhetetlen WORM szalagra írva - naponta
- másik helyszínen hetente LTO szalagra írva - 3 példányban, hetente forgatva
- ebből egyet egy külön helyszínen tárolva (mind a három sosincs egy helyen)
-
5-féle adathordozón tároljuk a mentéseket:
- elsődleges mentés: NVMe
- tükör adatközpont: SATA SSD
- napi szalagos mentés: WORM LTO
- heti offline mentés: normál LTO
- archivált adatok: HDD + LTO
-
5 különböző helyszínen tárolódnak a mentések:
- elsődleges szerverek: Németország
- tükör szerverek: Finnország
- LTO mentőszerverek és archívum: 3x Magyarország
(egymástól legalább 40 km távolságra található a 3 helyszín, 3 különböző szolgáltatónál)
-
A maximális biztonság érdekében (és paranoiánk hűsítése végett) a heti mentéseket offline/leválasztott állapotban tároljuk.
-
A mentéseket a
restic
helyben titkosítja, a Te gépeden. A titkosító kulcs sosem kerül hozzánk, mi csak titkosított adatokkal dolgozunk.
Gazdaságos¶
Mielőtt a restic
bármit is tenne a mentendő adatokkal, elvégez egy deduplikációt, azaz "kiszedi" belőle az ismétlődéseket. Ha egy file (akár részleteiben) már fent van a mentésben, nem foglalja mégegyszer a helyet. Ezáltal ki lehet szűrni:
It's magic!
A dolog szépsége, hogy nem csak filerendszerre vonatkoztatva működik a deduplikáció, hanem pl. VM image mentéseknél vagy akár SQL dumpoknál is (ezért praktikus ezeket tömörítés/titkosítás nélkül beletolni a restic
-be).
- a filerendszeren belüli ismétlődéseket,
- előző mentéshez képest változatlan fileokat (~ differenciális mentés),
- sőt a fájlokon belül a változatlan részeket.
Csak az ezekből fennmaradó, új adattartalmat fogja a restic
betömöríteni, titkosítani, majd feltölteni; ezzel takarékoskodva a tárhellyel.
Természetesen mindezt transzparensen, a felhasználó elől elrejtve végzi. Te csak annyit fogsz belőle tapasztalni, hogy a tárhelyed helyfoglalása nagyon lassan növekszik. Adatvisszaállításnál a megfelelő helyekről előszedi a megfelelő adatblokkokat, a mentési pillanatfelvételekből azt kapod vissza, amit az az adott mentés pillanatában a mentett adataid tartalmaztak - az egészet (nyilvánvalóan lehetőség van másik könyvtárba visszaállítani a mentést, nem muszáj rögtön felülírni vele az eredeti adatokat).
Elszámolás alapja: a nálunk ténylegesen elfoglalt hely
A mentési tárhely mérete alatt mi a szervereinken lévő tényleges helyfoglalást értjük. Semmiképpen nem a mentési adatkészlet nálad elfoglalt összesített méretét, de még csak nem is a tömörített adatmennyiségét, hanem amennyit a restic
ténylegesen feltölt, tehát deduplikáció » tömörítés » titkosítás után a tényleges helyfoglalást.
Mi valójában nem is látjuk, hogy a Te oldaladon mekkora adatmennyiségek vannak.
Ellenőrizhető¶
A mentéseket rendszeresen ellenőrizni kell. Nem csak a sértetlenségét (hogy vissza tudjuk-e olvasni az adatokat), hanem a teljeskörűségét is (hogy a visszaállított adatokból valóban mindenre kiterjedően helyre tudjuk állítani a védett rendszereinket). Ez utóbbit mi csak addig a pontig tudjuk ellenőrizni, hogy a másodlagos tárolókból (mirrorból / szalagokról) elvégezzük a visszaállítási tesztet, mert ennél jobban nem látunk bele a mentésekbe.
Viszont leírásokkal segítünk a visszaállítási tesztek (DR, azaz disaster recovery tesztek) teljeskörű végrehajtásában. A mi adatvisszaállítási tesztjeink eredményét jegyzőkönyv formájában is rendelkezésre bocsátjuk, ezzel a különféle auditkövetelmények teljesítésében is segíteni tudunk.
Árak¶
Online mentési tárhely¶
Ezek a csomagok online mentési tárhelyet tartalmaznak, amelyet a fentiek szerint folyamatosan mentünk az ötszörös védelem érdekében. Három típusból, azon belül is három méretből lehet választani (a méret természetesen később bővíthető).
5x-ös biztonság 5€-tól
A minimum követelményeknél magasabb szinten (5-5-5
) gondoskodunk a ránk bízott adatok hozzáférhetőségéről:
- 5 mentési példány
- 5-féle adathordozó
- 5 különböző helyszín
Ezt a védelmet mindhárom típusú tárh elyünknél egyformán biztosítjuk.
Business | Pro | Personal | |
---|---|---|---|
VPN kapcsolat lehetősége | ✅ | ❌ | ❌ |
Szolgáltatói audit DR naplók és riportok | ✅ | ❌ | ❌ |
Utalásos fizetés (Ft/EUR) lehetséges | ✅ | ❌ | ❌ |
Üzleti (ÁFÁ-s) számla (EUR) | ✅ | ✅ | ❌ |
Ingyenes extra 100G személyes tárhely vagy 10 nap ingyenes próbaidőszak |
❌ | ✅ | ❌ |
5-5-5 védelem | ✅ | ✅ | ✅ |
Tetszőleges mentési gyakoriság | ✅ | ✅ | ✅ |
Mentési státuszoldal (demo) | ✅ | ✅ | ✅ |
100G tárterület | 19€ | 9€ | 5€ |
1T tárterület | 39€ | 29€ | 19€ |
10T tárterület | 139€ | 129€ | 99€ |
Hűvösre tett adatok
Az archív (más néven offline / leválasztott) tárhely egy online mentési tárhelyből kapcsolható át (tartós adatmegőrzés céljából), ezután már nem érhető el távolról.
Kérésre újraéleszthető, így távolról is újra elérhetővé válik; adatokat lehet róla letölteni, illetve bővíteni újabb mentésekkel.
Archivált mentési tárhely¶
Archivált tárhely közvetlenül nem rendelhető, egy online tárhelyre való feltöltés után lehet kérni az archiválást. Az árak egységesek mindhárom csomag esetében:
Business / Pro / Personal | |
---|---|
100G tárterület | 2€ |
1T tárterület | 9€ |
10T tárterület | 49€ |
Fizetési módok, árfolyamok, kedvezmények
- Minden feltüntetett ár nettó havi díj.
- Magyarországi, EUR alapú (Business típusnál Ft is lehetséges), 27% ÁFA tartalmú számlát állítunk ki.
- Fizetési módok: bankkártyás fizetés (Stripe), előreutalás (csak Business csomagnál).
- Éves előfizetésnél 2 hónap kedvezményt adunk; csak 10 hónapi díjat számlázunk.
Megrendelés¶
Biztonságos fizetés
A Stripe megbízható pénzügyi szolgáltatóként megfelel a PCI-DSS követelményeinek, nekünk nem adja át a bankkártyád adatait: nem látjuk a teljes kártyaszámot, CVC kódot stb.
Az első és a későbbi automata fizetéseket a saját, minősített belső rendszerén keresztül intézi.
A Business csomagnál tudsz előreutalással is fizetni.
Megrendelést bankkártyás fizetésel az alábbi űrlapon tudsz kezdeményezni:
Első mentési tárhely megrendelése itt
Ha bármilyen segítség kell, írj nekünk a backup@elit.hu emailcímre. Segítünk a megrendelésben, műszaki információkban és az alábbiakban:
- további tárhelyek előfizetése
- méret upgrade (100G » 1T » 10T)
- Business tárhely megrendelése előreutalásos Ft vagy EUR alapú számlázással
- tárhely archív módba kapcsolása és visszaaktiválása
- adatörökös megadása vagy megváltoztatása
- szolgáltatás lemondása
Kérdések-válaszok¶
Miért EUR-ban vannak megadva az árak?
A legtöbb költségünk, így az LTO szalagok beszerzési árai, az online tárhelyek mögött álló adatközpontok bérleti díjai mind EUR alapúak, ezért hosszú távon gondolkodva praktikusnak tűnik EUR alapon számlázni.
Milyen gyorsan lehet tőletek visszaállítani adatot?
Online tárhely esetén azonnal eléred a mentéseidet, archivált (offline) tárhely esetében legkésőbb a következő munkanapon (NBD) tudjuk elindítani az online tárhellyé konvertálást. Jellemzően az archivált tárhelyekre olyan adatokat írnak ügyfeleink, amelyeknél a legfontosabb, hogy mindenképpen meglegyenek, nem az elérés gyorsasága az érdekes.
Csak asszimetrikus sávszélességem van, így is fogom tudni használni az online mentést?
Az első mentés valószínűleg elég sokáig fog tartani, de utána már a különbségek felküldése sokkal gyorsabban lezajlik majd - a tömörítés és a deduplikáció miatt minimálisra csökkentett hálózati forgalom mellett.
Betelt a tárhelyem, hogyan lehet bővíteni?
Nem tud betelni. Valójában technikailag nincs limitálva a tárhely mérete. Az előfizetett méret megközelítésekor küldünk egy értesítést, hogy mit tegyünk: archiváljunk vagy előfizetsz egy nagyobb csomagra. Ha megnézed az árlistát, láthatod, hogy nem lineáris az árazás, tehát sokkal jobban megéri "növeszteni" a tárhelyet, mint egy másikat létrehozni. Természetesen, ha van valami oka (pl. adatszeparáció, régi mentések szükségtelensége), természetesen van mód újabb és újabb tárhelyek létrehozásának.
Tényleg nem lehet mentést törölni?
Tényleg. Az append-only
mentés és a WORM szalagok
miatt ez egy technikai korlát, a korlát oka: "a biztonság mindenek előtt". Abszolút biztosak akarunk abban lenni, hogy amit egyszer feltöltesz hozzánk, az kőbe van vésve, azt soha senki és semmi nem változtathatja meg. Ameddig az előfizetésed él, az adataidat nálunk garantáltan megtalálod.
Nem fog így gyorsan betelni a tárhely, hogy nem lehet mentéseket törölni, és gyakran szeretnék menteni?
A tömörítés és a deduplikáció nagyon sokat segít. Mutatjuk az egyik webkiszolgálónk mentési adatait. Ezen 40 VPS szerver van "elszállásolva", mintegy 250 weboldallal, ebből 15 kiemelten nagy forgalmú webshop (rengeteg változással). A hozzá tartozó mentési tárhely 2023.02.01-tól naponta 4x teljes filerendszer + adatbázismentést tartalmaz, ez több mint 15 hónapon át kb. 1800 (x40) mentés statisztikája:
Original Size : 55019.21 GiB (100.00%)
Compressed Size : 26229.85 GiB ( 47.67%)
Deduplicated Size : 209.76 GiB ( 0.38%) stored on backup repository
Lehet több mentési tárhelyet használni egyszerre/felváltva?
Természetesen. Környezeti változó (RESTIC_REPOSITORY
) segítségével kiválaszthatod, hogy melyiket használod alapértelmezésként. Backendünket lehet shared repo-ként is használni, több hostról ugyanabba menteni, és egy hostról is lehet több repository-t használni értelemszerűen.
Lehet ezzel az eszközzel adatbázist is menteni?
Igen, például SQL adatbázisdump formátumban. Javasoljuk, hogy ne használj tömörítést a dump során, mert így a deduplikáció tudja tenni a dolgát, és az egymást követő mentésekben csak a módosult adatbázistartalom lesz benne). Elmentheted a filerendszerrel együtt az SQL exportfile-t, vagy akár közvetlenül is beleküldheted a dumpot a repository-ba:
mysqldump --all-databases --single-transaction=TRUE \
--hex-blob --routines --events --triggers --default-character-set=utf8 \
| restic backup --stdin --stdin-filename alldb.sql
Milyen a mentési tárhelyek rendelkezésreállása?
Minden szerverünk karbantartási időablaka elérhető az adott szolgáltatást igénybevevő ügyfeleink számára (az első értesítő levelünk tartalmazza), ami szerverenként más és más, heti 2 óra időtartamban (természetesen ez egy maximum érték, ennél tipikusan rövidebb idő alatt elkészülünk). Ebben az időablakban végezzük el a tervezhető üzemeltetési feladatokat (rendszerfrissítés, hardverbővítés, karbantartási feladatok). Az ezen kívüli nem várható eseményekre 99.8% SLA-t biztosítunk, figyelembevéve az adatközponti szolgáltatóink vállalt SLA szintjét is.
Mi lesz az adataimmal, ha velem történne valami?
Megadható egy "adatörökös", például cég esetében lehet egy másik tulajdonos vagy vezető tisztségviselő / jogi képviselő, magánszemély esetében pedig egy családtag/meghatalmazott, aki rendelkezhet ilyen esetben a mentésekkel.
Fontos, hogy a titkosító kulcsot mi nem kezeljük, így azt tőlünk független módon kell eljuttatnod az adatörökös számára. Enélkül a mentésekben foglalt adatok semmilyen módon nem visszaállíthatóak. Mi csak új hozzáférést adunk a megadott tárhelyhez az előre rögzített adatörökös számára. A sikeres adatvisszaállításhoz mindkét információra szükség van: a titkosító kulcsra és a hozzáférési adatokra.
Mi lesz az adataimmal, ha veletek történne valami?
Gondoskodtunk óvintézkedésekről: a megfelelő személyek adott esetben meg fognak kapni minden információt (akár a cégünk átvételével) ahhoz, hogy a szolgáltatást tovább tudják vinni, vagy legrosszabb esetben a mentési szolgáltatás esetleges leépítése előtt mindenki hozzájuthasson az adataihoz.
Milyen formában tudok hozzájutni a mentett adataimhoz?
A legegyszerűbb az online restic repository-ból letölteni a mentéseket. Különleges esetben, egyedi kérésre ki tudjuk írni LTO szalagra is (a titkosítás miatt csak egyben az egész repo-t tudjuk adni), és futárral elküldjük. A szalag tartalma (egyszerű tar formátum) diszkre felmásolva mint lokális restic repo - a titkosító kulcs birtokában - megnyitható vagy akár felmountolható.
Jelenleg az alábbi LTO formátumokat tudjuk írni: LTO-4, LTO-5, LTO-7, LTO-8.
Muszáj németországi / finnországi szervereket használni?
Előfordul, hogy valamilyen üzleti követelmény miatt az adatok, így a mentések sem hagyhatják el Magyarország területét. Ez egy műszakilag megoldható helyzet, de sajnos a standard árlistánk erre nem érvényes, egyedi árat tudunk rá adni. Továbbá az 5-5-5 sem tud maradéktalanul teljesülni, mert csak 3 magyarországi helyszínünk van.
Biztonságos ez a megoldás, interneten keresztül mentéseket feltölteni az érzékeny adataimról?
Több védelmi szint biztosítja a mentéseid titkosságát, mások számára megismerhetetlenségét. Még mi is csak azt az információt látjuk, hogy mikor indítottál mentést, és mekkora helyet foglal. A védelmi szintek a következők:
- A gépeden, ahol indítod a mentést, a deduplikációval és a tömörítéssel párhuzamosan helyben AES-256 titkosítás is történik, amelyhez a titkosító kulcs számunkra nem ismert.
- A hálózati kapcsolat TLS titkosítással, azonosított HTTPS protokollon keresztül épül fel a mentési tárhely felé. A már eleve titkosított mentés így duplán titkosított adatfolyamként látszik a végpontok (a géped és a szerverünk) között.
- Mindezt megfejelheted még egy WireGuard VPN eléréssel (Business csomag esetében), ami további titkosítási réteget alkalmaz az előbbi kettő fölött.
- VPN használatakor a mentési tárhelyed nyilvános internes elérését le is lehet tiltani, így kizárólag VPN-en lesz elérhető, a saját belső hálózatodból. Ráadásul a WireGuard VPN szerverünk "lopakodó" módban működik, csak akkor válaszol bármilyen kapcsolódási kísérletre, ha a megfelelő titkos kulcsoddal kezdeményezel, egyébként láthatatlan a külvilág számára.
Nincs fix IP címem, működhet így is a VPN?
Tökéletesen. A WireGuard "betárcsázós" üzemmódban is képes üzemelni.
A tárhely elérhető IPv6 hálózaton?
Természetesen, minden tárhely saját IPv6 címmel is rendelkezik. A saját backup repository-hoz tartozik egy anonimizált hostnév AAAA és A rekordokkal, így ha a géped rendelkezik működő IPv6 címmel, alapértelmezettként a restic azon keresztül fog kapcsolódni. Ha ennek ellenére inkább IPv4 hálózaton szeretnél kapcsolódni, környezeti változóban átírhatod a connect stringet.
Mi történik, ha kompromittálódik / megfertőzödik a gépem, nem tudnak kárt okozni a mentésben?
Ahogy írtuk fentebb, a mentésekből fizikailag lehetetlen törölni, még a hozzáférés és a titkosító kulcs teljes ismeretében sem lehetséges. Így a mentések gyakoriságától függően tudod minimalizálni az adatvesztést. Bármelyik mentés állapotát vissza tudjuk adni (és persze a közreműködésünk nélkül le tudod tölteni). Csak nemfizetéssel lehet "inaktiválni" a tárhelyet, de teljesen törölni még így sem tudjuk.
Tehát folyamatos előfizetés nélkül is eltároljátok az adataimat?
Ahogy írtuk, a mentéseid tényleg "kőbe vannak vésve". Ez azt jelenti, hogy a WORM szalagokon egy példányban előfizetés megszűnése után is ott maradnak a szalag élettartamáig (hiszen fizikailag letörölhetetlen). Viszont csak ebből a forrásból a túl régi mentések visszaállítása több időbe telhet, ezért a nem élő előfizetéssel rendelkező tárhely sikeres visszaállításakor kiszámlázzuk a kieső időszakra is az archivált mentési tárhely díját.
Természetesen folyamatos előfizetés nélkül - az egyszeres védelem miatt - nem tudunk garanciát és SLA-t vállalni a mentések visszaállítására.
Viszont ha már úgyis mindenképpen ki kell fizetni az archív tárhelyet, praktikusabb folyamatosan fenntartani a szolgáltatást (az archivált tárhely díja nagyon kedvező), mert így - megkapva a maximális védelmet - a napi differenciális szalagos mentéseken kívül külön, egyben is archiváljuk a tárhelyet (szalagon és offline HDD tömbön is); így sokkal gyorsabban visszaállítható.
Nem túlzás ez az 5-5-5 szintű védelem?
Nagyon alaposan végiggondoltuk a lehetséges rizikófaktorokat. Ha tényleg mindentől meg szeretnénk védeni a ránk bízott mentéseket, mindegyik védelmi szintre szükség van.
Unalmas, de szükséges IT dokumentumok
DRP - Disaster Recovery Plan: katasztrófa-utáni helyreállítási terv, a kritikus informatikai funkciók és adatok elvárt időn belüli visszaállítására fókuszál katasztrófa vagy váratlan esemény után.
BCP - Business Continuity Plan: üzletmenet-folytonossági terv, a kritikus folyamatok összetevőit tartalmazza. Célja, hogy minimalizálja a leállásokat és adatveszteségeket, biztosítva a szervezet folyamatos működését.
Felmérés, tanácsadás¶
Ha bizonytalan vagy rendszereid mentési megoldásait illetően, szívesen segítünk meghatározni a kockázatokat, felmérni a biztonsági mentések állapotát, kidolgozni a DRP/BCP terveket, megvalósítani a mentési rendszereket (akár függetlenül a mi backup szolgáltatásunktól).
Ha pedig további kérdéseid vannak a backup szolgáltatásról, szívesen válaszolunk emailben.
Tanácsadás - backup témában is Keress minket - elérhetőségek
Viszonteladói program¶
Ha tetszik amit csinálunk, és fejlesztőként vagy üzemeltetőként a mi szolgáltatásunk segítségével szeretnéd ügyfeleid adatait megvédeni (vagy egyszerűen csak továbbajánlani másoknak), szívesen adunk egy olyan ajánlatot, amivel mindenki jól jár. Csak írj nekünk a backup@elit.hu címre, és megtárgyaljuk!
Persze műszakilag lehetséges, hogy becsatornázod az összes általad üzemeltetett rendszert egy közös backup repository-ba, de így kicsit körülményesebb a mentéseket egymástól függetlenül kezelni vagy szétválasztani (a --tag
címkékkel és a --host
opcióval lehetséges), a hozzáférési jogosultság is közös; ezért praktikusabb inkább több kisebb, önálló repo-t létrehozni.