Jup, habe ebenso keine PRobleme mit externen Blockvolumes.
Würde aber den “old-way” gemäß Anleitung empfehlen, so hat man die “neuen” Pfade gleich mit im compose-File, falls man mal ein Backup wiederherstellen muss.
Etwas Offtopic:
Bin sogar soweit gegangen, dass ich den Mountpoint der Docker-Volums (via old-way) mit in den gitlab-Ordner gelegt habe und den ganzen Ordner auf ein btrfs formatiertes via Loop gemountes Image gelegt habe (da mein Root-FS kein btrfs ist)
Jetzt mach ich stündlich
- btrfs-Snapshots vom gitlab-ordner (der wie gesagt auch die Docker-Volumes enthält und das docker-compose.overwrite.yml und andere Modifikationen enthält)
- bennene das sql-volume um (theoretisch ginge auch löschen)
- mariabackup –backup + mariaback –prepare ins sql-volume –> ReadyToUse DB-Daten aus einer laufenden Instanz
- sqldump (unnötig, aber fühlt sich sicherer an)
- setze ReadOnly
Ich denke zu 99,9% würde auch ein Snapshot ausreichen und der Aufwand mit der Datenbank ist unnötig. Aber es fühlt sich sauberer an, weil die Datenbank ja noch aktiv ist und theoretisch noch was wichtiges im RAM sein könnte, was durch die Backupbfehle noch den Weg auf die Platte und somit ins Backup findet.
Das kostet kaum Ressourcen, dank CoW. Und man kann je nach Wunsch die Snapshots in aller Ruhe weiterverwenden, sind ja Readonly.
Ich synce z.B. den letzten nochmal auf mein privates NAS daheim und 1x täglich tare ich einen und schieb den auch nochmal woanders hin und das Image-File mit dem gesamten btrfs-filesystem wird auch nochmal regelmäßig gesichert :-D
Und im Fehlerfall/neuer Server muss ich mir nur ein Snapshot schnappen, entpacken und hab mein Mailserver wieder im Betrieb.