Kan du återställa en containeravbildning utan att förlora appdata?

Ja, du kan rulla tillbaka en containeravbild utan att förlora appdata när det beständiga tillståndet finns utanför containern och förblir kompatibelt med den äldre versionen.

På en hem-NAS återskapas normalt bara programmets körmiljö när avbilden byts ut, medan namngivna volymer eller bind-monteringar behåller databaser, inställningar och användarfiler. Den farliga gränsen är schemaändringar: en nyare avbild kan migrera databasen eller skriva om konfigurationen på ett sätt som den äldre avbilden inte kan läsa. Innan du rullar tillbaka bör du spara de aktuella monteringspunkterna, avbildens identitet, konfigurationen, hemligheterna och en konsekvent säkerhetskopia av data.

Frys det aktuella tillståndet innan du ändrar avbilden

Stoppa automatiska avbildsuppdateringar och dokumentera aktuell avbildstagg, oföränderlig digest, containerkonfiguration, miljövariabler, nätverk, portar, monteringar, omstartspolicy och hälsokontroll. Spara compose-filen eller den exporterade konfigurationen separat från containern.

Ett arbetsflöde för återställning av NAS-containrar rekommenderar att du har en känd tidigare avbild tillgänglig i stället för att förlita dig på en föränderlig latest-tagg. Den användbara återställningspunkten är den specifika tidigare avbildsversionen tillsammans med konfigurationen som körde den.

Ta en applikationskonsistent säkerhetskopia eller ögonblicksbild av databasen innan du stoppar den nyare versionen. Utgå inte från att den befintliga volymen är en återställningskopia, eftersom den redan kan innehålla schema- eller dataändringar som uppdateringen har gjort.

Bekräfta att appdata finns utanför det skrivbara lagret

Kartlägg alla namngivna volymer och bind-monteringar och identifiera databaser, uppladdningar, insticksprogram, certifikat, cache eller konfiguration som fortfarande bara lagras i containerns skrivbara lager.

Beständig lagring överlever att containern byts ut endast när den nya containern återansluter till samma externa dataplats. SynoForums arbetsflöde för avbildsversioner kontrollerar uttryckligen att volymdata finns kvar på NAS-lagringen innan en container återskapas från en annan avbild.

Om kritiska data bara finns i det skrivbara lagret ska du kopiera eller exportera dem innan du tar bort den aktuella containern. Se den extraktionen som ett återställningssteg, inte som ett skäl att behålla en versionslös container på obestämd tid.

Lås fast den exakta äldre avbilden i stället för att återanvända latest

Hämta eller leta fram den senast kända fungerande taggen eller digest-värdet och uppdatera endast avbildsreferensen. Kontrollera arkitektur, programutgåva och nödvändiga miljövariabler innan du återskapar tjänsten.

Användare som rullar tillbaka Compose-hanterade tjänster återgår vanligtvis till en tidigare uttrycklig avbildsversion i stället för att be Docker backa en körande container på plats. En praktisk diskussion om återställning fokuserar på att ändra den låsta Compose-avbildstaggen och återskapa tjänsten.

Använd inte en gammal cachad avbild vars identitet är okänd. Dokumentera digest-värdet efter hämtningen så att en annan återskapning inte i tysthet väljer en annan binär under samma föränderliga tagg.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Kontrollera om den nyare versionen ändrade databasen

Läs programmets versionsinformation och migreringsloggar för versionerna mellan återställningsmålet och den aktuella avbilden. Leta efter irreversibla schemaändringar, omskriven konfiguration, ändringar av krypteringsnycklar eller uppgraderingar av insticksprogram.

Återställning av en databas är svårare än återställning av en avbild, eftersom programkod och schema måste förbli kompatibla. Octopus beskriver bakåtkompatibla migreringar som ett krav när gamla och nya programversioner kan samexistera eller behöva återställas, vilket gör schemakompatibilitet mellan versioner till den avgörande gränsen för återställningen.

Om den äldre avbilden inte kan läsa den migrerade databasen ska du återställa databassäkerhetskopian från före uppgraderingen i stället för att rikta den gamla koden mot det nya tillståndet. Bevara den aktuella databasen separat ifall återställningen själv måste ångras.

Återskapa tjänsten med samma beständiga sökvägar

Stoppa och återskapa applikationscontainern med den äldre avbilden samtidigt som du behåller samma verifierade namngivna volymer eller bind-monteringar. Använd inte kommandon eller alternativ i gränssnittet som tar bort volymer.

Behåll nätverksnamn, tjänstealias, publicerade portar, UID/GID-mappningar, hemligheter och mål för omvänd proxy konsekventa, såvida inte den äldre versionen kräver en dokumenterad skillnad. En container som startar korrekt med fel monteringar kan skapa en ny tom app och se ut som dataförlust.

Inspektera monteringslistan och programmets loggar innan du loggar in eller låter bakgrundsjobb köras. Om appen initierar en ny databas ska du stoppa omedelbart och korrigera datasökvägen i stället för att importera till fel plats.

Validera återställningen och behåll en väg framåt

Testa inloggning, läsning och skrivning i databasen, uppladdningar, schemalagda jobb, integrationer och en kontrollerad omstart. Jämför ett urval av poster och filer med inventeringen från före återställningen.

ZimaSpaces arbetsflöde för ögonblicksbilder av appdata före uppdateringar utgör det säkrare förberedelsesteget inför framtida uppgraderingar.

Återställningen är klar först när den gamla avbilden använder avsedd beständig data, schemat är kompatibelt eller återställt och tjänsten överlever ännu en återskapning. Behåll den nyare avbilden, dess säkerhetskopia av data och anteckningarna om återställningen tills den gamla versionen har varit stabil under den normala arbetsbelastningsperioden.