Welke back-upmethode houdt een draaiende databasecontainer consistent op een thuis-NAS?

Voor de meeste gebruikers van home NAS en zelfgehoste servers is de veiligste standaard een database-native logische back-up die wordt gemaakt terwijl de database draait, gevolgd door een normale back-up van die dump samen met de containerconfiguratie en applicatiebestanden. Gebruik een korte gestopte-containerkopie wanneer downtime acceptabel is, en gebruik een gecoördineerde bestandsysteem-snapshot alleen wanneer de database is geleegd, vergrendeld, gecontroleerd of anderszins voorbereid op de snapshot. Een gewone kopie van een live databasevolume is geen consistente back-upmethode.

Definieer “Consistent” als een herstel dat de database accepteert

Een consistente back-up is niet alleen een complete mappenstructuur. Na herstel moet de database-engine starten, transacties correct herstellen, integriteitscontroles doorstaan en een punt-in-tijdstatus presenteren die de applicatie kan gebruiken. Op een home-server met Immich, Nextcloud, Paperless-ngx, Home Assistant of een andere zelfgehoste app betekent dit dat de database, uploads, configuratie en geheimen op elkaar afgestemd moeten zijn.

Containerpersistentie verklaart alleen waar de bestanden zich bevinden. Het maakt een draaiende database niet veilig om te kopiëren. Een database kan actieve transacties, gecachte pagina’s, write-ahead logs, tijdelijke bestanden of metadata hebben die veranderen terwijl NAS-back-upsoftware het volume leest.

Methode 1: Gebruik een database-native logische dump als standaard voor de home NAS

Een logische dump vraagt de database-engine om een consistente weergave van schema’s en records te exporteren. Voor een bescheiden PostgreSQL- of MariaDB-container op een gezins-NAS is dit meestal de eenvoudigste methode om te plannen, te inspecteren, extern te kopiëren en te herstellen in een schone vervangende container. Een actuele Docker-back-upgids toont dit patroon door database-native dumps uit te voeren vanuit een geplande back-upcontainer.

Schrijf de dump naar een speciale back-upmap buiten het live datavolume. Laat vervolgens de NAS-back-uptaak de dump, Compose-bestand, omgevingssjabloon, applicatieconfiguratie en geüploade data beschermen. Maak productiewachtwoorden niet zichtbaar in de dump-bestandsnaam of onbeveiligde logs.

Methode 2: Stop de database kort voordat u het volume kopieert

Een kopie van een gestopte container is eenvoudig en fysiek compleet. Stop eerst de applicatieschrijvers, stop de database netjes, bevestig dat het proces is gestopt, kopieer het volledige persistente volume of de bind-gemounte database-directory en start dan de stack opnieuw. Een Docker- en MariaDB-gids beschrijft fysieke volumekopieën als snel maar versieafhankelijk en normaal gesproken gekoppeld aan downtime.

Deze methode werkt goed voor een kleine thuis-NAS waar een paar minuten onderhoud acceptabel is en het herstel een compatibele databaseversie gebruikt. Het is minder draagbaar dan een logische dump en kan de downtime verlengen wanneer het volume groot is. Bewaar de database-afbeeldingstag en opslagindeling bij de back-up zodat je geen fysieke bestanden herstelt in een incompatibele engineversie.

Methode 3: Coördineer een snelle snapshot met de database

ZFS, Btrfs, LVM en NAS-snapshotsystemen kunnen een groot databasevolume snel vastleggen, maar de snapshot moet worden gecoördineerd met de database. Voor MariaDB of MySQL kan dat een korte lock- of flush-venster betekenen; voor PostgreSQL kan dat het door de database ondersteunde back-up- of checkpointproces betekenen; voor een applicatiebeheerste database kan dat een pre-snapshot hook betekenen.

Een discussie over database-snapshots legt uit dat een live kopie op schijf intern inconsistent kan zijn tenzij de database wordt bevroren of de snapshot atomair wordt genomen. De lock- of quiesce-interval moet kort zijn: bereid de database voor, maak de snapshot, geef schrijfrechten vrij en kopieer de snapshot later.

Deze methode is nuttig wanneer de database te groot is voor frequente logische dumps of wanneer je een korter herstelpuntinterval nodig hebt. Het vereist zorgvuldiger scripten en hersteltesten dan een basis home-server dump workflow.

Behandel Docker-afbeelding of containerexport niet als databaseback-up

De containerafbeelding bevat de applicatieruntime, niet noodzakelijkerwijs de live persistente data. Het exporteren of committeren van de container kan benoemde volumes weglaten en vraagt de database niet om een consistent herstelpunt te creëren. Een PostgreSQL-containerback-upaccount concludeert dat Docker save en commit geen vervanging zijn voor PostgreSQL-specifieke back-uptechnieken.

Voor een ZimaOS- of Docker-home-server, houd de implementatiedefinitie en het gegevensbeschermingsplan gescheiden: bewaar Compose-bestanden en imagetags zodat de service opnieuw kan worden opgebouwd, en bewaar de database via een database-consistente methode zodat de status kan worden hersteld.

Kopieer nooit een actief geschreven databasevolume als gewone kopie

NAS-back-upsoftware kan verschillende databasebestanden op verschillende momenten lezen. Het resulterende archief kan een databestand van één transactiestatus bevatten, een log van een andere en metadata van een derde. Een overzicht van open-source SQL-back-upmethoden waarschuwt dat een database in beweging op een inconsistent moment kan worden vastgelegd terwijl belangrijke status nog in het geheugen is.

Crashherstel kan sommige atomair vastgelegde snapshots repareren, maar een gewone recursieve bestandskopie is niet atomair. Als de app geen downtime kan verdragen, gebruik dan een logische dump, een ondersteund fysiek back-uptools of een gecoördineerde snapshot.

Behandel SQLite-containers als databases, niet als gewone bestanden

Veel home-server apps gebruiken SQLite omdat het compact en gemakkelijk te implementeren is. Het risico is dat beheerders één .db-bestand zien en aannemen dat het gekopieerd kan worden terwijl de app schrijft. In WAL-modus kunnen recente gecommitteerde wijzigingen nog buiten het hoofdbestand staan. Een praktisch SQLite-herstelartikel raadt aan de online back-upmechanisme of een schone gesloten kopie te gebruiken in plaats van een live databasebestand te kopiëren.

Gebruik de ingebouwde back-up van de applicatie als die er is. Gebruik anders de eigen online back-upfunctie van SQLite of stop de applicatie netjes voordat je de hele databasemap kopieert. Kopieer niet alleen het hoofddatabasebestand terwijl het journal of de WAL-status achterblijft.

Kies de methode op basis van downtime, databasegrootte en herstelbaarheid

Back-up de hele zelfgehoste applicatie, niet alleen de database

Een bruikbaar herstelpakket moet de databasebackup, Docker Compose-bestand, imageversies, omgevingsvariabelen of een herstelbaar geheimenpakket, reverse-proxy-instellingen, applicatieconfiguratie, geüploade bestanden en eventuele encryptiesleutels bevatten. Alleen de SQL-dump back-uppen kan records herstellen maar de app onbruikbaar maken voor het vinden van foto’s, documenten, miniaturen, certificaten of opslagpaden.

Voor thuisserver-herstelplanning legt de ZimaSpace-gids over bind mounts en named volumes uit waarom zichtbare opslagpaden helpen bij herstel maar nog steeds geen applicatie-consistente databasebackup vervangen.

Bewijs de methode door te herstellen in een nieuwe container

Maak een geïsoleerde teststack met een nieuwe projectnaam, andere hostpoorten en een tijdelijke datamap. Herstel de dump of snapshot, start de database, voer de integriteits- of consistentiecontroles uit en verbind vervolgens een testkopie van de applicatie. Bevestig dat gebruikers, records, bijlagen en recente transacties aanwezig zijn.

Meet zowel het herstelpunt als de hersteltijd. Als een logische dump consistent is maar te lang duurt om te herstellen, houd deze dan als de draagbare herstellaag en voeg een snellere gecoördineerde snapshot toe. Als een gestopte volume-kopie snel herstelt maar alleen naar dezelfde databaseversie, behoud dan een logische dump als migratiefallback.

FAQ

Is het pauzeren van een databasecontainer voldoende voordat je het volume kopieert?

Niet als algemene regel. Pauzeren bevriest het proces maar bewijst niet dat de database de juiste staat heeft weggeschreven voor een draagbare backup. Gebruik een database-native dump, een schone afsluiting of een gedocumenteerde quiesce-en-snapshot procedure.

Is een NAS-snapshot alleen voldoende voor PostgreSQL of MariaDB?

Alleen wanneer de snapshot atomair is en gecoördineerd met het door de database ondersteunde consistentieproces. Een niet-gecoördineerde snapshot kan slechts crash-consistent zijn, en een niet-atomair bestand kopiëren kan erger zijn.

Wat moet ik back-uppen voor een SQLite-gebaseerde thuisserver-app?

Gebruik de export van de app of SQLite online backup wanneer beschikbaar. Bewaar ook de app-configuratie, Compose-bestand, geheimen, bijlagen en de map die de database bevat in plaats van aan te nemen dat de hoofdmap .db bestand is de hele applicatie.

Eindaanbeveling

Gebruik geplande logische dumps als standaard voor de meeste PostgreSQL- en MariaDB-containers op een thuis-NAS. Gebruik een schone gestopte volume-kopie wanneer korte downtime acceptabel is, en gebruik gecoördineerde snapshots of database-native fysieke tools wanneer de database groot is of het herstelpuntvenster krap is. Welke methode je ook kiest, herstel deze in een nieuwe container voordat je erop vertrouwt.