Docker Compose stack back-up en upgrade handleiding

Wat een back-up van een Docker Compose-stack moet bevatten

Een back-up van een Docker Compose-stack moet uit vier afzonderlijke onderdelen bestaan. Het verlies van een van deze onderdelen betekent dat de applicatie niet kan worden hersteld: het compose-bestand, de .env ernaast, de inhoud van elk volume en een database-dump die door de eigen client van de database is geschreven. Het kopiëren van databasebestanden terwijl de container actief is, is geen back-up. Upgrades gebruiken dezelfde lijst plus één regel: maak de back-up voordat u een pull uitvoert, omdat schema-migraties zijn geschreven om vooruit te draaien en de meeste projecten geen weg terug bieden.

Alles hieronder gaat ervan uit dat de stack al is uitgerold en dat docker compose ps laat zien dat deze actief is. De voorbeelden gebruiken een projectmap op /srv/myapp met services genaamd app en db. Vervang deze door uw eigen namen. De commando's blijven bewust generiek, omdat de relevante onderdelen, de volumes en de database, op dezelfde manier werken ongeacht de applicatie.

Bepaal wat uw stack daadwerkelijk opslaat

cd /srv/myapp
docker compose ps
docker compose config --volumes
docker volume ls --filter label=com.docker.compose.project=myapp

docker compose config --volumes toont de korte namen van de named volumes die in uw bestand zijn gedeclareerd. docker volume ls toont de namen die deze volumes daadwerkelijk op de schijf hebben. De twee lijsten verschillen, omdat Compose de projectnaam voor de volumenaam plaatst: een volume dat in het bestand als db_data is geschreven, bestaat als myapp_db_data. De projectnaam is standaard de naam van de map; het hernoemen van de map zorgt er dus voor dat de stack naar een nieuwe set lege volumes wijst, terwijl de oude volumes met uw data achterblijven. Elk onderstaand commando vereist de werkelijke naam uit docker volume ls.

Bind mounts verschijnen in geen van beide lijsten. In het compose-bestand zijn dit de vermeldingen met een host-pad links van de dubbele punt, ./config:/app/config. Dit zijn gewone mappen op de host, waardoor ze met standaardtools bereikbaar zijn. Named volumes bevinden zich onder /var/lib/docker/volumes/ en docker volume inspect --format '{{.Mountpoint}}' myapp_db_data toont het exacte pad van een dergelijk volume. Het type dat uw stack gebruikt, bepaalt hoe u deze kopieert, en bind mounts versus named volumes behandelt de afwegingen volledig.

Categoriseer nu wat u heeft gevonden in twee groepen. Sommige volumes bevatten status die niet opnieuw kan worden gegenereerd: geüploade bestanden, gegenereerde sleutels, de database zelf en alles wat een gebruiker in de applicatie heeft ingevoerd. Andere bevatten afgeleide data zoals thumbnails en zoekindexen, die de applicatie zelfstandig kan herbouwen. Het back-uppen van de tweede groep kost schijfruimte en hersteltijd zonder enig voordeel. Een Redis-cachevolume is hier het duidelijkste voorbeeld: het verlies ervan kost slechts één traag eerste verzoek.

Maak een back-up van het compose-bestand en het .env-bestand

Beide bestanden bevinden zich naast elkaar op de host en geen van beide bevindt zich in een volume. Het .env bevat het databasewachtwoord, het applicatiegeheim en alle API-tokens; dit is het bestand dat een verzameling volumes weer verandert in een werkende applicatie. Het staat bovendien meestal in .gitignore, wat betekent dat een plan als "mijn configuratie staat in git" het enige bestand uitsluit dat er echt toe doet. Geheimen in een env-bestand bewaren is het juiste patroon, en dit legt een bijbehorende verantwoordelijkheid bij uw back-up.

sudo install -d -m 700 -o "$USER" -g "$(id -gn)" /srv/backups/myapp
cp -a compose.yaml .env /srv/backups/myapp/
chmod 600 /srv/backups/myapp/.env

Kopieer elk compose-bestand dat de stack gebruikt, niet alleen het eerste. Een stack die is gestart met -f compose.yaml -f compose.prod.yaml heeft beide bestanden nodig om op dezelfde manier terug te keren, en hoe meerdere compose-bestanden samensmelten bepaalt welke waarden daadwerkelijk de container bereiken.

Eén waarschuwing koppelt het .env aan de volumes. De officiële Postgres-image leest POSTGRES_PASSWORD alleen wanneer deze een lege datamap initialiseert. Het later wijzigen van die waarde verandert het wachtwoord in de database niet. Herstel het volume van vorige maand naast het .env van vandaag en de applicatie kan geen verbinding maken met FATAL: password authentication failed for user "appuser", terwijl beide bestanden er bij inspectie correct uitzien. Bewaar het .env en de volumes van hetzelfde moment samen in dezelfde back-up.

De database dumpen met de eigen client

Een databaseserver schrijft constant naar zijn bestanden. Een tar van /var/lib/postgresql/data die wordt gemaakt terwijl de server draait, kopieert sommige pagina's van vóór een schrijfactie en andere van erna. Het archief bevat daardoor een mix van momenten die mogelijk niet consistent is. Een dump-tool leest de data binnen één transactie, waardoor het bestand één consistent moment representeert. Dat verschil is wat een backup onderscheidt van een kopie.

docker compose exec -T db sh -c \
  'pg_dump -U "$POSTGRES_USER" -d "$POSTGRES_DB" -Fc' \
  > /srv/backups/myapp/db-$(date +%F).dump

Behoud de -T. Deze schakelt TTY-allocatie uit. Met een gekoppelde TTY vertaalt Docker de output-stream naar uw shell, wat een binaire dump corrumpeert. U merkt dit pas op wanneer het herstel mislukt. De enkele aanhalingstekens zijn ook van belang: ze voorkomen dat uw host-shell $POSTGRES_USER uitbreidt, zodat de shell in de container dit doet met de waarden die al in het compose-bestand zijn ingesteld. -Fc schrijft het aangepaste formaat, dat tijdens het schrijven comprimeert en waarmee pg_restore later objecten kan selecteren.

Rollen en hun wachtwoorden bevinden zich buiten een individuele database, dus neem deze ook mee:

docker compose exec -T db sh -c 'pg_dumpall -U "$POSTGRES_USER" --globals-only' \
  > /srv/backups/myapp/globals.sql

Controleer vervolgens of het bestand een dump is en geen foutmelding:

ls -lh /srv/backups/myapp/
head -c 5 /srv/backups/myapp/db-$(date +%F).dump

Een dump in aangepast formaat begint met de vijf bytes PGDMP. Een bestand van nul bytes, of een bestand dat begint met pg_dump:, betekent dat het commando is mislukt. De shell maakt het output-bestand aan voordat het commando wordt uitgevoerd, waardoor een mislukte dump een bestand achterlaat met een plausibele naam en tijdstempel. Dit is de meest voorkomende stille backup-fout die er is.

Voor MariaDB of MySQL verandert de client, maar de werkwijze niet:

docker compose exec -T db sh -c \
  'mariadb-dump -u root -p"$MARIADB_ROOT_PASSWORD" --single-transaction --databases "$MARIADB_DATABASE"' \
  > /srv/backups/myapp/db-$(date +%F).sql

--single-transaction geeft een consistente dump van InnoDB-tabellen zonder schrijfacties te blokkeren. In de MySQL-image is het commando mysqldump en zijn de variabelen MYSQL_ROOT_PASSWORD en MYSQL_DATABASE. In huidige MariaDB-images werkt mysqldump nog steeds als compatibiliteitsnaam voor mariadb-dump. Let op: een wachtwoord dat op de commandoregel wordt meegegeven, is zichtbaar in de proceslijst van de container zolang de dump draait.

SQLite vereist specifieke aandacht. De database is één bestand, maar recente transacties kunnen nog in een apart -wal-bestand ernaast staan. Het kopiëren van alleen het .db-bestand resulteert in een database die de nieuwste schrijfacties mist. Als de image de client bevat, schrijft sqlite3 /data/app.db ".backup '/data/app-backup.db'" een consistente kopie terwijl de applicatie draait. Als dit niet het geval is, stop dan de container en kopieer het .db-bestand samen met zijn -wal- en -shm-metgezellen.

Als uw database op de host draait in plaats van in de stack, zijn dezelfde commando's van toepassing zonder het docker compose exec-voorvoegsel, en het draaien van de database in Docker of op de host is het lezen waard vóór uw volgende rebuild.

Volumes vastleggen

Een named volume heeft geen host-pad dat u handmatig moet bewerken; koppel het daarom aan een tijdelijke container en archiveer het vanaf daar.

docker run --rm \
  -v myapp_uploads:/data:ro \
  -v /srv/backups/myapp:/backup \
  alpine:3 tar czf /backup/uploads.tar.gz -C /data .

De helper-container koppelt het volume als read-only op /data en uw backup-directory op /backup, waarna het archief naar de host wordt geschreven. --rm verwijdert de helper zodra tar is afgesloten. De :ro is van belang, omdat een typefout in het tar-commando de bron dan niet kan beschadigen. -C /data . zorgt ervoor dat de restore op de juiste plek terechtkomt: het slaat elk pad relatief op ten opzichte van de volume-root. Gebruik in plaats daarvan tar czf /backup/uploads.tar.gz /data en elk pad krijgt een voorloop-data/, waardoor de restore een /data/data aanmaakt in het volume en de applicatie een lege directory ziet. Het archief is eigendom van root, omdat tar als root in de container draaide. Voer sudo chown "$USER" /srv/backups/myapp/uploads.tar.gz uit als dat in de weg zit, en lees hoe PUID en PGID bestandseigenaarschap bepalen als de herstelde bestanden onleesbaar zijn voor de applicatie.

Voer dit eenmaal per named volume uit. Voor bind mounts is geen container nodig: tar czf /srv/backups/myapp/config.tar.gz -C /srv/myapp/config . voert dezelfde taak uit op de host.

Bepaal per volume of de applicatie moet stoppen. Een live tar van een volume dat de applicatie tijdens het schrijven wijzigt, kan een bestand halverwege een schrijfactie vastleggen. Voor een uploads-directory, waar bestanden eenmalig worden geschreven en daarna alleen worden gelezen, is dat risico klein. Stop voor alle andere gevallen de service gedurende de kopieeractie met docker compose stop app, en daarna docker compose start app. stop laat de containers en de volumes intact, wat hier precies de bedoeling is, en het is de moeite waard om het verschil tussen down en stop te kennen voordat u een van beide typt.

Beschouw een tar van het database-volume niet als uw database-backup. De dump is de backup. Een volume-archief van een gestopte database is enkel een nuttige methode voor een snelle herbouw.

De volgorde van bewerkingen

1. Kopieer de compose-bestanden en de .env naar de back-upmap.
2. Maak een dump van de database terwijl deze nog actief is.
3. Stop de app-container als de volumes ter plaatse worden gewijzigd.
4. Archiveer elk benoemd volume en elke bind-mount-map.
5. Start alles wat u heeft gestopt en bevestig dit vervolgens met docker compose ps.
6. Noteer de image-tags en digests die de stack op dat moment gebruikt.
7. Kopieer de volledige back-upmap vanaf deze server naar een externe locatie.

Stap 7 is de stap die mensen vaak uitstellen.

Kopieer de data van de server

Een back-up op dezelfde schijf als de stack beschermt u enkel tegen uw eigen fouten. Eén defect volume, één verwijderde server of één verloren account zorgt ervoor dat beide kopieën tegelijkertijd verdwijnen. Verplaats de directory naar opslag die zich niet op deze VPS bevindt, volgens een schema en met een retentiebeleid. restic backups vanaf een VPS behandelt het instellen van de repository, de retentie-flags en het check-commando, dus dat hoeft hier niet herhaald te worden.

restic kan de dump ook direct via een pipe inlezen, waardoor de database in platte tekst helemaal niet op de schijf terechtkomt:

docker compose exec -T db sh -c 'pg_dump -U "$POSTGRES_USER" -d "$POSTGRES_DB" -Fc' \
  | restic backup --stdin --stdin-filename db.dump

Welke tool u ook gebruikt, plaats het schema in een systemd timer of een cron job en zorg dat de taak foutmeldingen rapporteert op een plek waar u ze ziet. Een back-upscript waarvan de output nergens heen gaat, is een back-upscript dat zes maanden lang kan stoppen met werken zonder dat iemand het merkt.

Controleer de back-up met een restore-oefening

Een back-up die nooit is teruggezet, is slechts een hypothese. De onderstaande oefening voert een restore uit naar een tweede stack die naast de eerste draait. Hierdoor blijft de productieomgeving operationeel en kan uw invoer deze niet beïnvloeden.

Het mechanisme hiervoor is de projectnaam. Compose haalt deze uit de mapnaam en koppelt deze aan elke container en elk volume dat wordt aangemaakt. Kopieer de back-up naar een nieuwe map en de herstelde stack krijgt automatisch zijn eigen volumes.

sudo install -d -m 700 -o "$USER" -g "$(id -gn)" /srv/myapp-restore
cd /srv/myapp-restore
cp /srv/backups/myapp/compose.yaml /srv/backups/myapp/.env .

Pas het gekopieerde compose-bestand aan zodat de gepubliceerde hostpoort niet botst met de actieve stack; gebruik 18080:8080 in plaats van 8080:8080, of wijzig de variabele die deze instelt in het gekopieerde .env. Maak vervolgens de containers en hun lege volumes aan zonder iets te starten:

docker compose create
docker volume ls --filter label=com.docker.compose.project=myapp-restore

Het tweede commando hoort dezelfde volumenamen als in productie weer te geven, met myapp-restore_ ervoor. Vul deze, start de database afzonderlijk en laad de dump:

docker run --rm -v myapp-restore_uploads:/data -v /srv/backups/myapp:/backup \
  alpine:3 tar xzf /backup/uploads.tar.gz -C /data
docker compose up -d db
docker compose exec -T db sh -c \
  'pg_restore -U "$POSTGRES_USER" -d "$POSTGRES_DB" --clean --if-exists' \
  < /srv/backups/myapp/db-2026-08-16.dump

--clean --if-exists verwijdert elk object voordat het opnieuw wordt aangemaakt, wat de restore herhaalbaar maakt. Zonder deze optie stopt een tweede run in een database die al tabellen bevat met pg_restore: error: could not execute query: ERROR: relation "users" already exists.

Start daarna de rest en controleer de werking zoals een gebruiker dat zou doen:

docker compose up -d --wait
docker compose exec -T db sh -c 'psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -c "\dt"'
docker compose logs --tail=50

docker compose up -d --wait blokkeert totdat elke service rapporteert dat deze draait of gezond is. Het commando sluit af met een foutcode als dit niet lukt, wat deze stap geschikt maakt voor scripts. Wanneer een service nooit de status 'healthy' bereikt, toont docker compose ps de status ervan, en Compose healthchecks legt uit wat die kolom precies weergeeft. Open vervolgens de applicatie op de alternatieve poort en log in met een echt account. Schrijf één record en open één bestand dat in een volume staat. Dat paar is het bewijs: de dump is hersteld, het volume is hersteld en beide komen met elkaar overeen. Een oefening die alleen bewijst dat de inlogpagina laadt, zegt niets over de integriteit van uw data.

Ruim de oefenomgeving op zodra deze is geslaagd:

docker compose down -v

Dit is de enige situatie waarin -v de juiste vlag is. In de productiemap verwijdert hetzelfde commando de volumes die u juist wilt beschermen.

Een Compose-stack upgraden

Lees de release notes voor elke versie tussen de versie die u draait en de versie die u wilt installeren. Zoek hierin naar de termen breaking en migration. Projecten die het overslaan van meerdere hoofdversies niet ondersteunen, vermelden dit daar. Een migratie die weigert uit te voeren, geeft dit vaak pas aan nadat een deel van het schema al is gewijzigd.

Leg vast wat u momenteel draait voordat u wijzigingen aanbrengt:

docker compose images
docker image inspect --format '{{index .RepoDigests 0}}' postgres:16.4

docker compose images toont de image en tag die elke service op dit moment gebruikt. De digest is de enige waarde die een image exact identificeert, omdat een tag op elk moment naar een andere locatie kan wijzen.

Maak een back-up volgens de voorgaande secties en kopieer deze van de server af. Doe dit ook voor een patch-release. De goedkope upgrades zijn de upgrades waarvoor men stopt met de voorbereidingen.

Zet vervolgens de versie vast in het compose-bestand, aangezien latest geen versie is:

services:
  db:
    image: postgres:16.4

Met image: postgres:latest haalt docker compose pull op waar die tag vandaag naar wijst, en u heeft geen mogelijkheid om te benoemen wat u gisteren draaide. Een vastgezette tag verandert een upgrade in een wijziging van één regel die u kunt inzien in git diff en met één extra wijziging ongedaan kunt maken. Zet de applicatie-image op dezelfde manier vast door de exacte versie van de releasepagina van het project te gebruiken.

Pull en recreate:

docker compose pull
docker compose up -d --wait

docker compose up -d vergelijkt het bestand met de draaiende containers en recreëert alleen de services waarvan de image of configuratie is gewijzigd. Het raakt named volumes niet aan, waardoor de nieuwe container op de bestaande data start. Dat is het doel van deze oefening, maar ook het risico, omdat de eerste start van de nieuwe versie meestal het moment is waarop de schema-migratie wordt uitgevoerd.

Monitor het proces:

docker compose ps
docker compose logs -f --tail=100 app

Een container die faalt toont Exited (1) in de kolom STATUS van docker compose ps; de reden hiervoor staat in de laatste regels van het logbestand. Migratiefouten zijn daar duidelijk zichtbaar, maar elders onzichtbaar. Zodra de logs stabiel zijn, logt u in en gebruikt u de applicatie gedurende een minuut.

Als docker compose pull stopt met no space left on device, zijn oude image-layers meestal de oorzaak. Via ongebruikte Docker-images opschonen krijgt u de ruimte terug. Voer het opschonen pas uit nadat de upgrade zich heeft bewezen, niet daarvoor, omdat die oude layers nodig zijn voor een snelle rollback.

Hoe u een rollback uitvoert wanneer een upgrade mislukt

Er zijn twee scenario's met aanzienlijk verschillende gevolgen. Als de nieuwe versie het schema niet heeft gewijzigd, is een rollback slechts één regel werk: zet de oude tag terug in het compose-bestand en voer docker compose up -d uit. De container wordt vervangen, de volumes blijven behouden en de oude code leest de data die deze zelf heeft geschreven.

Als de nieuwe versie het schema heeft gemigreerd, kan de oude code dit niet meer lezen. Migraties zijn geschreven om voorwaarts uit te voeren en de meeste projecten leveren geen downgrade-script mee. De oude versie start daarom wel, maar faalt bij de eerste query op een kolom die is hernoemd of verwijderd, met foutmeldingen in de vorm van ERROR: column "avatar_url" does not exist. De enige weg terug is de dump die u maakte voordat u de nieuwe versie ophaalde: zet de oude tag terug, verwijder het databasevolume, maak een leeg volume aan, zet de dump terug en start de service. Zonder die dump is er geen weg terug; dit is precies de reden waarom een backup altijd voorafgaat aan een pull.

Grote versiewijzigingen van Postgres zijn hierbij het meest kritiek. Ze verrassen gebruikers vaak omdat de fout niet bij de rollback optreedt, maar bij de upgrade zelf. Het on-disk formaat verandert bij elke grote release. Wijzig postgres:16.4 naar postgres:17.2, voer docker compose up -d uit en de nieuwe server weigert te starten:

FATAL:  database files are incompatible with server
DETAIL:  The data directory was initialized by PostgreSQL version 16, which is not compatible with this version 17.2.

De image voert niet automatisch pg_upgrade voor u uit. De ondersteunde methode binnen een Compose-stack is: dumpen, vervangen, herstellen. Maak een dump terwijl de oude versie nog draait, voer docker compose down uit, verwijder het databasevolume, stel de nieuwe tag in, voer docker compose create uit voor een nieuwe lege datamap, start de database, zet de dump terug en start de overige services. Bewaar de oude dump totdat de nieuwe grote versie gedurende een dag daadwerkelijk netwerkverkeer heeft verwerkt. Kleine upgrades binnen dezelfde grote versie, zoals van 16.4 naar 16.9, vereisen dit proces niet, omdat het formaat stabiel blijft en de container direct start.

Zijn VPS-snapshots een back-up?

Ze vormen een aanvulling op een back-up, aangezien beide op verschillende manieren kunnen falen. Een snapshot kopieert de volledige schijf op hypervisor-niveau, waardoor de gehele machine binnen enkele minuten wordt hersteld, inclusief de onderdelen die u was vergeten te back-uppen. Dit maakt het de juiste tool voor één specifieke taak: de server is defect na een upgrade en u wilt de status van twintig minuten geleden herstellen.

Voor alle andere doeleinden is het een ongeschikte tool. De granulariteit is de volledige machine; het herstellen van één verwijderde tabel betekent dat u een volledige server ergens anders moet terugzetten om de tabel er vervolgens uit te vissen. De bewaartermijn is meestal kort. De kopieën bevinden zich doorgaans in hetzelfde account van de provider als de server, waardoor bij verlies van het account zowel de server als de snapshots verloren gaan. Bovendien legt een snapshot van een draaiende machine de database vast tijdens een schrijfactie, waardoor de database bij de eerste start een crash-recovery moet uitvoeren en alle lopende transacties verloren gaan.

Gebruik beide. De snapshot is de 'ongedaan maken'-knop voor een onderhoudsvenster. De dump is de kopie die een verwijderd account overleeft. hoe snapshots en back-ups verschillen behandelt welke defecten door elk type worden gedekt. Diezelfde back-upmap is ook wat het verplaatsen van een stack naar een nieuwe VPS verandert in een routinematige taak in plaats van een herbouw uit het geheugen.

Wat er misgaat en wat u zult zien

De volumes-vlag bij down. docker compose down -v verwijdert de benoemde volumes die in het bestand zijn gedeclareerd, en Compose bevestigt dit met een regel die Volume myapp_db_data Removed luidt. Dit kan niet ongedaan worden gemaakt. Een standaard docker compose down laat ze ongemoeid. Gebruik de lange vorm, docker compose down --volumes, zodat de destructieve vlag een woord is dat u expliciet moet uitschrijven.

Een dump zonder magic string. pg_restore: error: did not find magic string in file header betekent dat het bestand geen archief is. De gebruikelijke oorzaak is een ontbrekende -T bij docker compose exec, omdat de stream bij een gekoppelde TTY wordt vertaald op weg naar uw shell en de binaire dump beschadigd aankomt. Maak de dump opnieuw met -T en controleer vervolgens de eerste vijf bytes met head -c 5.

Een wachtwoord dat niet wijzigt. FATAL: password authentication failed for user "appuser" na een restore betekent dat het .env en de datadirectory van verschillende momenten afkomstig zijn. De image stelt dat wachtwoord alleen in wanneer deze een lege datadirectory aanmaakt, dus het later bewerken van .env verandert niets in de database. Herstel het bijbehorende .env, of wijzig het wachtwoord in de database met ALTER USER.

Een tweede, leeg volume. Docker maakt op verzoek een volume aan, dus docker run -v myapp_upload:/data met een ontbrekende s schrijft naar een gloednieuw leeg volume en meldt succes. docker volume ls toont vervolgens beide namen, waarvan er één niets bevat. Kopieer volumenamen uit docker volume ls in plaats van ze uit het hoofd te typen.

Een restore gericht op productie. Het uitvoeren van de restore-commando's in /srv/myapp in plaats van /srv/myapp-restore overschrijft live data met de backup, en de commando's zien er op beide plekken identiek uit. Controleer pwd vóór elk restore-commando en bewaar de oefenomgeving in een eigen directory.

FAQ

Verwijdert docker compose down mijn data?

Nee. docker compose down verwijdert de containers en het standaardnetwerk, maar laat named volumes en bind mounts ongemoeid. docker compose down -v verwijdert de named volumes die in uw bestand zijn gedeclareerd; dit is permanent. Bind mounts zijn mappen op de host, dus Compose verwijdert deze nooit. Gebruik docker compose stop als u de services wilt stoppen voor een back-up, terwijl de rest ongewijzigd blijft.

Kan ik de Postgres-datamap kopiëren in plaats van pg_dump te draaien?

Alleen als de container is gestopt. Terwijl de server draait, veranderen de bestanden continu en kan de kopie een inconsistent mengsel van momentopnames bevatten die niet opnieuw afspeelbaar zijn. Een kopie op bestandsniveau is bovendien gebonden aan één specifieke major-versie van Postgres; deze zal niet starten onder een andere versie. Stop de container, archiveer het volume, start de container opnieuw en beschouw het resultaat als een methode voor snel herstel in plaats van als uw enige back-up. De dump is de draagbare kopie en het bestand waarvan u herstelt.

Hoe upgrade ik Postgres naar een nieuwe major-versie in Compose?

Het wijzigen van de tag is onvoldoende. De nieuwe server weigert te starten op de oude datamap en logt The data directory was initialized by PostgreSQL version 16, which is not compatible with this version 17.2. Draai pg_dump terwijl de oude versie nog draait, voer daarna docker compose down uit, verwijder het databasevolume, stel de nieuwe tag in, draai docker compose create voor een leeg volume, start de database en herstel de dump daarin. Bewaar de oude dump totdat de nieuwe versie daadwerkelijk verkeer heeft verwerkt.

Hoe vaak moet ik back-ups maken en hoe lang moet ik ze bewaren?

Stem het interval af op de hoeveelheid werk die u bereid bent opnieuw te doen. Een dagelijkse back-up is geschikt voor een stack van een persoon of een klein team, aangevuld met één extra handmatige back-up vlak voor elke upgrade. Bewaar voor de retentie voldoende historie om schade te herstellen die u niet direct opmerkt, aangezien een beschadigde tabel die op vrijdag wordt ontdekt, niet kan worden hersteld met de kopie van donderdagnacht. restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune is een redelijk startbeleid. Ongeacht het schema: voer elk kwartaal een test-restore uit. Totdat u dat heeft gedaan, heeft u geen back-ups, maar slechts bestanden.

Moet ik de hele stack stoppen om een back-up te maken?

Meestal niet. De database-dump is consistent terwijl de server draait, dus de database behoeft geen downtime. De volumes zijn de eigenlijke vraag. Als de applicatie alleen bestanden toevoegt, zoals een uploadmap, is een live-archief veilig genoeg. Als de applicatie bestanden ter plekke overschrijft, stop dan die specifieke service gedurende de kopieeractie met docker compose stop app en start deze daarna weer. Het stoppen van de applicatie terwijl de database blijft draaien, is doorgaans het kortst mogelijke veilige venster dat u kunt realiseren.