Wie Sie vielleicht schon den Satz gehört haben:Ein Backup ist nicht gut, wenn es nicht wiederherstellbar ist .
Es gibt verschiedene Möglichkeiten, ein Backup Ihrer wichtigen Dateien auf einem Cloud-Server zu erstellen. Wichtig ist aber auch, dass Sie immer eine aktualisierte Kopie dieser Dateien auf Ihrem lokalen Ordner haben Systeme.
Es ist in Ordnung, sie in der Cloud zu sichern. Aber ein echtes Backup ist nur eine frische und regelmäßig aktualisierte Kopie, die Ihnen jederzeit zur Verfügung steht. Wieso den? Weil es IHRE Daten sind!
Zwei Herausforderungen, die ich in dieser Hinsicht ansprechen werde, sind :
- Die Notwendigkeit, Docker-Container auf einem Produktionsserver zu stoppen, um mögliche Datenbeschädigungen (insbesondere Datenbanken) beim Backup zu vermeiden. Die Dateien auf Live-Produktionscontainern werden kontinuierlich geschrieben.
- Das Anhalten von Docker-Containern führt auch zu Ausfallzeiten, und das können Sie sich nicht leisten, insbesondere wenn Sie in der Produktion sind.
Diese Probleme können durch die Verwendung von Clustern anstelle von einzelnen Servern behoben werden. Aber hier konzentriere ich mich auf einzelne Server und nicht auf Cluster um den Cloud-Service-Aufwand so gering wie möglich zu halten.
Ich fragte mich immer wieder, wie ich mit den beiden oben genannten Herausforderungen umgehen sollte. Dann fiel mir auf, dass wir eine Kombination aus einer Cloud- und einer lokalisierten Lösung verwenden können.
Mit Cloud-basierten Lösungen meine ich die Backup-Dienste von Cloud-Service-Anbietern wie Linode, Digital Ocean und anderen. In dieser exemplarischen Vorgehensweise werde ich Linode verwenden.
Mit lokalisierten Lösungen meine ich die Verwendung von Befehlszeilen- oder GUI-basierten Tools, um das Backup von Cloud-Servern auf Ihr lokales System/Desktop herunterzuladen. Hier habe ich sftp (befehlsbasiert) verwendet.
Zuerst werde ich besprechen, wie man die Sicherung durchführt, gefolgt von der Wiederherstellung.
Das Cloud + Local Based Backup-Verfahren
Sehen wir uns zuerst die Sicherungsprozedur an.
Aktivieren Sie Backups auf dem Linode-Produktionsserver (falls Sie dies noch nicht getan haben)
Wenn Sie einen Produktionsserver auf Linode verwenden, wird dringend empfohlen, dass Sie die Sicherung für ihn aktivieren, wenn er zum ersten Mal bereitgestellt wird. Eine "Nanode", wie sie genannt wird, kommt mit 1 GB RAM und bietet den folgenden Backup-Plan:
Alle anderen Backup-Lösungen bieten eine ähnliche Funktion, jedoch zu höheren Raten. Stellen Sie sicher, dass es aktiviert ist.
Machen Sie einen manuellen Snapshot als Backup in der Cloud
Geben Sie ein Datum zur späteren Bezugnahme ein. Hier nenne ich es "manual-snapshot-11-05-21".
Sobald Sie darauf klicken, werden Sie um eine Bestätigung gebeten:
Wenn Sie bestätigen, finden Sie unten rechts eine Benachrichtigung:
Sie können den Fortschritt auf derselben Seite überwachen, neben der Stelle, wo steht, dass Ihr Server läuft (oben links):
Sobald es fertig ist, sehen Sie das Backup als viertes in der Liste.
Klonen Sie den Produktionsserver
Obwohl Sie einen Server (basierend auf früher geplanten Backups) direkt aus dem Linode-Panel klonen können, empfehle ich Ihnen, manuelle Backups zu verwenden, wie im obigen Schritt beschrieben.
Um also mit der Erstellung eines Klons basierend auf der letzten manuellen Sicherung fortzufahren, die Sie erstellt haben, befolgen Sie unbedingt die folgenden Anweisungen:
Gehen Sie zum Linode-Bedienfeld und klicken Sie auf „Erstellen“:
Wählen Sie "Linode":
Wählen Sie die Registerkarte "Sicherungen":
Beachten Sie, dass der Schnappschuss, den Sie machen, auf einem 2 GB Linode basiert. Wählen Sie den soeben erstellten manuellen Snapshot aus:
Stellen Sie nun sicher, dass Sie die gleiche Spezifikation (2 GB Linode Plan) für Ihren Klon auswählen:
Nachdem Sie den neuen Server basierend auf der Sicherung des Produktionsservers erstellt haben, steht Ihnen ein leicht verfügbarer Klon des Produktionsservers zur Verfügung.
Melden Sie sich per ssh beim Klon an und stoppen Sie alle Container
Sie sollten keine Probleme haben, sich über ssh beim neuen Klon anzumelden, da er dieselben öffentlichen Schlüssel wie der Produktionsserver verwendet. Sie müssen nur die neue IP des Klons verwenden. Ich gehe davon aus, dass Sie nur ssh verwenden und die passwortbasierte Authentifizierung deaktiviert haben, oder? Lesen Sie diesen SSH-Sicherheitsleitfaden, falls Sie ihn noch nicht gelesen haben.
Stoppen Sie nach der Anmeldung alle Container, deren Daten Sie sichern möchten. Normalerweise würden Sie in die entsprechenden App-Verzeichnisse wechseln und den Befehl docker-compose down verwenden. In einer typischen Produktionsumgebung wird immer erwartet, dass Sie Docker Compose anstelle des herkömmlichen docker stop verwenden Befehl, der nur während des Testens bevorzugt werden sollte.
Wenn zum Beispiel Ghost mit seinem entsprechenden Datenbankcontainer läuft, würde ich zuerst die entsprechenden Informationen überprüfen:
[email protected]:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6a3aafe12434 ghost:4.4.0 "docker-entrypoint.s…" 7 days ago Up 7 days 2368/tcp ghost_ghost_2
95c560c0dbc7 jrcs/letsencrypt-nginx-proxy-companion "/bin/bash /app/entr…" 6 weeks ago Up 10 days letsencrypt-proxy-companion
6679bd4596ba jwilder/nginx-proxy "/app/docker-entrypo…" 6 weeks ago Up 10 days 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp jwilder-nginx-proxy
1770dbb5ba32 mariadb:10.5.3 "docker-entrypoint.s…" 3 months ago Up 10 days ghost_db_1
Wie Sie hier sehen können, lauten die Containernamen ghost_ghost_2 und ghost_db_1 jeweils unter einem Reverse-Proxy laufen. Halten wir sie auf.
[email protected]:~$ cd ghost
[email protected]:~/ghost$ docker-compose down
Stopping ghost_ghost_2 ... done
Stopping ghost_db_1 ... done
Network net is external, skipping
[email protected]:~/ghost$
Falls Sie mehr Anwendungen hinter einer Nginx-Reverse-Proxy-Konfiguration ausführen, verwenden Sie dasselbe Verfahren mit den entsprechenden Verzeichnisnamen, die für die Anwendungen festgelegt sind. Halte sie alle einzeln auf.
Volumes und Einstellungen als gzip-Archive sichern
Sehen wir uns nun den manuellen Sicherungsvorgang an.
Benannte Volumes sichern
Wenn Sie mit benannten Docker-Volumes arbeiten, notieren Sie sich, ob die Volumes manuell erstellt wurden oder auf einer generischen Docker Compose-Konfiguration basierten, bei der die App zuerst bereitgestellt wurde.
Eine generische Konfiguration im Volumes-Abschnitt sieht so aus:
volumes:
ghost:
ghostdb:
Das obige Szenario wird von Docker Compose verwaltet, und die tatsächlichen Volume-Namen, die Sie für die Sicherung benötigen, lauten ghost_ghost und ghost_ghostdb .
Falls die Volumes manuell mit docker volume create volume-name erstellt wurden , würde die Konfiguration wie folgt aussehen und ausschließlich ghost sein und ghostdb allein:
volumes:
ghost:
external: true
ghostdb:
external: true
Trotzdem müssen Sie sie in jedem Fall sichern, und Sie müssen auch die Pfade auf den Containern überprüfen, wenn die Volumes gemountet werden. Beispielsweise können bei einer typischen Ghost-Konfiguration mit MariaDB die Pfade bekannt sein, indem man sich die Unterabschnitte der Volumes innerhalb der Service-Definitionen ansieht. Hier ist ein Auszug, um Ihnen zu zeigen, was ich meine:
ghostdb:
volumes:
- ghostdb:/var/lib/mysql
Die obige Konfiguration ist Teil des Datenbankdienstes und seines entsprechenden Containers, der erstellt wird, sobald er bereitgestellt wird.
Ebenso lautet der Pfad für den Ghost-Dienst selbst /var/lib/ghost/content :
ghost:
volumes:
- ghost:/var/lib/ghost/content
Sie müssen diese Pfade kennen, um Ihre Volumes zu sichern.
Verwenden Sie das docker volume ls Befehl, um die Volume-Namen auf dem geklonten Server zu überprüfen.
[email protected]:~/ghost$ docker volume ls
DRIVER VOLUME NAME
local ghost
local ghostdb
local nginx-with-ssl_acme
local nginx-with-ssl_certs
local nginx-with-ssl_dhparam
local nginx-with-ssl_html
local nginx-with-ssl_vhost
So können Sie bestätigen, dass die Volumes tatsächlich ghost sind und ghostdb .
Zeit, sie zu unterstützen! Lassen Sie uns jetzt auf dem Produktionsklon ein Sicherungsverzeichnis in Ihrem Benutzerverzeichnis erstellen:
mkdir ~/backup
Jetzt werde ich den folgenden Befehl verwenden, um den Inhalt der Volumes in einem tar-Archiv zu sichern:
docker run --rm -v ghostdb:/var/lib/mysql -v ~/backup:/backup ubuntu bash -c "cd /var/lib/mysql && tar cvzf /backup/ghostdb.tar.gz ."
Im obigen Befehl mit -v oder --volume , mounte ich das vorhandene Docker-Volume in einen neuen Ubuntu-Container und binde auch das soeben erstellte Backup-Verzeichnis ein. Später gehe ich in das Datenbankverzeichnis innerhalb des Containers und verwende tar, um seinen Inhalt zu archivieren. --rm wird verwendet, um den Container automatisch zu bereinigen und sein Dateisystem zu entfernen, wenn der Container beendet wird (weil Sie es nur so lange wollen, wie der Sicherungs- oder Wiederherstellungsjob abgeschlossen ist).
Beachten Sie den Punkt am Ende des obigen Befehls, bevor das Zitat (") endet. Er stellt sicher, dass das Archiv enthält, was in /var/lib/ghost/content ist allein und ohne den gesamten Pfad selbst als Unterverzeichnisse. Letzteres verursacht Probleme beim Wiederherstellen des Archivs auf einem neuen Volume auf einem neuen Server. Denken Sie also bitte daran.
Jetzt habe ich ein Archiv des MariaDB-Datenbankvolumens, das unser Ghost-Blog verwendet. Ebenso muss ich auch das Ghost-Volume sichern:
docker run --rm -v ghost:/var/lib/ghost/content -v ~/backup:/backup ubuntu bash -c "cd /var/lib/ghost/content && tar cvzf /backup/ghost.tar.gz ."
Denken Sie daran, dass die obigen Sicherungsbefehle auf externen Volumes basieren, die ursprünglich manuell erstellt wurden. Für generische Volumes, die von Docker Compose erstellt und verwaltet werden, würden die tatsächlichen Volume-Namen stattdessen ghost_ghost lauten und ghost_ghostdb bzw. Zum Beispiel für ghost_ghostdb , der ghost Präfix bezieht sich auf den Namen Ihres Anwendungsverzeichnisses, in dem sich Ihre Docker Compose-Konfigurationsdateien und ghostdb befinden bezieht sich auf den Volume-Namen, den Sie in Ihrer Docker Compose-Konfiguration festgelegt haben.
Sicherungseinstellungen mit oder ohne Bind-Mounts
Beachten Sie auch, dass Sie das Ghost-Docker-Compose-Verzeichnis archivieren müssen, unabhängig davon, ob Sie Bind-Mounts oder benannte Volumes verwenden, da Ihre Konfigurationsdateien hier gespeichert sind.
Falls Sie Bind-Mounts und nicht benannte Docker-Volumes verwenden, wird das gesamte Verzeichnis einschließlich der Bind-Mounts archiviert. Hier nenne ich es ghost-docker-compose.tar.gz um Verwirrung zu vermeiden:
[email protected]:~/ghost$ sudo tar cvzf ~/backup/ghost-docker-compose.tar.gz .
Bind-gemountete Volumes benötigen keinen separaten Volume-Abschnitt in einer Docker Compose-Datei. Sie möchten nur Folgendes, wenn es innerhalb des Dienstes definiert wird:
ghost:
volumes:
- ./ghost:/var/lib/ghost/content
In ähnlicher Weise würde das durch Bind bereitgestellte Datenbank-Volume folgendermaßen aussehen:
ghostdb:
volumes:
- ./ghostdb:/var/lib/mysql
"./" gibt das bind-gemountete Verzeichnis innerhalb desselben Geisterverzeichnisses an, in das wir gerade "cd"d haben. Daher erstellen Sie in diesem Fall eine vollständige Sicherung aller Dateien (einschließlich Volumes und Konfigurationsdateien).
Backup-Bind-Mounts wie benannte Volumes sichern
Alternativ können Sie die Bind-Mounts auch einzeln sichern. Dadurch haben Sie die Möglichkeit zu wählen, ob Ihr neuer Server eine Bind-Mounted- oder eine Named-Volume-Konfiguration auf Docker haben soll. Der Grund dafür ist, dass die Archive auf die gleiche Weise wie oben beschriebene benannte Volumes gesichert werden. Dazu müssen Sie nacheinander in die Anwendungs- und Datenbankverzeichnisse (bind mounts) wechseln.
cd ~/ghost/ghost
sudo tar cvzf ~/backup/ghost.tar.gz .
cd ~/ghost/ghostdb
sudo tar cvzf ~/backup/ghostdb.tar.gz .
Sowohl Bind-Mounts als auch benannte Volumes haben ihre eigenen Vor- und Nachteile. Die Frage, welche davon am besten geeignet ist, variiert von Anwendung zu Anwendung. Beispielsweise schlagen Nextcloud-Entwickler benannte Volumes vor, während Rocket.Chat-Entwickler Bind-Mounts vorschlagen.
Fahren Sie fort, es ist an der Zeit, dass Sie diese Archive an Ihrem Ende abrufen.
Laden Sie die Archive mit sftp auf Ihr lokales System herunter
Mit sftp können Sie Ihre Archive sofort in Ihr lokales System herunterladen. Hier verwende ich Port 4480 und IP 12.3.1.4 als Beispiel. Es bezieht sich auf denselben Port, der von ssh verwendet wird.
[email protected]:~$ sftp -oPort=4480 [email protected]
Connected to 12.3.1.4.
sftp> get /home/avimanyu/backup/ghost.tar.gz /home/user/Downloads
Fetching /home/avimanyu/backup/ghost.tar.gz to /home/user/Downloads/ghost.tar.gz
/home/avimanyu/backup/ghost.tar.gz 100% 233MB 6.9MB/s 00:34
sftp> get /home/avimanyu/backup/ghostdb.tar.gz /home/user/Downloads
Fetching /home/avimanyu/backup/ghostdb.tar.gz to /home/user/Downloads/ghostdb.tar.gz
/home/avimanyu/backup/ghostdb.tar.gz 100% 26MB 6.5MB/s 00:03
sftp> get /home/avimanyu/backup/ghost-docker-compose.tar.gz /home/user/Downloads
Fetching /home/avimanyu/backup/ghost-docker-compose.tar.gz to /home/user/Downloads/ghost-docker-compose.tar.gz
/home/avimanyu/backup/ghost-docker-compose.tar.gz 100% 880 6.0KB/s 00:00
sftp> exit
[email protected]:~$
Wie Sie hier sehen können, wird der get Befehl auf sftp ist verdammt viel schneller als rsync oder scp . Einmal der Download abgeschlossen ist, wird Ihnen die sftp-Eingabeaufforderung angezeigt, wo Sie exit eingeben können und verlassen Sie die sftp-Konsole. Die heruntergeladenen Dateien wären unter /home/user/Downloads verfügbar .
An dieser Stelle können Sie sagen, dass Sie eine vollständige Sicherung Ihrer Docker-Anwendung erstellt haben.
Aber wie ich noch einmal sagen muss, es nützt nichts, wenn Sie es nicht wiederherstellen können.
Wiederherstellungsverfahren
Nachdem Sie nun wissen, wie man eine Sicherung durchführt, ist es an der Zeit, sich anzusehen, wie man aus einer Sicherung wiederherstellt.
Erstellen Sie einen neuen Server in der Cloud
Erstellen Sie einen frischen neuen Server aus Ihrem Cloud-Service-Dashboard. Ich habe dies in unserem Backup-Bereich besprochen. Auf Linode sieht es so aus:
Es wird empfohlen, die Serverspezifikationen dieselben wie die des ursprünglichen Servers zu lassen, von dem die Archive gesichert wurden (oben erwähnt).
Backup-Archive auf neuen Server hochladen
Angenommen, Sie können sich jetzt basierend auf Ihren gespeicherten ssh-Einstellungen bei Ihrem Cloud-Dienstanbieter beim neuen Server anmelden, laden Sie die Dateien mit put von sftp auf den Server hoch Befehl:
[email protected]:~$ sftp -oPort=4480 [email protected]
Connected to 12.3.1.5.
sftp> put /home/user/Downloads/ghostdb.tar.gz /home/avimanyu
Uploading /home/user/Downloads/ghostdb.tar.gz to /home/avimanyu/ghostdb.tar.gz
/home/iborg/Downloads/ghostdb.tar.gz 100% 26MB 6.2MB/s 00:04
sftp> put /home/user/Downloads/ghost.tar.gz /home/avimanyu
Uploading /home/user/Downloads/ghost.tar.gz to /home/avimanyu/ghost.tar.gz
/home/iborg/Downloads/ghost.tar.gz 100% 233MB 7.2MB/s 00:32
sftp> put /home/user/Downloads/ghost-docker-compose.tar.gz /home/avimanyu
Uploading /home/user/Downloads/ghost-docker-compose.tar.gz to /home/avimanyu/ghost-docker-compose.tar.gz
/home/iborg/Downloads/ghost-docker-compose.tar.gz 100% 880 22.6KB/s 00:00
sftp> exit
[email protected]:~$
Wenn Sie zum Hochladen lieber eine GUI verwenden, können Sie immer noch FileZilla verwenden.
Einstellungen und Volumes wiederherstellen
Stellen Sie zunächst das Docker-Compose-Verzeichnis Ihrer Ghost-Konfiguration wieder her.
mkdir ghost
cd ghost
sudo tar xvf ~/backup/ghost-docker-compose.tar.gz
Alternativ können Sie auch versuchen, mit --same-owner den Benutzerbesitz wiederherzustellen (Berechtigungen werden bereits beibehalten), was beim Wiederherstellen von bind-gemounteten Verzeichnissen (bereits in den Archiven vorhanden) hilfreich sein kann :
sudo tar --same-owner -xvf ~/backup/ghost-docker-compose.tar.gz
Falls Sie sich für die Verwaltung der neuen Volumes auf Docker Compose verlassen möchten, erstellen Sie diese zuerst. Gemäß unserer Diskussion im obigen Abschnitt „Backup-Volumes“ müssten Sie offensichtlich die notwendigen Namenskonventionen einhalten:
docker volume create ghost_ghost
docker volume create ghost_ghostdb
Wenn Sie sie in Ihrer Docker Compose-Konfiguration als extern festlegen möchten, müssen die Namen unterschiedlich sein (überarbeiten Sie die beiden obigen Befehle):
docker volume create ghost
docker volume create ghostdb
So stellen Sie das MariaDB-Volume für Ghost wieder her:
docker run --rm -v ghostdb:/restore -v ~/backup:/backup ubuntu bash -c "cd /restore && tar xvf /backup/ghostdb.tar.gz"
So stellen Sie das Ghost-Volume selbst wieder her:
docker run --rm -v ghost:/restore -v ~/backup:/backup ubuntu bash -c "cd /restore && tar xvf /backup/ghost.tar.gz"
Stellen Sie sicher, dass die DNS-Einstellungen basierend auf der neuen IP wiederhergestellt werden
Da Sie einen neuen Server verwenden, hat sich die IP definitiv geändert und muss daher für Ihre Domain überarbeitet werden. Sie können diese Voraussetzungen für den Nginx-Reverse-Proxy-Docker als Referenz überprüfen, wo sie besprochen wurden.
Starten Sie neue Container mit den erforderlichen Einstellungen und wiederhergestellten Volumes
Starten Sie nun die Konfiguration auf dem neuen Server neu:
docker-compose up -d
Wenn Sie alle obigen Anweisungen gewissenhaft befolgen, haben Sie jetzt eine vollständig wiederhergestellte Docker-Webanwendung, die auf Ihrer Sicherung basiert.
Zerstöre den Klon
Sobald Sie sicher sind, dass Ihr Ziel erreicht ist, ist es nicht mehr erforderlich, den Klon zu haben, es sei denn, Sie möchten ihn zum Testen behalten. Wenn Sie es also nicht mehr möchten, löschen Sie bitte die Linode (DOPPELT PRÜFEN!):
Abschließende Gedanken
Es gibt bereits viele Lösungen, die partiell und portionsweise auf solche Verfahren zurückgreifen. Aber das erfordert Ausfallzeiten, weil die Container angehalten werden müssen. Diese Herausforderung wird gemeistert, indem Cloud-Sicherungen von Produktionsklonen und nicht von den Produktionsservern selbst verwendet werden.
Anstatt einen 24/7 zusätzlichen Server als Cluster für Backups ohne Ausfallzeiten zu verwenden, verwenden wir derzeit nur einen, um dies zu gewährleisten. Dies ermöglicht bessere FinOps.
Wenn Sie es vorziehen, eine GUI zum Herunterladen oder Hochladen Ihrer Backups zu verwenden, können Sie sftp verwenden über FileZilla.
Da Sie die Dateien auf einem geklonten Server und nicht auf dem Produktionsserver selbst sichern, sparen Sie wertvolle Betriebszeit und vermeiden unerwartete Schluckaufe, die während des Vorgangs auftreten können. Ganz ehrlich, Sie können völlig unbeschwert daran herumtüfteln, weil Sie den Produktionsserver nicht anfassen;)
Ich kann nicht leugnen, dass der gesamte Prozess ziemlich umfassend ist, aber er kümmert sich sicher um unser Ziel. Darüber hinaus könnte dieser Vorgang mit einer sorgfältigen Synchronisation zwischen der Cloud und Ihrem lokalen System in Zukunft auch vollständig automatisiert werden.
Wenn Sie weitere Vorschläge zur Docker-Sicherung und -Wiederherstellung ohne Ausfallzeiten haben, teilen Sie uns bitte Ihre Gedanken im folgenden Abschnitt mit. Jedes andere Feedback oder Kommentare sind sehr willkommen.