Byggde krypterade säkerhetskopior utanför värden med restic, med gallring enligt lagringstid, en integritetskontroll och en månatlig automatiserad återläsningsövning, granskade sedan återställningsförmågan och skrev ner luckorna i stället för att låta dem upptäckas under en incident.
Arbetet utfört: september 2026
krypterade säkerhetskopior, med en månatlig återläsningsövning
Situation. Allt som företaget har — git‑repona, databasen, webbplatsen — låg på en enda molninstans, och leverantörens ögonblicksbild av den var hela återställningsberedskapen. En ögonblicksbild hos leverantören är bra att ha och dålig att förlita sig på: den ligger i samma konto som maskinen den skyddar, den krypteras inte av någon här, och ingen hade någonsin återställt något från en sådan.
Uppgift. Säkerhetskopiorna måste vara krypterade, ligga utanför värden, gallras enligt en bevarandepolicy och — den del som brukar hoppas över — faktiskt användas för återställning, enligt ett schema, utan att någon person behöver komma ihåg att göra det.
Handling. Säkerhetskopieringen körs på en systemd‑timer: en databasdump där det finns en databas, därefter en krypterad, deduplicerad ögonblicksbild till lagring hos en annan leverantör via SFTP, sedan en gallring enligt bevarandepolicyn och sist en integritetskontroll. Ett dödmansgrepp pingas bara när körningen lyckas, och det är den distinktionen som gör det till ett larm i stället för en logg — en körning som misslyckas säger ingenting, och det är tystnaden som utlöser larmet. Separat körs en återställningsövning varje månad: den hämtar ut en känd fil ur repot och jämför den, så att det som kontrolleras är en återställning och inte en säkerhetskopiering. Lösenfrasen skrivs till en fil som enheterna läser i stället för att skickas via miljön, eftersom tjänstehanteraren tolkar escape‑tecken i miljövärden och en lösenfras med ett omvänt snedstreck i tysthet skulle ha blivit en annan än den som skapade repot. Efteråt granskades återställningsberedskapen och dokumenterades, och de återstående luckorna namngavs i dokumentet i stället för att lämnas åt att upptäckas under en incident.
Resultat. Företaget kan förlora värden och få tillbaka sina data, och den meningen vilar på en återställning som kördes förra månaden snarare än på en säkerhetskopiering som kördes i natt. Granskningens mest värdefulla resultat var listan över det som fortfarande inte täcks, och det är den del som en grön säkerhetskopieringsrapport av strukturella skäl aldrig kan berätta för någon.
Se tillbaka på Drev hela företaget på en enda värd med 512 MB och en kärna — en git‑forge, en webbserver för sju domäner, Tor, två servrar för alternativa protokoll, säkerhetskopiering och intrångsblockering — genom att behandla 464 MB användbart minne som den bindande arkitektoniska begränsningen. Läs vidare: Byggde övervakning med dödmansgrepp som pingar bara så länge minne och disk är i gott skick, så att en försämrad värd larmar genom att tystna — och upptäckte sex variabelnamn som sa ”free” där kontrollen korrekt mätte ”available”, en storleksordning isär på en maskin med 464 MB. Eller ta en titt på hela portföljen.
För kunder kallar vi den här Säkerhetskopior som faktiskt har återställts — se den tillsammans med de andra fallen.
En del av en längre historik — och den finns i sin helhet här.
Varje post är skriven på samma sätt: situationen, uppgiften, vad vi gjorde och vad som förändrades.