Wie GitLab dabei hilft, große Backups von NextCloud-Speichern zu erstellen

Hallo, Habra!

Heute möchte ich über unsere Erfahrungen mit der Automatisierung der Datensicherung großer Nextcloud-Speicher in verschiedenen Konfigurationen berichten. Ich bin CTO bei „Molniya AK“, wo wir uns mit dem Konfigurationsmanagement von IT-Systemen befassen, und für die Datenspeicherung verwenden wir Nextcloud. Dazu gehört auch die verteilte Struktur mit einer Sicherung.

Die Probleme, die aus den Besonderheiten der Installationen resultieren, liegen darin, dass es viele Daten gibt. Die Versionierung, die Nextcloud bietet, die Sicherung, subjektive Gründe und anderes führen zu vielen Duplikaten.

Vorgeschichte

Beim Administrieren von Nextcloud tritt das Problem auf, eine effektive Sicherung zu organisieren, die unbedingt verschlüsselt werden muss, da die Daten wertvoll sind.

Wir bieten Optionen zur Speicherung der Sicherung bei uns oder beim Kunden auf dessen separaten Maschinen von Nextcloud an, was einen flexiblen automatisierten Ansatz zur Verwaltung erfordert.

Es gibt viele Kunden, alle mit unterschiedlichen Konfigurationen, und alle an ihren eigenen Standorten mit ihren eigenen Besonderheiten. Die Standardmethode, wenn die gesamte Anlage einem gehört und die Sicherungen über Cronjobs erstellt werden, passt hier schlecht.

Lassen Sie uns zunächst die Eingabedaten betrachten. Wir benötigen:

• Skalierbarkeit in Bezug auf eine Node oder mehrere. Für große Installationen verwenden wir MinIO als Speicher.
• Probleme beim Backup ausfindig machen.
• Die Sicherung muss bei den Kunden und/oder bei uns gespeichert werden.
• Probleme schnell und einfach lösen.
• Die Kunden und Installationen unterscheiden sich stark voneinander — es ist nicht möglich, Einheitlichkeit zu erreichen.
• Die Wiederherstellungsgeschwindigkeit muss in zwei Szenarien minimal sein: vollständige Wiederherstellung (Desaster), ein Ordner — versehentlich gelöscht.
• Eine Funktion zur Deduplizierung ist zwingend erforderlich.

Für die Verwaltung der Backups haben wir GitLab integriert. Mehr dazu im Blog.

Natürlich sind wir nicht die Ersten, die eine solche Aufgabe lösen, aber wir glauben, dass unsere praktischen Erfahrungen von Interesse sein könnten, und wir sind bereit, sie zu teilen.

Da in unserem Unternehmen eine Open-Source-Politik verfolgt wird, haben wir nach einer Lösung mit offenem Quellcode gesucht. Im Gegenzug teilen wir unsere Entwicklungen und stellen sie bereit. Zum Beispiel gibt es auf GitHub unser Plugin für Nextcloud, das wir unseren Kunden bereitstellen und das die Datensicherheit im Falle einer versehentlichen oder vorsätzlichen Löschung erhöht.

Backup-Tools

Wir begannen die Suche nach Lösungsmethoden mit der Auswahl eines Tools zur Erstellung von Backups.

Das normale tar + gzip funktioniert schlecht – die Daten werden dupliziert. In der Tat enthält das Inkrement oft sehr wenig Änderungen, und der größte Teil der Daten innerhalb einer Datei wiederholt sich.
Es gibt noch ein weiteres Problem – die Redundanz des verteilten Datenspeichers. Wir verwenden minio, und seine Daten sind grundsätzlich redundant. Entweder hätte das Backup über minio selbst gemacht werden müssen – es zu belasten und alle Schichten zwischen dem Dateisystem zu nutzen, und was nicht weniger wichtig ist, es besteht das Risiko, Teile der Buckets und Metainformationen zu vergessen. Oder man müsste Deduplication verwenden.

Backup-Lösungen mit Deduplication gibt es im Open Source (auf Habré gab es des Artikels zu diesem Thema) und unsere Finalisten wurden Borg und Restic. Über unseren Vergleich der beiden Anwendungen unten, und vorher erzählen wir, wie wir das gesamte System organisiert haben.

Management der Backup-Erstellung

Borg und Restic sind gut, aber kein Produkt hat einen zentralisierten Management-Mechanismus. Für das Management und die Kontrolle haben wir ein Tool gewählt, das bereits eingeführt ist, ohne das wir unsere Arbeit, einschließlich Automatisierung, nicht denken können – das bekannte CI/CD – GitLab.

Die Idee ist die folgende: Auf jeder Node, die Daten von Nextcloud speichert, wird ein gitlab-runner installiert. Der Runner startet gemäß dem Zeitplan ein Skript, das den Backup-Prozess überwacht und Borg oder Restic ausführt.

Was haben wir erreicht? Feedback von der Ausführung, bequeme Kontrolle über die Änderungen, Details im Fehlerfall.

Hier hier auf GitHub haben wir Skriptbeispiele für verschiedene Aufgaben veröffentlicht, und wir haben es letztendlich nicht nur für das Nextcloud-Backup, sondern auch für viele andere Dienste integriert. Dort gibt es auch einen Scheduler, falls man ihn nicht manuell konfigurieren möchte (was wir nicht wollen) und die .gitlab-ci.yml

Im GitLab-API gibt es bisher keine Möglichkeit, das CI/CD-Timeout zu ändern, und es ist sehr kurz. Es muss erhöht werden, sagen wir auf 1d.

Glücklicherweise kann GitLab nicht nur nach dem Commit, sondern auch nach Zeitplan starten, das ist genau, was wir brauchen.

Jetzt zum Wrapper-Skript.

Wir haben solche Bedingungen für dieses Skript festgelegt:

• Es muss sowohl von einem Runner als auch manuell über die Konsole mit denselben Funktionen ausgeführt werden.
• Es müssen unbedingt Fehlerbehandler vorhanden sein:
• Return-Code.
• Suche nach einer Zeile im Protokoll. Zum Beispiel kann für uns eine Fehlermeldung eine Meldung sein, die das Programm nicht als fatal ansieht.
• Timeout-Verarbeitung. Die Ausführungszeit muss angemessen sein.
• Wir benötigen ein detailliertes Protokoll. Aber nur im Fehlerfall.
• Außerdem werden eine Reihe von Tests vor Beginn durchgeführt.
• Einige nützliche Extras, die wir während des Supports als hilfreich erachtet haben:
• Der Start und das Ende werden im Syslog des lokalen Rechners festgehalten. Das hilft, systembedingte Fehler mit der Backup-Arbeit zu verknüpfen.
• Ein Teil des Fehlerprotokolls, wenn vorhanden, wird in stdout ausgegeben, das gesamte Protokoll wird in eine separate Datei geschrieben. Es ist praktisch, sofort im CI einen Blick darauf zu werfen und einen trivialen Fehler zu erkennen, falls vorhanden.
• Debugging-Modi.

Das vollständige Protokoll wird als Artefakt in GitLab gespeichert; wenn kein Fehler aufgetreten ist, wird das Protokoll gelöscht. Das Skript wird in Bash geschrieben.

Wir freuen uns über Vorschläge und Anmerkungen zum Open Source — willkommen.

Die DANE-Spezifikation ist in

Auf dem zu sichernden Knoten wird ein Runner mit einem Bash-Executor gestartet. Gemäß dem Scheduler wird in einem speziellen Repository ein CI/CD-Job gestartet. Der Runner führt ein universelles Wrapper-Skript für solche Aufgaben aus, in dem Validitätsprüfungen des Backup-Repositories, der Mount-Punkte und alles, was wir wollen, durchgeführt werden, danach erfolgt das Backup und die Bereinigung der alten Daten. Das fertige Backup wird an S3 gesendet.

Wir arbeiten nach diesem Schema — es ist ein externer Anbieter wie AWS oder ein russisches Pendant (das ist schneller und die Daten verlassen nicht die RF). Alternativ installieren wir dem Kunden einen separaten Minio-Cluster auf seinem Gelände für diese Zwecke. Normalerweise geschieht dies aus Sicherheitsgründen, wenn der Kunde absolut nicht möchte, dass die Daten ihren Bereich verlassen.

Wir haben die Funktion zum Senden von Backups per SSH nicht genutzt. Das trägt nicht zur Sicherheit bei, und die Netzwerkbandbreite des S3-Anbieters ist erheblich höher als die einer unserer SSH-Maschinen.

Um sich vor Hackern auf dem lokalen Rechner zu schützen — denn sie könnten Daten auf S3 löschen — ist es unbedingt notwendig, die Versionierung zu aktivieren.
Der Backuper verschlüsselt immer das Backup.

Borg hat einen Modus ohne Verschlüsselung none, aber wir empfehlen dringend, ihn nicht zu aktivieren. In diesem Modus gibt es nicht nur keine Verschlüsselung, sondern es wird auch keine Prüfziffer für die geschriebenen Daten berechnet, was bedeutet, dass die Integrität nur indirekt, über die Indizes, überprüft werden kann.

Mit einem separaten Scheduler wird die Integrität der Backups anhand der Indizes und Inhalte geprüft. Die Überprüfung erfolgt langsam und lange, daher starten wir sie einmal im Monat separat. Sie kann mehrere Tage dauern.

Lesen Sie auf Russisch

Hauptfunktionen

• vorbereiten Vorbereitung
• testcheck Bereitschaftsprüfung
• Hauptbefehl Basisbefehl
• Zwangs-Postscriptum Die Funktion, die am Ende oder bei einem Fehler ausgeführt wird. Wird verwendet, um die Partition zu demontieren.

Dienstfunktionen

• Bereinigung Wir protokollieren Fehler oder löschen die Protokolldatei.
• Protokollprüfung Wir analysieren das Protokoll auf das Vorkommen einer Fehlerzeile.
• ret Exit-Handler.
• Timeout überprüfen Überprüfung auf Zeitüberschreitungen.

Umgebung

• VERBOSE=1 Fehler werden sofort auf dem Bildschirm (stdout) ausgegeben.
• SAVELOGSONSUCCESS=1 Protokoll wird im Erfolgsfall gespeichert.
• INIT_REPO_IF_NOT_EXIST=1 Wir erstellen ein Repository, falls es nicht vorhanden ist. Standardmäßig deaktiviert.
• ZEITÜBERSCHREITUNG Maximale Zeit für die Hauptoperation. Sie können am Ende 'm', 'h' oder 'd' setzen.

Modus zur Aufbewahrung alter Kopien. Standardmäßig:

• HALTE_TÄGLICH=7
• HALTE_WÖCHENTLICH=4
• HALTE_MONATLICH=6

Variablen innerhalb des Skripts

• FEHLERSTRING — Zeichenfolge zur Überprüfung im Protokoll auf Fehler.
• EXTRAHIEREN_FEHLERSTRING — Ausdruck zur Anzeige der Zeichenfolge im Fehlerfall.
• KILL_TIMEOUT_SIGNAL — Signal zum Abbrechen im Falle einer Zeitüberschreitung.
• TAIL — wie viele Fehlerzeilen auf dem Bildschirm angezeigt werden.
• FARBMELDUNG — Farbe der Meldung (standardmäßig gelb).

Das Skript, das "wordpress" genannt wird, hat den Vorteil, dass es auch die MySQL-Datenbank sichert. Das bedeutet, es kann für einmalige Installationen von Nextcloud verwendet werden, bei denen auch die Datenbank gesichert wird. Der Vorteil liegt nicht nur darin, dass alles an einem Ort ist, sondern dass der Inhalt der Datenbank dem Inhalt der Dateien sehr ähnlich ist, da die Zeitdifferenz minimal ist.

Restic vs Borg

Vergleiche zwischen Borg und Restic sind unter anderem hier auf Habré, und wir hatten nicht die Aufgabe, einfach nur einen weiteren Vergleich zu machen, sondern unseren eigenen. Es war uns wichtig, wie es mit unseren Daten und unserer Spezifikationen aussehen würde. Wir stellen sie dar.

Unsere Auswahlkriterien, neben den bereits erwähnten (Deduplizierung, schnelle Wiederherstellung usw.):

• Widerstandsfähigkeit gegen unvollständige Arbeiten. Überprüfung auf kill -9.
• Speicherplatz auf der Festplatte.
• Ressourcenerfordernisse (CPU, Arbeitsspeicher).
• Größe der gespeicherten Blobs.
• Arbeiten mit S3.
• Integritätsprüfung.

Für die Tests haben wir einen Kunden mit realen Daten und einer Gesamtspeichergröße von 1,6 TB genommen.
Bedingungen.

Borg kann nicht direkt mit S3 arbeiten, und wir haben es als FUSE-Laufwerk über goofys. Restic hat direkt an S3 gesendet.

Goofys arbeitet sehr schnell und gut, und es gibt einen Festplattencache-Modul, das die Arbeit weiter beschleunigt. Es befindet sich im Beta-Stadium, und um ehrlich zu sein, ist es uns bei Tests (anderen) mit Datenverlust abgestürzt. Der Vorteil besteht jedoch darin, dass der Sicherungsprozess nicht viel Lesevorgang erfordert, hauptsächlich wird geschrieben, deshalb nutzen wir den Cache nur während der Integritätsprüfung.

Um den Einfluss des Netzwerks zu reduzieren, haben wir einen lokalen Anbieter - Yandex Cloud - verwendet.

Ergebnisse der Testvergleiche.

• Kill -9 mit anschließendem Neustart, beide sind erfolgreich durchgelaufen.
• Größe auf der Disk. Borg kann komprimieren, daher sind die Ergebnisse zu erwarten.

Backuper
Größe

Borg
562Gb

Restic
628Gb

• Zu CPU
  Borg selbst verbraucht wenig, mit der Standardkompression, aber man sollte das zusammen mit dem Prozess von goofys bewerten. Zusammen vergleichen sie sich und benötigen etwa 1,2 Kerne auf der gleichen Test-VM.
• Speicher. Restic benötigt ungefähr 0,5Gb, Borg etwa 200Mb. Aber das ist alles unbedeutend im Vergleich zum Dateispeicher-Cache des Systems. Daher sollte man mehr Speicher zuweisen.
• Der Unterschied in der Größe der Blobs war erstaunlich.

Backuper
Größe

Borg
ungefähr 500Mb

Restic
ungefähr 5Mb

• Die Arbeit mit S3 von Restic ist ausgezeichnet. Die Arbeit von Borg über goofys wirft keine Fragen auf, es wurde jedoch festgestellt, dass es ratsam ist, nach Abschluss des Backups ein umount durchzuführen, um den Cache vollständig zurückzusetzen. Eine Besonderheit der Arbeit mit S3 ist, dass unvollständig heruntergeladene Chunks niemals in den Bucket gesendet werden, was bedeutet, dass nicht vollständig hochgeladene Daten zu großen Schäden führen.
• Die Integritätsprüfung funktioniert in beiden Fällen gut, aber die Geschwindigkeit unterscheidet sich erheblich.
  Restic – 3,5 Stunden.
  Borg, mit einem Dateispeicher-Cache von 100Gb SSD – 5 Stunden. Ungefähr gleiches Ergebnis hinsichtlich der Geschwindigkeit, wenn die Daten auf der lokalen Festplatte liegen.
  Borg liest direkt von S3 ohne Cache 33 Stunden. Furchtbar lange.

Im Endeffekt kann Borg komprimieren und hat größere Blobs - das macht die Speicherung und GET/PUT-Operationen in S3 günstiger. Dafür muss man jedoch für eine kompliziertere und langsamere Überprüfung zahlen. Was die Wiederherstellungsgeschwindigkeit betrifft - da haben wir keinen Unterschied bemerkt. Die nachfolgenden Backups (nach dem ersten) macht Restic etwas länger, aber nicht signifikant.

Nicht zuletzt war die Größe der Community bei der Auswahl wichtig.

Und wir haben Borg gewählt.

Ein paar Worte zur Kompression

Borg hat einen großartigen neuen Kompressionsalgorithmus in seinem Arsenal – zstd. In Bezug auf die Kompressionsqualität nicht schlechter als gzip, aber deutlich schneller. Und in Bezug auf die Geschwindigkeit mit der Standardversion lz4 vergleichbar.

Zum Beispiel komprimiert ein MySQL-Dump ungefähr doppelt so gut wie lz4 bei gleicher Geschwindigkeit. Allerdings zeigt die Erfahrung mit echten Daten, dass der Grad der Kompression bei Nextcloud-Knoten sehr gering ist.

In Borg gibt es einen ziemlich bonufartigen Kompressionsmodus – wenn die Datei eine hohe Entropie hat, dann wird die Kompression überhaupt nicht angewendet, was die Geschwindigkeit erhöht. Aktiviert wird das mit einer Option bei der Erstellung
-C auto,zstd
für den zstd-Algorithmus
Mit dieser Option haben wir im Vergleich zur Standardkompression Folgendes erhalten
560Gb und 562Gb entsprechend. Die Daten aus dem obigen Beispiel, erinnere ich daran, ohne Komprimierung sind das 628Gb. Das Ergebnis mit 2Gb Unterschied war etwas überraschend für uns, aber wir entschieden uns dennoch dafür. auto,zstd.

Methode zur Überprüfung des Backups

Die virtuelle Maschine wird laut Zeitplan direkt beim Anbieter oder beim Kunden gestartet, was die Netzwerkbelastung erheblich reduziert. Mindestens ist es günstiger, als es selbst hochzufahren und den Traffic zu steuern.

goofys --cache "--free:5%:\/mnt\/cache" -o allow_other --endpoint https:\/\/storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com \/mnt\/goofys
export BORG_PASSCOMMAND="cat \/home\/borg\/.borg-passphrase"
borg list \/mnt\/goofys\/borg1\/
borg check --debug -p --verify-data \/mnt\/goofys\/borg1\/

Nach demselben Schema prüfen wir die Dateien mit Antivirus (nachträglich). Denn die Nutzer laden unterschiedliche Inhalte in Nextcloud hoch und nicht alle haben einen Antivirus. Eine Prüfung zum Zeitpunkt des Uploads dauert zu lange und beeinträchtigt das Geschäft.

Die Skalierbarkeit wird durch das Starten von Runnern auf verschiedenen Knoten mit unterschiedlichen Tags erreicht.
In unserem Monitoring werden die Status von Backups über die GitLab API in einem Fenster gesammelt, bei Bedarf werden Probleme leicht erkannt und ebenso leicht lokalisiert.

Fazit

Letztendlich wissen wir genau, dass wir Backups durchführen, dass unsere Backups gültig sind, und dass die Probleme, die dabei auftreten, wenig Zeit in Anspruch nehmen und auf Ebene des diensthabenden Administrators gelöst werden. Backups nehmen im Vergleich zu tar.gz oder Bacula wirklich wenig Platz ein.

Quelle: habr.com