Docker volume back-ups met snapshots?

[Lethalis]

Mijn vraag
In het kort: hoe maken jullie consistente back-ups van Docker volumes?

Stel je hebt containers met volumes die wat meer data bevatten, te denken valt hierbij bijvoorbeeld aan Graylog met Elasticsearch, of bijvoorbeeld applicaties die sqlite gebruiken en dat soort dingen.

Een manier om eenvoudig een consistente back-up van de data te maken, is om de containers te stoppen, en vervolgens met een tijdelijke busybox container een tar.gz archief van de named volumes te maken. En op het einde de containers weer te starten.

Als je dan de data hebt, en het docker-compose.yml bestand, kun je de boel weer eenvoudig ergens anders herstellen when the shit hits the fan.

Het probleem: naarmate de hoeveelheid data toeneemt, neemt ook de downtime toe. Momenteel ligt mijn monitoring stack er bijvoorbeeld bijna een kwartier uit om een back-up te maken.

De oplossing hiervoor - in het algemeen - is om een bestandssysteem te gebruiken dat snapshots ondersteunt, bijvoorbeeld BTRFS (ZFS etc kan ook).

Met bind mounts is dat eenvoudig te realiseren:
- Bewaar alle data op de host in een BTRFS subvolume
- Stop de containers
- Maak de snapshot
- Start de containers
- Maak tar.gz archief van de snapshot
- Verwijder de snapshot weer

Downtime is dan maar ongeveer 15 seconden

Maar... hoe doe je hetzelfde met Docker managed named volumes? Want vaak lees je dat ze juist eenvoudiger te backuppen zijn enzovoorts, maar zodra ik er op ga zoeken i.v.m. snapshots vind ik niet zoveel.

Relevante software en hardware die ik gebruik
Linux en Docker

En natuurlijk allerlei containers waar ik consistente back-ups van wil maken zonder al te veel downtime.

Wat ik al gevonden of geprobeerd heb
Verschillende dingen en strategieën.

De dooddoener is vaak: als het mogelijk is om een back-up op applicatie niveau te maken, dan is dat beter dan een file level back-up.

Nadeel daarvan vind ik alleen dat wanneer je veel verschillende soorten applicaties hebt, back-ups maken ervan een vrij complexe aangelegenheid wordt. En het herstellen dus ook.

Ik ben vooral benieuwd naar hoe jullie dit oplossen. Ik kan het immers met bind mounts fixen, maar ik vind het jammer dat ik nog geen goede manier heb gevonden om hetzelfde met named volumes te doen.

Named volumes hebben immers ook zo hun voordelen ten opzichte van bind mounts, qua gemak.

Alvast bedankt.

[qwasd]

Ik gebruik zelf Duplicati om backups te maken van mijn docker data.

[Lethalis]

qwasd schreef op dinsdag 24 augustus 2021 @ 05:00:
Ik gebruik zelf Duplicati om backups te maken van mijn docker data.

Maar wat voor voorzieningen zitten daar in om de consistentie van de back-up te waarborgen?

Duplicati is voor de rest wel mooi om back-ups naar de cloud te maken (hoewel ik met versie 1.x issues met restoren heb gehad... zal in versie 2.x wel gefixt zijn hoop ik). Maar het gaat mij vooral om hoe je met brongegevens omgaat.

Als ik tutorials bekijk van mensen die hun Docker data back-uppen met Duplicati, dan zie ik vooral dat ze bind mounts gebruiken en dan gewoon hun /docker map als bron opgeven in Duplicati. Ik zie ze vervolgens alleen niks doen dat ervoor zorgt dat hun containers tijdelijk stoppen en hun data wegschrijven naar de bestandssysteem, ik zie niets over snapshots, enzovoorts.

Het is dan gewoon een kopie van de bestanden zoals ze op dat moment zijn, consistent of niet. En dat vind ik persoonlijk niet genoeg.

Stel je hebt bijvoorbeeld een gitea container draaien met sqlite. Als je dan bijvoorbeeld een back-up maakt van de /docker/gitea map - terwijl gitea draait - dan zijn nog niet alle gegevens weggeschreven in de sqlite database (gitea.db) en is de back-up dus niet consistent.

Pas op het moment dat je gitea stopt, dan worden alle gegevens weggeschreven en kun je daar betrouwbaar een file back-up van maken. Op Windows zou het bestand zelfs gelockt zijn als gitea nog draait en dan kan je helemaal geen kopie van de sqlite database maken.

Vandaar mijn oplossing met de snapshot (eerst service stoppen, snapshot maken van de consistente data, service weer starten, daarna kan er rustig een back-up gemaakt worden van de snapshot terwijl de service draait en geeft het dus niet hoelang het duurt, en op het eind gooien we de snapshot weer weg).

Op Windows worden dit soort dingen doorgaans opgelost door de volume shadow copy service, met applicatie specifieke VSS writers. Software zoals Macrium gebruikt dat. Dan maak je gewoon een back-up van een hele machine en op het moment dat Windows de opdracht krijgt om een snapshot te maken, roept Windows alle VSS writers aan - waaronder die voor bijvoorbeeld SQL Server - en dan schrijft SQL Server eerst netjes zijn wijzigingen naar de schijf, zodat Macrium daarna een consistente back-up kan maken.

Kanttekening hierbij: er is geen VSS writer voor gitea of sqlite dat ik weet

Maar goed, ik probeer op Linux qua back-ups ergens op hetzelfde niveau te komen als op Windows. Met Docker als soort van extra complicatie.

[qwasd]

Ik snap het. Ik heb echter gewoon een paar docker containers waar de services niet van gestopt hoeven te worden. Ik backup gewoon platte data en als ik deze data weer terugzet op een nieuwe vm met docker dan heb ik alles weer terug in de originele staat. Wat jij wilt bereiken heb ik dus ook geen oplossing voor. Succes

[kamerplant]

Dus je wilt Docker iedere keer eerst laten stoppen zodat er geen data ontbreekt. Maar dan heb je downtime, en mis je daarmee toch ook data?

[Lethalis]

kamerplant schreef op woensdag 25 augustus 2021 @ 07:18:
Dus je wilt Docker iedere keer eerst laten stoppen zodat er geen data ontbreekt. Maar dan heb je downtime, en mis je daarmee toch ook data?

Door een snapshot te maken is de downtime zeer beperkt, omdat de services alleen uit staan tijdens het maken van de snapshot. Het enige andere alternatief is application level back-ups te maken in plaats van file level back-ups. Dat betekent echter ook dat je per applicatie een losse back-up procedure krijgt.

In het voorbeeld van gitea betekent dat een sqldump maken van de database en los de git repositories archiveren. Bij elastic search betekent het een "snapshot" van de indexes maken. Bij X betekent het Y. Als je dan veel verschillende dingen draait op een host, heb je ook 20+ verschillende back-up scripts

En dat maakt het beheren ervan en vooral ook snel herstellen van al die verschillende applicaties op het moment dat het nodig is, ook behoorlijk complex. Terwijl je in de file level back-up situatie simpelweg alle data terugzet en met docker-compose weer ff de verschillende stacks opstart en klaar.

[Pin0]

Ik zou de images ook backuppen. Ik heb vaak genoeg een oude applicatie zien falen omdat een dependency geïnstalleerd bij het builden van zo'n image (via een dockerfile) niet meer bestaat. (zegt natuurlijk wat over hoe die image is samengesteld maar toch)

[LEDfan]

Ik snap dat je niet voor elke soort applicatie een andere backup procedure wilt, maar ik denk dat je er dan niet aan ontkomt om je huidige methode toe te passen. Zonder de service down te brengen kan je er niet van uitgaan dat de state op het filesystem consistent is (voor elke mogelijke applicatie die er bestaat). Als je én geen downtime wilt én consistente backups wilt, kan je denk ik niet anders dan rekening houden met de karakteristieken van de applicatie.

In het kort: hoe maken jullie consistente back-ups van Docker volumes?

Enkele voorbeelden:

• Nextcloud draait met MySQL: ik neem een backup van de data directory (zie later) en een backup van de database via
  code:
  

  mysqldump --single-transaction nextcloud > nextcloud.sql

  Dit zorgt ervoor dat de DB in een consistente staat wordt gedumpt (dus de staat zoals aan het begin van de transactie) . In principe moet je Nextcloud in "maintenance" mode zetten, zodat gebruikers even niets kunnen doen en de database altijd consistent is met het filesystem. Ik doe dit niet, maar ik weet dan wel dat ik Nextcloud naar files moet laten scannen op het moment dat ik een restore doe.
• Matrix met postgersql: ik laat Matrix gewoon draaien en voer
  code:
  

  docker exec synapse_db_1 pg_dump -U synapse synapse > synapse.sql

  uit. Opnieuw zal PSQL er voor zorgen dat de dump consistent is (https://dba.stackexchange...roduce-consistent-backups). Hier draait Synapse in een docker container en is de data folder bind-mounted op het systeem. Daar neem ik terug gewoon een filesystem backup van.
• [i]Jenkins: heeft geen database, dus hier neem ik enkel een fileystem backup van. Zover ik weet is het filesystem van Jenkins altijd consistent. Wat wel kan is dat er veranderingen gebeuren tijdens het backupen, die loop je dan mogelijk mis.[/i]

Naast de databases, backup ik dus ook de filsystems. Hierbij maakt het voor mij niet uit of het in Docker draait of niet. Ik zorg er gewoon voor dat ik het pad ken (bij named volumes staat het volume ook ergens op je filesystem en kan je het pad dus achterhalen). Hiervoor gebruik ik een combinatie van rsync en borg. Op mijn backup host, rsync ik eerst alle directories van de server(s) naar de backup host. Aangezien rsync enkel de gewijzigde bestanden overneemt gaat dit vrij snel. Daarna laat ik borg een backup maken van die directory (op de backup server dus). Door Borg kan je dus zorgen voor een encrypted, authenticated en deduplicated backup. Het deduplicatie algoritme van Borg is echt heel goed en bespaart ontzettend veel ruimte.

code:

 Nadeel daarvan vind ik alleen dat wanneer je veel verschillende soorten applicaties hebt, back-ups maken ervan een vrij complexe aangelegenheid wordt. En het herstellen dus ook.

Zelf applicaties hosten is niet zo eenvoudig. Daarom dat dit ook een aparte job is binnen de IT Maar er verschijnen steeds meer tools om dit eenvoudiger te maken natuurlijk.
Ik denk dat je huidige aanpak zeker niet slecht is.

[Thralas]

LEDfan schreef op woensdag 25 augustus 2021 @ 10:58:
Zonder de service down te brengen kan je er niet van uitgaan dat de state op het filesystem consistent is (voor elke mogelijke applicatie die er bestaat).

Maar met snapshots heb je juist die garantie. Ook bij databases (de voorbeelden die je gebruikt) is dat voldoende.

quote: https://www.postgresql.org/docs/current/backup-file.html

An alternative file-system backup approach is to make a “consistent snapshot” of the data directory, if the file system supports that functionality (and you are willing to trust that it is implemented correctly). The typical procedure is to make a “frozen snapshot” of the volume containing the database, then copy the whole data directory (not just parts, see above) from the snapshot to a backup device, then release the frozen snapshot. This will work even while the database server is running.

@Lethalis Je draagt de oplossing zelf al aan: btrfs of ZFS, zodat je consistente snapshots hebt - dan zou ik me over de rest niet al te veel zorgen meer maken. Wel belangrijk: de docker image driver van beide zou ik dan weer niet gebruiken, last time I checked waren die enorm inefficient en/of brak.

En ZFS is niet eens bruikbaar icm. overlay2: linux: renameat2 flags support - oplossing: /var/docker op een ext4/xfs zvol

Ik ben vooral benieuwd naar hoe jullie dit oplossen. Ik kan het immers met bind mounts fixen, maar ik vind het jammer dat ik nog geen goede manier heb gevonden om hetzelfde met named volumes te doen.

Named volumes hebben immers ook zo hun voordelen ten opzichte van bind mounts, qua gemak.

Welk voordeel is dat? Het maakt toch niet zoveel uit of je een named volume of directory opgeeft in je compose file? Enige wat je zult moeten doen is een btrfs subvolume of zfs dataset aanmaken voor iedere container, maar dat is met 1 commando geregeld toch? Als je het echt heel vervelend vindt kun je iets als docker-zfs-plugin gebruiken.

[ Voor 8% gewijzigd door Thralas op 27-08-2021 18:13 ]

[Lethalis]

@LEDfan @Thralas Bedankt voor jullie reacties. Voor beide methoden is iets te zeggen dus (application level back-ups versus file level back-ups).

Waarbij het eigenlijk niet zoveel uitmaakt of een applicatie in Docker draait of niet. Het enige aspect daarbij is eigenlijk of je named volumes gebruikt of bind mounts. @Thralas stelt dan ook terecht de vraag wat het voordeel van named volumes gebruiken is.

Het enige voordeel daarvan is gebruiksgemak bij het deployen van een container in een nieuwe omgeving. Bij een bind mount is het immers heel belangrijk dat de bestandsrechten van de map op het hostsysteem goed ingesteld zijn, anders kan de containerized applicatie er misschien niet in schrijven. Bijvoorbeeld als deze standaard met een user id van 1000 ofzoiets draait.

Ook daar kun je dan allerlei dingen mee doen. Of simpelweg het ownership van die map goedzetten op die user, of juist het proces onder een user laten draaien waar je zelf de voorkeur aan geeft.

Bij named volumes boeit dit allemaal wat minder en gaat het eigenlijk altijd goed.

Dus als je meerdere applicaties hebt die met verschillende rechten draaien, dan moet je wel alle mappen met de juiste rechten herstellen op een andere host in een noodsituatie. Gelukkig kun je met tar de rechten bewaren en zal het ook op dezelfde manier weer ergens anders terug gezet worden. Dus een heel groot probleem is dit niet.

Application level back-ups hebben dan weer het voordeel dat het niet echt uitmaakt waar de data staat, zolang de back-up maar goed gemaakt wordt. Een ander voordeel is dat ze iets minder afhankelijk van de versie kunnen zijn. Bij een file level back-up is het vaak belangrijk dat je ook weer dezelfde versie van de applicatie gebruikt op een andere machine.

Dus... het heeft allemaal zijn voor- en nadelen. En ik moet nog even goed bedenken waar ik nou voor ga kiezen.