Kezdőlap›Útmutatók›Mi a teendő, ha…
Mi a teendő, ha…
Sikertelen volt az éjszakai mentés
Egy éjszaka sikertelen mentés nem katasztrófa, hanem késés: az utolsó ép másolat legalább 48 órás, ha az előző napi sikeres volt. Több egymást követő sikertelen mentés már védelmi incidens: az okát még aznap fel kell deríteni, nem elég nyugtázni a riasztást.
Frissítve: 2026. október3 perc olvasás5 hivatkozott forrás
A lényeg
- Olvassa el a hibaüzenetet, ne csak a piros jelzést nézze: hely, hiányzó forrás, hitelesítő adatok, zárolt fájlok, sávszélesség, leállt ügynök.
- Egy „sikeres” feladat üres mappát is másolhatott: nézze meg a másolt mennyiséget.
- Jegyezze fel az utolsó sikeres mentés dátumát, és közölje az érintett részleg vezetőjével.
- A javítás után indítsa újra, majd ellenőrizze a következő éjszakát.
- Egy hónapon belül három sikertelen mentés ugyanazon a gépen: a beállításokon változtasson, ne csak az „újraindítás” gombot nyomja meg.
1. Olvassa el a hibát, ne csak a piros jelzést nézze
A szokásos okok, megjelenésük sorrendjében:
| Ok | Jel | Javítás |
|---|---|---|
| Elfogyott a hely a céltárhelyen, vagy betelt a kvóta | Írási hiba, rövidülő megőrzési idő | A tárhely növelése, vagy az előzmények tudatos rövidítése |
| Kikapcsolt forrás, hálózaton kívül, megváltozott elérési út | Átnevezett meghajtóbetűjel vagy megosztás; „sikeres” feladat egy üres mappán | A forrás helyreállítása, az elérési út javítása, a másolt mennyiség ellenőrzése |
| Elutasított hitelesítő adatok | Lejárt szolgáltatásfiók-jelszó | A fiók helyreállítása: különben minden éjszaka sikertelen lesz |
| Zárolt fájlok vagy nem nyugalmi állapotba hozott adatbázis | Részleges másolat | A nyitott adatbázisokhoz előírt módszer alkalmazása; egy ilyen állapotú SQL-adatbázis nem állítható vissza tisztán |
| Túl lassú vagy megszakadt kapcsolat | Az időablak végén megszakadt feladat | Hatékonyabb növekményes mentés, hosszabb időablak, vagy kevesebb szükségtelen adat |
| Leállt ügynök a gépen | Nincs küldés | A szolgáltatás újraindítása, a leállás okának felderítése |
A legmegtévesztőbb eset a zöld feladat egy üres mappán. Az ANSSI, a francia nemzeti kiberbiztonsági ügynökség előírja, hogy a mentést rendszeresen ellenőrizni kell, különösen figyelve az ellentmondásos adat- vagy fájlmennyiségre, a hálózati lassulásokra és a konfigurációs változásokra. Ha a másolt mennyiség egyik éjszakáról a másikra hirtelen lecsökken, az ugyanannyi figyelmet érdemel, mint egy sikertelen mentés.
2. Mikor volt az utolsó sikeres mentés?
Ez az egyetlen dátum, amely az aznapi RPO szempontjából számít. Ha néhány napnál régebbi, közölje az érintett részleg felelősével. Ő védőháló nélkül dolgozik, ezt tudnia kell. Ha ezt a mondatot kihagyva csak nyugtázza a riasztást a konzolban, ez az a lépés, amely két héttel később egy incidensből adatvesztést csinál.
3. Újraindítás a javítás után
Az ok elhárítása után indítson el kézzel egy feladatot. Várja meg, amíg befejeződik. Ha az újraindítás is sikertelen, az ok még mindig fennáll. Másnap reggel ellenőrizze a következő éjszakát: sok „nyilvánvaló” javítás nem éli túl a második futást.
Egy sikeres feladat azt bizonyítja, hogy egy másolat kiírásra került, azt nem, hogy vissza is állítható. SQL Server-adatbázis esetén a Microsoft kiemeli, hogy a mentés-ellenőrző parancs nem vizsgálja a benne lévő adatok szerkezetét. Az ANSSI előírja, hogy a mentéseket rendszeresen tesztelni kell, írásban rögzített visszaállítási eljárással; a NIST szintén a mentések tesztelését javasolja annak biztosítására, hogy a fájlok hiba nélkül helyreállíthatók. Egy mentési incidens után egy fájl vagy adatbázis próbavisszaállítása a legjobb ellenőrzés. Lásd: Hogyan teszteljük, hogy működik-e a mentés?.
4. Ha ismétlődik
Egy hónapon belül három sikertelen mentés ugyanazon a gépen: a mentési kör, a sávszélesség vagy a termék nem megfelelő. Változtasson egy paraméteren (zárjon ki egy hatalmas és szükségtelen mappát, ossza fel a feladatot, növelje a tárhelyet), ne érje be azzal, hogy minden hétfőn kézzel újraindítja.
Reggeli ellenőrzőlista
- Minden éjszakai feladat befejeződött, és nem csak „nem hibás”?
- A másolt mennyiség összhangban van az előző éjszakákéval?
- Minden kritikus gép utolsó sikeres mentése 24 óránál frissebb?
- A riasztásokat egy kijelölt személy elolvasta, és nem csak megérkeztek?
- A céltárhelyen maradt szabad hely fedezi a tervezett megőrzési időt?
A WeDoBacknél
A napi 24 órás felügyelet a mentésekre terjed ki, és riasztást küld, ha egy mentés nem fejeződik be. A riasztás ennek az oldalnak az eleje, nem a vége. Az INTEGRAL ajánlatban havi két óra támogatás fordítható az ok elhárítására. A SMART ajánlatban a támogatást eseti alapon számlázzuk: a hiba az ügyfél számára látható a konzolban, és az ő feladata elolvasni. A támogatás a +33 9 72 50 78 28 számon érhető el 9:00 és 13:00, valamint 14:00 és 17:30 között (párizsi idő szerint). A tárhely méretezéséhez a közzétett irányszám a jelenlegi adatmennyiség háromszorosa, majd egyhetes használat után kiigazítás: a túl szűkre szabott tárhely a sikertelen feladatokból vagy a rövidülő megőrzési időből látszik. Az ügyfélnél lévő titkosítási kulcsnak nincs szerepe a küldés sikertelenségében: ha a feladat sikertelen, a távoli másolat egyszerűen nem frissült.
Gyakori kérdések
Egy sikertelen éjszaka súlyos probléma?
Ritkán, ha az előző éjszaka sikeres volt, és az okot napközben kijavítják. A kockázat a halmozódásból ered: minden sikertelen éjszaka növeli azt a munkamennyiséget, amely katasztrófa esetén elveszne. Néhány napon túl ez már a vezetésnek jelentendő incidens.
Elegendő bizonyíték a „sikeres” állapot arra, hogy a mentés jó?
Nem. Az ANSSI, a francia nemzeti kiberbiztonsági ügynökség a mentések rendszeres ellenőrzését írja elő, különösen az ellentmondásos adatmennyiségekét, valamint rendszeres visszaállítási teszteket. SQL Server esetén a Microsoft kiemeli, hogy a mentés ellenőrzése nem vizsgálja a benne lévő adatok szerkezetét: ezt csak egy tényleges visszaállítás, majd azt követő konzisztenciavizsgálat bizonyítja.
Kinek kell figyelnie a mentési riasztásokat?
Egy kijelölt személynek, szabadság idejére helyettessel. Az olyan közös postafiókba érkező riasztás, amelyet senki sem olvas, egyenértékű a riasztás hiányával. Döntse el azt is, ki értesíti a vezetést, ha az utolsó sikeres mentés óta eltelt idő meghalad egy előre egyeztetett küszöbértéket.
Források
A dokumentumokat 2026 októberében tekintettük meg.
- Információs rendszerek mentése – Alapelvek (ANSSI-BP-100, v1.1, 2025. november 27.) — ANSSI (francia ügynökség)
- Cybersecurity guide for SMEs (angol nyelven, 2021. június) — ENISA
- RESTORE VERIFYONLY (Transact-SQL) — Microsoft Learn
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
- Ajánlatok és árak — WeDoBack
Azonnal segítségre van szüksége?
Ne állítson vissza semmit, amíg nem azonosított egy ép másolatot. Segítünk eligazodni.
Hívja a +33 9 72 50 78 28 számotvagy írjon nekünkFolyamatban lévő incidens?
Csapatunk segít azonosítani a megfelelő másolatot és elvégezni a visszaállítást, hétfőtől péntekig 9:00–13:00 és 14:00–17:30 között.
