Vad gör vi om…

Nattens säkerhetskopiering misslyckades

En säkerhetskopiering som misslyckas en natt är ingen katastrof, utan en fördröjning: den senaste friska kopian är minst 48 timmar gammal om körningen natten innan lyckades. Flera misslyckanden i rad är en skyddsincident: orsaken söks samma dag, man nöjer sig inte med att kvittera larmet.

Uppdaterad i oktober 20263 min läsning5 citerade källor

Det viktigaste

Läs felmeddelandet, inte bara den röda lampan: utrymme, saknad källa, inloggningsuppgifter, låsta filer, bandbredd, stoppad agent.
Ett ”lyckat” jobb kan ha kopierat en tom mapp: titta på den kopierade storleken.
Anteckna datumet för den senaste lyckade körningen och meddela den ansvarige för den berörda verksamheten.
Kör om efter åtgärd och kontrollera sedan nästa natt.
Tre misslyckanden på en månad på samma maskin: ändra inställningarna, tryck inte bara på ”kör igen”.

1. Läs felet, inte bara den röda lampan

De vanliga orsakerna, i den ordning de brukar dyka upp:

Orsak	Tecken	Åtgärd
Slut på utrymme på målet, eller nådd kvot	Skrivfel, lagringstid som krymper	Öka volymen, eller korta historiken med full insikt om konsekvenserna
Källan avstängd, utanför nätverket, ändrad sökväg	Enhetsbokstav eller delad resurs som bytt namn; ”lyckat” jobb på en tom mapp	Återställ källan, rätta sökvägen, kontrollera den kopierade storleken
Inloggningsuppgifter nekade	Lösenordet för tjänstekontot har gått ut	Återställ kontot: annars misslyckas varje natt
Låsta filer eller databas som inte har förts till viloläge	Ofullständig kopia	Använd den metod som är avsedd för öppna databaser; en SQL-databas i det tillståndet går inte att återställa korrekt
För långsam eller bruten förbindelse	Jobbet avbryts i slutet av tidsfönstret	Effektivare inkrementell kopiering, längre tidsfönster eller mindre onödiga data
Agenten stoppad på maskinen	Inget skickas	Starta om tjänsten, ta reda på varför den stoppades

Det mest vilseledande fallet är det gröna jobbet på en tom mapp. ANSSI, Frankrikes nationella cybersäkerhetsmyndighet, kräver att säkerhetskopieringen alltid kontrolleras, bland annat genom att bevaka orimliga data- eller filvolymer, långsamt nätverk och konfigurationsändringar. En kopierad storlek som plötsligt sjunker från en natt till nästa förtjänar lika mycket uppmärksamhet som ett misslyckande.

2. Ta reda på när den senaste lyckade körningen var

Det är det enda datum som räknas för dagens RPO. Om det är mer än några dagar gammalt, säg det till den som ansvarar för den berörda verksamheten. Hen arbetar utan skyddsnät och måste veta det. Att kvittera larmet i konsolen utan att säga detta är det som förvandlar en incident till dataförlust två veckor senare.

3. Kör om efter åtgärd

Starta ett manuellt jobb när orsaken är åtgärdad. Vänta tills det är klart. Om omkörningen misslyckas finns orsaken kvar. Kontrollera nästa natt på morgonen därpå: många ”självklara” åtgärder håller inte vid andra körningen.

Ett lyckat jobb bevisar att en kopia har skrivits, inte att den går att återställa. För en SQL Server-databas anger Microsoft att kommandot för att verifiera en säkerhetskopia inte kontrollerar strukturen hos de data den innehåller. ANSSI kräver att säkerhetskopior testas regelbundet, med en skriftlig återställningsrutin; NIST rekommenderar också att säkerhetskopior testas för att säkerställa att filerna kan återskapas utan fel. Efter en incident med säkerhetskopieringen är en teståterställning av en fil eller en databas den bästa kontrollen. Se Hur testar man att en säkerhetskopia fungerar?.

4. Om det upprepas

Tre misslyckanden på en månad på samma maskin: omfånget, bandbredden eller produkten är inte anpassade. Man ändrar en inställning (utesluter en jättestor och onödig mapp, delar upp jobbet, ökar lagringen), man nöjer sig inte med att köra om manuellt varje måndag.

Morgonens checklista

Är alla nattens jobb slutförda, och inte bara ”utan fel”?
Är den kopierade storleken rimlig jämfört med tidigare nätter?
Är den senaste lyckade körningen för varje kritisk maskin mindre än 24 timmar gammal?
Har larmen lästs av en namngiven person, och inte bara tagits emot?
Räcker det kvarvarande utrymmet på målet för den planerade lagringstiden?

Hos WeDoBack

Övervakningen dygnet runt omfattar säkerhetskopiorna och skickar ett larm när en säkerhetskopiering inte slutförs. Larmet är början på den här sidan, inte slutet. I INTEGRAL kan två timmars support per månad användas för att åtgärda orsaken. I SMART debiteras supporten per insats: misslyckandet syns för kunden i konsolen, och det är kundens uppgift att läsa det. Supporten nås på +33 9 72 50 78 28, kl. 9.00–13.00 och 14.00–17.30 (Paris-tid). För att dimensionera lagringen är den publicerade tumregeln den nuvarande volymen gånger tre, följt av en justering efter en veckas användning: en för snål volym syns på jobb som misslyckas eller på en lagringstid som krymper. Krypteringsnyckeln, som kunden innehar, spelar ingen roll när överföringen misslyckas: om jobbet misslyckas har fjärrkopian helt enkelt inte uppdaterats.

Ring +33 9 72 50 78 28 Upptäck erbjudandet INTEGRAL

Vanliga frågor

Är en misslyckad natt allvarlig?

Sällan, om natten innan lyckades och orsaken åtgärdas under dagen. Risken ligger i ackumuleringen: varje misslyckad natt ökar mängden arbete som skulle gå förlorad vid en katastrof. Efter några dagar är det en incident som ska rapporteras till ledningen.

Räcker statusen ”lyckad” för att bevisa att en säkerhetskopia är bra?

Nej. ANSSI, Frankrikes nationella cybersäkerhetsmyndighet, kräver systematisk kontroll av säkerhetskopior, särskilt av orimliga datavolymer, och regelbundna återställningstester. För SQL Server anger Microsoft att verifieringen av en säkerhetskopia inte kontrollerar strukturen hos de data den innehåller: bara en verklig återställning, följd av en konsistenskontroll, bevisar det.

Vem ska bevaka larmen för säkerhetskopieringen?

En namngiven person, med en ersättare under semestrar. Ett larm som hamnar i en delad låda som ingen läser är detsamma som inget larm. Bestäm också vem som informerar ledningen när den senaste lyckade körningen överskrider en i förväg överenskommen gräns.

Läs vidare

Källor

Dokument som konsulterades i oktober 2026.

Säkerhetskopiering av informationssystem – grunderna (ANSSI-BP-100, v1.1, 27 november 2025) — ANSSI (fransk myndighet)
Cybersecurity guide for SMEs (på engelska, juni 2021) — ENISA
RESTORE VERIFYONLY (Transact-SQL) — Microsoft Learn
SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
Erbjudanden och priser — WeDoBack

Behöver ni hjälp nu?

Återställ ingenting innan ni har identifierat en ren kopia. Vi kan vägleda er.

Ring +33 9 72 50 78 28 eller skriv till oss

Pågående incident?

Vårt team hjälper er att identifiera rätt kopia och återställa, måndag–fredag kl. 9.00–13.00 och 14.00–17.30 (CET).

Ring +33 9 72 50 78 28 Skriv till teamet