Backup/Restore Appdata am sinnvollsten einsetzen

  • Guten Morgen,

    ich nutze Backup/Restore Appdata zum Backup meiner Docker Settings.
    Hier kann man einen Zeitplan hinterlegen, vor dem Backup werden die Container gestoppt und danach wieder gestartet.

    Wie ihr wisst, nutze ich gern und viel Docker Container, daher lohnt sich natürlich das Backup - andererseits ist da natürlich einiges los, in den Containern.

    Ich suche nach einer Möglichkeit, das Timing möglichst schlau hinzubekommen damit keiner der Container mitten in seiner Arbeit ausgeschaltet wird.
    Als Beispiele mal: TVH während es eine Aufnahme macht, Emby während es einen Film recodiert um es mobil zu syncen, Handbrake während es eine TV Aufnahme recodiert, easyEPG während es das EPG neu holt, NextCloud während Upload von Videos, Krusader beim kopieren von Dateien, Photoprism beim Face Detection, usw.

    Vieles lässt sich bestimmt durch die Uhrzeit und "mitdenken" erledigen, also Nachts um 3 einfach nicht fernsehen oder Daten kopieren. ;)
    Das allermeiste läuft aber automatisch bzw. eventgesteuert, also mit wenig direktem Einfluss meinerseits.

    Vielleicht noch eine grundsätzliche Frage:
    Backup/Restore Appdata macht ja sozusagen ein Cold Backup, also Docker aus, Backup, Docker an.
    Da in den Appdata Verzeichnissen bei mir keine Daten, sondern nur Configs liegen, wäre es nicht auch ausreichend ein Hot Backup via Duplicati zu machen?

    Danke für Tipps

  • Wenn Du glueck hast, dann sind auf dem container keine prozesse, die dateien schreibbar haben, wenn der container idle ist. Dann kann man sich natuerlich einen script bauen, der alle prozesse des containers pausiert, dann das filesystem read-only remounted, backup macht, wieder rw mounted, und dann die prozesse weiterlaufen laesst.

    Kannst auch probieren, mit LVM snapshots zu spielen. also docker ueber LVM disks laufen lassen, da kannst Du dann nachdem die prozesse angehalten sind, einen LVM snapshot machen, prozesse weiterlaufen lassen, backup from snapshot, und dann snapshot loeschen.

    Wenn es im container immer prozesse mit r/w zugriff auf das dateisystem des containers gibt, dann hilft im prinzip bloss lvm checkpointing, aka kein read-only remount, sondern bloss gucken, das prozess idle sind, anhalten, sync auf das filesystem, snapshot erzeugen, prozesse weiterlaufen lassen, snapshot backup machen,snapshot loeschen.

    alles nur theorie. keine erfahrung, aber das waere was ich ausprobieren wuerde. Allerdings finde ich lvm zu komplex, also eher btrfs oder zfs. Das ist aber auch stress ;)

  • Sorry te36 aber es scheint als hättest du keine Ahnung von Docker. Vielleicht mal Theorie erst anlesen und dann schreiben..

    @Commerzpunk : Es kein Problem einfach mit Duplicati ein Hot Backup vom AppData Order zu machen. Selbst wenn du mehr als nur config Daten da drin hättest. Ich mach z.B. täglich zwei Backups per Shell Script im laufenden Betrieb und kann im Ernstfall per Docker-Compose meine Container schnell wieder herstellen. Fürs Worst Case Szenario, dass das ganze System ausfällt kann ich zudem per Ansible mein System innerhalb von Minuten komplett wiederherstellen (inkl. Docker Backup).

  • Backup/Restore AppData läuft bei mir 1x die Woche so gegen 5:00 Uhr. Zu dieser Zeit schlafe ich in der Regel und es finden daher auch keine User-initiierten Events statt. Alle anderen zeitgesteuerten Events laufen vorher (easyEPG usw. ) und sind um diese Zeit garantiert fertig. Auch Aufnahmen (TVH) werden um diese Uhrzeit i.d.R. nicht gefahren.

    Auf die Frage hin, ob man überhaupt ein Backup braucht: Ja, ich bereits so ca. 3-4x. Mir hat es schon die mariaDB und easyEPG zerschossen und bei OpenHAB war ich froh, bei selbstgebauten Murks auf ein Backup zugreifen zu können.

    AZi (DEV): Nexus auf LibreElec | Asrock J4205 | 4 GB RAM | 128 GB Sandisk| Rii mini
    DEV: PC Ubuntu 20.04 | Matrix
    AZi: Tanix TX3 | Android/CoreElec Dualboot (EMMC), Nexus
    WoZi: Nexus auf LibreElec | Asrock J4205 | 4GB RAM | 128 GB Sandisk SSD | Atric IR | URC7960
    NAS: unRaid, 3x6TB, 2x12TB | TV-Server: Futro S550 mit Hauppauge QuadHD DVB-C
    PayPal: paypal.me/pvdbj1

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!