Vad bör en Docker-säkerhetskopia innehålla utöver mediebiblioteket?
En Docker-säkerhetskopia måste bevara distributionsdefinitionen, applikationens tillstånd, databaser, autentiseringsuppgifter och återställningsproceduren – inte bara de utbytbara mediefilerna.
Filmer, musik och foton kan vara den största datamängden, men om Compose-filer, appdatabaser, metadata, användarkonton, certifikat, krypteringsnycklar eller monteringsmappningar går förlorade kan biblioteket bli oanvändbart eller kräva veckor av återuppbyggnad. En tillförlitlig säkerhetskopiering börjar med frågan ”Vad måste finnas för att återskapa tjänsten på en tom värd?” och skyddar varje nödvändigt lager med en applikationskonsistent metod.
Säkerhetskopiera distributionsdefinitionen
Bevara alla Compose-filer, override-filer, Dockerfiles, byggkontexter, stacknamn, avbildningstaggar, kommandon, portmappningar, nätverk, volymdeklarationer, hälsokontroller, omstartspolicyer och resursgränser som krävs för att återskapa containrarna.
En diskussion om självhostning beskriver hur man håller varje applikations Compose- och miljöfiler tillsammans så att stacken kan distribueras på nytt på ett förutsägbart sätt. Då blir distributionskonfigurationen en förstklassig säkerhetskopieringsresurs i stället för att man förlitar sig på en körande container som dokumentation.
Notera exakta avbildningsversioner i stället för enbart flytande taggar som latest. Lagra konfiguration i versionshantering där det är lämpligt, men håll hemligheter borta från offentliga arkiv och inkludera en skyddad förteckning över nödvändiga externa beroenden.
Skydda alla beständiga bind-monteringar och namngivna volymer
Lista monteringar som är kopplade till varje tjänst och klassificera dem som utbytbar cache, applikationskonfiguration, metadata, databas, uppladdat innehåll, genererade miniatyrbilder eller kritiskt tillstånd. Säkerhetskopiera alla sökvägar som inte kan återskapas.
En diskussion på OpenMediaVault anger att den viktiga återställningsmängden består av Compose-definitionen plus beständiga data, medan containeravbildningar vanligtvis kan laddas ned igen. Det skiljer beständigt tillstånd från utbytbara containeravbildningar.
Inkludera dolda applikationskataloger och små metadatavolymer, inte bara den stora biblioteksmonteringen. Kontrollera att källsökvägar för bind-monteringar ingår i värdens säkerhetskopiering och att namngivna volymer exporteras med en metod som bevarar ägarskap och behörigheter.
Skapa databaskonsistenta säkerhetskopior
Identifiera PostgreSQL, MariaDB, MySQL, MongoDB, SQLite, Redis-persistens och inbäddade databaser. Använd databasens stödda dumpnings-, ögonblicksbilds- eller pausade säkerhetskopieringsprocess i stället för att kopiera filer medan transaktioner ändras.
En diskussion om säkerhetskopiering av Docker-volymer på Stack Overflow visar hur en volym kan monteras i en tillfällig container för att skapa ett arkiv, men databasfiler kräver fortfarande medvetenhet om konsistens. Ett rått volymarkiv är inte automatiskt en giltig transaktionssäkerhetskopia av en databas.
Dokumentera motorversion, databasnamn, användare, tillägg och återställningsordning. Testa en logisk dump separat från filsystemsbackupen så att den ena metoden kan återställa systemet när den andra är ofullständig.
Bevara hemligheter, certifikat och identitet
Säkerhetskopiera skyddade kopior av miljöhemligheter, API-token, databaslösenord, OAuth-klientuppgifter, TLS-certifikat, privata nycklar, SSH-nycklar, krypteringsnycklar och återställningskoder för applikationer.
Hemligheter bör lagras separat från vanliga Compose-filer och krypteras med en återställningsmetod som inte är beroende av den havererade Docker-värden. Säkerhetskopian måste innehålla tillräckligt med sammanhang för att man ska veta vilken tjänst och variabel varje hemlighet ska återställas till.
Utelämna inte krypteringsnycklar för krypterade databaser eller lagringsutrymmen. En perfekt kopia av krypterade data kan inte återställas om nyckeln, lösenfrasen eller konfigurationen för nyckelhantering går förlorad.
Inkludera reverse proxy, DNS, jobb och värdantaganden
Bevara reverse proxy-rutter, middleware, åtkomstkontroller, DNS-poster, DDNS-konfiguration, schemalagda jobb, uppdateringspolicyer, brandväggsregler, GPU-enhetsmappningar, UID- och GID-tilldelningar samt monteringsenheter för lagring.
En produktöversikt för säkerhetskopiering betonar att tillförlitligt volymskydd också kräver schemaläggning, lagringstid, kryptering, destinationskontroll och synlig körningshistorik. Dessa driftuppgifter förvandlar ett engångsarkiv till ett repeterbart säkerhetskopieringsarbetsflöde.
Dokumentera vilka värdkataloger, nätverk, kärnfunktioner och enheter som måste finnas innan Compose startas. Utan dessa antaganden kan återställda containrar skapa tomma reservkataloger, använda fel behörigheter eller starta utan hårdvaruacceleration.
Bevisa säkerhetskopian genom en återställning på en tom värd
Återställ till en isolerad testvärd eller virtuell maskin med endast säkerhetskopian och de skriftliga instruktionerna. Återskapa lagringssökvägar, hemligheter, databaser, proxy-rutter och containrar i den dokumenterade ordningen.
ZimaSpaces guide om att återställa en delad mapp på ett säkert sätt bygger på samma princip: en säkerhetskopia är tillförlitlig först efter att en kontrollerad återställning har bekräftat dess omfattning.
Validera inloggning, behörigheter, databasintegritet, metadata, miniatyrbilder, uppspelning, uppladdningar, schemalagda jobb, TLS och en andra omstart. Dokumentera återställningstiden och uppdatera checklistan för säkerhetskopiering varje gång återställningen avslöjar ett saknat beroende.
Rekommenderade produkter
Support och tips
Mer att läsa
Varför återskapar en återställning av en Docker-volym filinnehållet men tar bort utökade attribut?
En felsökning av volymåterställning som omfattar inventering av xattr, alternativ för tar och Rsync, namnrymder, stöd för måldestinationen, behörigheter, etiketter, appmetadata och tester.
Varför behåller en körande container sin gamla minnesgräns efter att Compose-filen har ändrats?
En minnesgränsdiagnos som omfattar aktiva cgroups, omstart kontra återskapande, Compose-fält, hårda och mjuka gränser, överordnade scope, växlingsutrymme och körningsheapar.
Varför ogiltigförklarar en omstart av en omvänd proxy varje session för en självhostad app?
En sessionsförlustdiagnos som omfattar omstartens omfattning, cookie-ägarskap, rotation av hemligheter, cachebaserade sessioner, sticky routing, autentiseringsgatewayer och återställning.
