Wie GitLab bei der Sicherung großer NextCloud-Speicher hilft

Hallo, Habr!

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 beschäftigen, für die Datenspeicherung nutzen wir Nextcloud, einschließlich verteilter Struktur mit Sicherung.

Die Probleme ergeben sich aus den Besonderheiten der Installationen, da es eine große Datenmenge gibt. Die Versionierung, die Nextcloud bietet, sowie die Sicherung, subjektive Gründe und mehr führen zu vielen Duplikaten.

Hintergrund

Bei der Administration von Nextcloud wird das Problem einer effektiven Sicherung besonders wichtig, die unbedingt verschlüsselt werden muss, da die Daten wertvoll sind.

Wir bieten Optionen zur Speicherung von Backups bei uns oder beim Kunden auf separaten Maschinen, die nicht mit Nextcloud verbunden sind, was einen flexiblen, automatisierten Ansatz für das Management erfordert.

Es gibt viele Kunden mit unterschiedlichen Konfigurationen, jeder auf seinen eigenen Plattformen mit seinen eigenen Besonderheiten. Hier passt die Standardmethode, wenn die gesamte Plattform dir gehört und Backups aus dem Cronjob erstellt werden, schlecht.

Lassen Sie uns zunächst die Eingangsdaten anschauen. Wir benötigen:

• Skalierbarkeit, entweder eine oder mehrere Knoten. Für größere Installationen verwenden wir MinIO als Speichersystem.
• Über Probleme beim Backup-Management informiert zu werden.
• Backups müssen bei den Kunden und/oder bei uns gespeichert werden.
• Probleme schnell und einfach beheben können.
• Kunden und Installationen unterscheiden sich stark voneinander – eine Einheitlichkeit ist nicht zu erreichen.
• Die Wiederherstellungsgeschwindigkeit muss in zwei Szenarien minimal sein: vollständige Wiederherstellung (Disaster Recovery), und eine Datei wurde versehentlich gelöscht.
• Die Funktion zur Deduplizierung ist unabdingbar.

Für die Verwaltung der Backups haben wir GitLab integriert. Weitere Informationen dazu im Untertitel.

Zweifellos sind wir nicht die Ersten, die dieses Problem angehen, aber wir glauben, dass unser praktischer, hart erarbeiteter Erfahrungsschatz von Interesse sein kann, und wir sind bereit, ihn zu teilen.

Da in unserem Unternehmen eine Open-Source-Politik gilt, suchten wir eine Lösung mit offenem Quellcode. Im Gegenzug teilen wir unsere Entwicklungen und stellen sie zur Verfügung. Beispielsweise gibt es auf GitHub unser Plugin für Nextcloud., den wir unseren Kunden bereitstellen, um die Datensicherung im Falle von versehentlichem oder absichtlichem Löschen zu verstärken.

Backup-Lösungen

Wir haben mit der Auswahl einer Backup-Lösung begonnen, um Methoden zur Problemlösung zu finden.

Das klassische tar + gzip funktioniert schlecht – die Daten werden dupliziert. Inkrementelle Backups enthalten oft nur sehr wenige tatsächliche Änderungen, und ein großer Teil der Daten innerhalb einer Datei wiederholt sich.
Es gibt ein weiteres Problem – die Redundanz des verteilten Datenspeichers. Wir verwenden MinIO, und dessen Daten sind im Prinzip redundat. Entweder sollten wir Backups direkt über MinIO erstellen – was es belastet und die gesamte Infrastruktur zwischen dem Dateisystem beansprucht, oder was nicht weniger wichtig ist: Es besteht das Risiko, Teile von Buckets und Metainformationen zu vergessen. Alternativ könnte deduplizierte Sicherung zum Einsatz kommen.

Es gibt Open-Source-Backup-Lösungen mit Deduplizierung (es gab Artikel darüber auf Habré einem Artikel ) und unsere Finalisten sindBorg . Unten erläutern wir den Vergleich der beiden Anwendungen, aber zunächst möchten wir erklären, wie wir das gesamte Schema organisert haben. und ResticVerwaltung der Backup-Erstellung

Verwaltung der Erstellung von Sicherungen

Borg und Restic sind gut, aber keines der beiden Produkte verfügt über einen zentralen Verwaltungsmangel. Für das Management und die Kontrolle haben wir ein Tool ausgewählt, das bereits bei uns integriert ist und ohne das wir unsere Arbeit, einschließlich der Automatisierung, nicht denken können – das bekannte CI/CD-Tool GitLab.

Die Idee ist wie folgt: Auf jedem Node, der Nextcloud-Daten speichert, wird ein gitlab-runner installiert. Der Runner führt nach einem Zeitplan ein Skript aus, das den Backup-Prozess überwacht, und dieses Skript startet Borg oder Restic.

Was haben wir erreicht? Feedback zu den Ausführungen, eine einfache Kontrolle der Änderungen und detailierte Informationen im Falle eines Fehlers.

Hier hier auf GitHub wir haben Beispiel-Skripte für verschiedene Aufgaben bereitgestellt, und letztendlich haben wir es nicht nur für das Backup von Nextcloud, sondern auch für viele andere Dienste integriert. Dort befindet sich auch der Scheduler, falls man ihn nicht manuell einstellen möchte (und wir möchten das nicht) sowie die .gitlab-ci.yml.

In der GitLab-API gibt es bisher keine Möglichkeit, das CI/CD-Timeout zu ändern, und das ist ziemlich kurz. Es muss auf zum Beispiel erhöht werden auf 1 Tag.

Zum Glück kann GitLab nicht nur bei einem Commit, sondern auch nach Zeitplan gestartet werden, genau das, was wir brauchen.

Jetzt zum Wrapper-Skript.

Wir haben folgende Anforderungen an dieses Skript gestellt:

• Soll sowohl als Runner als auch manuell über die Konsole mit gleicher Funktionalität laufen.
• Fehlerbehandler sind zwingend erforderlich:
• Rückgabecode.
• Suche nach einer Zeichenfolge im Log. Zum Beispiel könnte für uns eine Fehlermeldung vorliegen, die das Programm als nicht fatal betrachtet.
• Timeout-Verarbeitung. Die Ausführungszeit sollte angemessen sein.
• Wir benötigen ein detailliertes Log. Dies jedoch nur im Fehlerfall.
• Es werden auch eine Reihe von Tests vor dem Start durchgeführt.
• Einige nützliche Funktionen, die wir im Support-Prozess als hilfreich empfunden haben:
• Start und Ende werden im Syslog der lokalen Maschine protokolliert. Dies hilft, systembedingte Fehler und die Backup-Aktivitäten zu verknüpfen.
• Ein Teil des Fehlerlogs, sofern vorhanden, wird in stdout ausgegeben, das gesamte Log wird in einer separaten Datei festgehalten. So kann man direkt im CI schauen und triviale Fehler bewerten.
• Debugging-Modi.

Das vollständige Log wird als Artefakt in GitLab gespeichert; im Falle eines Fehlers wird das Log gelöscht. Das Skript wird in Bash geschrieben.

Wir freuen uns auf Vorschläge und Anmerkungen zur Open-Source-Nutzung – willkommen.

Wie es funktioniert

Auf dem gesicherten Knoten wird ein Runner mit einem Bash-Executor gestartet. Über den Scheduler wird in einem speziellen Repository ein CI/CD-Job gestartet. Der Runner führt ein Skript aus, das als universelle Hülle für solche Aufgaben dient; es werden Validitätsprüfungen des Backup-Repositories, der Einhängepunkte und aller gewünschten Elemente durchgeführt. Anschließend erfolgt die Sicherung und die Bereinigung alter Daten. Das fertige Backup wird auf S3 abgelegt.

Wir arbeiten nach diesem Schema – entweder mit einem externen Anbieter wie AWS oder einem russischen Pendant (das ist schneller und die Daten bleiben in Russland). Alternativ richten wir einen separaten MinIO-Cluster beim Kunden für diese Zwecke ein. Dies geschieht in der Regel aus Sicherheitsgründen, wenn der Kunde absolut nicht möchte, dass die Daten seinen Bereich verlassen.

Wir haben uns entschieden, die Funktion zur Sicherung über SSH nicht zu nutzen. Das erhöht die Sicherheit nicht und die Netzwerkfähigkeiten des S3-Anbieters sind erheblich höher als die einer einzigen SSH-Maschine.

Um sich vor Hackern auf der lokalen Maschine zu schützen – denn sie könnten Daten auf S3 löschen – ist es unbedingt erforderlich, die Versionierung zu aktivieren.
Der Backup-Dienst verschlüsselt das Backup stets.

Borg verfügt über einen Modus ohne Verschlüsselung. keine, aber wir raten dringend davon ab, ihn zu aktivieren. In diesem Modus erfolgt 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 anhand der Indizes überprüft werden kann.

Die Integrität der Backups und deren Inhalte wird von einem separaten Scheduler überprüft. Diese Überprüfung erfolgt langsam und langwierig, weshalb wir sie einmal im Monat separat starten. Sie kann mehrere Tage in Anspruch nehmen.

README auf Russisch

Hauptfunktionen

• prepare Vorbereitung
• testcheck Überprüfung der Bereitschaft
• maincommand Hauptbefehl
• forcepostscript Funktion, die am Ende oder bei einem Fehler ausgeführt wird. Wird verwendet, um die Partition auszuhängen.

Servicefunktionen

• cleanup Schreiben von Fehlern oder Löschen der Protokolldatei.
• checklog Analysiert das Protokoll auf das Auftreten von Fehlerzeilen.
• ret Exit-Handler.
• checktimeout Überprüfung auf Timeout.

Umgebung

• VERBOSE=1 Fehler werden sofort auf dem Bildschirm (stdout) ausgegeben.
• SAVELOGSONSUCCESS=1 Protokoll bei Erfolg speichern.
• INIT_REPO_IF_NOT_EXIST=1 Repository erstellen, falls es nicht existiert. Standardmäßig deaktiviert.
• TIMEOUT Maximale Zeit für die Hauptoperation. Sie können es am Ende als ‘m’, ‘h’ oder ‘d’ festlegen.

Modus zur Aufbewahrung alter Kopien. Standardmäßig:

• KEEP_DAILY=7
• KEEP_WEEKLY=4
• KEEP_MONTHLY=6

Variablen im Skript

• ERROR_STRING — Zeichenfolge für die Protokollprüfung bei Fehlern.
• EXTRACT_ERROR_STRING — Ausdruck zur Anzeige der Zeichenfolge im Fehlerfall.
• KILL_TIMEOUT_SIGNAL — Signal zum Abbrechen bei Zeitüberschreitung.
• TAIL — Anzahl der fehlerhaften Zeichenfolgen auf dem Bildschirm.
• COLORMSG — Farbe der Nachricht (Standard gelb).

Das Skript, das als Wordpress bezeichnet wird, trägt diesen Namen aufgrund seiner Funktionalität; es macht gleichzeitig auch ein Backup der MySQL-Datenbank. Daher kann es für Einmalinstallationen von Nextcloud verwendet werden, wo man auch die Datenbank sichern kann. Der Vorteil liegt nicht nur darin, dass alles an einem Ort ist, sondern auch darin, dass der Inhalt der Datenbank nah am Inhalt der Dateien ist, da der Zeitunterschied minimal ist.

Restic vs Borg

Vergleiche zwischen Borg und Restic sind unter anderem hier auf Habré, und wir hatten nicht die Aufgabe, einfach noch einen weiteren zu erstellen, sondern unseren eigenen. Uns war wichtig, wie es mit unseren Daten und unserer Spezifik er aussehen wird. Wir präsentieren sie.

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

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

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

Borg kann nicht direkt mit S3 arbeiten, daher haben wir es als Fuse-Disk über goofys. Restic hat die Daten selbst zu S3 geschickt.

Goofys arbeitet sehr schnell und gut, und es gibt ein Cache-Modul, das die Leistung weiter beschleunigt. Es befindet sich in der Beta-Phase und, um ehrlich zu sein, hatten wir während der Tests (andere) Datenverluste. Der Vorteil ist jedoch, dass der Backup-Prozess nicht viel Lesevorgang erfordert, sondern hauptsächlich Schreibvorgänge, sodass wir den Cache nur während der Integritätsprüfung verwenden.

Um die Netzwerkwirkung zu verringern, haben wir einen lokalen Anbieter - Yandex Cloud - genutzt.

Ergebnisse der Vergleichstests.

• Kill -9 mit anschließendem Neustart beider verlief erfolgreich.
• Größe auf der Festplatte. Borg kann komprimieren, daher sind die Ergebnisse erwartungsgemäß.

Backuper
Größe

. Unten erläutern wir den Vergleich der beiden Anwendungen, aber zunächst möchten wir erklären, wie wir das gesamte Schema organisert haben.
562 Gb

Restic
628 Gb

• CPU-Verbrauch
  An sich verbraucht Borg wenig mit der Standardkomprimierung, aber die Bewertung sollte im Zusammenhang mit dem Prozess von goofys erfolgen. Insgesamt sind sie vergleichbar und nutzen etwa 1,2 Kerne auf derselben Test-VM.
• Speicher. Restic benötigt etwa 0,5 Gb, Borg etwa 200 Mb. Aber das ist alles unbedeutend im Vergleich zum Dateicache des Systems. Daher sollte man mehr Speicher zuweisen.
• Der Größenunterschied der Blobs war auffällig.

Backuper
Größe

. Unten erläutern wir den Vergleich der beiden Anwendungen, aber zunächst möchten wir erklären, wie wir das gesamte Schema organisert haben.
etwa 500 Mb

Restic
ca. 5 MB

• Die Zusammenarbeit mit S3 von Restic ist hervorragend. Borg funktioniert problemlos über goofys, jedoch ist es ratsam, nach Abschluss des Backups ein umount durchzuführen, um den Cache vollständig zurückzusetzen. Eine Besonderheit von S3 ist, dass unvollständige Chunks niemals in den Bucket gesendet werden, was bedeutet, dass nicht vollständig hochgeladene Daten zu erheblichen Schäden führen können.
• Die Integritätsprüfung funktioniert in beiden Fällen gut, jedoch variiert die Geschwindigkeit erheblich.
  Restic – 3,5 Stunden.
  Borg, mit 100 GB SSD-Datei-Cache – 5 Stunden. Ein etwa gleiches Ergebnis hinsichtlich der Geschwindigkeit ergibt sich, wenn die Daten auf einer lokalen Festplatte liegen.
  Borg liest direkt von S3 ohne Cache 33 Stunden. Furchtbar lange.

Zusammenfassend lässt sich sagen, dass Borg komprimieren kann und größere Blobs hat – was die Speicherung und die GET/PUT-Operationen in S3 kostengünstiger macht. Dafür muss man jedoch für eine kompliziertere und langsamere Überprüfung bezahlen. Was die Wiederherstellungsgeschwindigkeit betrifft, haben wir keinen Unterschied festgestellt. Die nachfolgenden Backups (nach dem ersten) erstellt Restic etwas langsamer, aber nicht erheblich.

Die Größe der Community war nicht unwichtig bei der Auswahl.

Und wir haben Borg gewählt.

Ein paar Worte zur Kompression

Borg bietet einen hervorragenden neuen Komprimierungsalgorithmus – zstd. In Bezug auf die Komprimierungsqualität ist er nicht schlechter als gzip, aber deutlich schneller. Zudem ist er in der Geschwindigkeit mit dem standardmäßigen lz4 vergleichbar.

Zum Beispiel wird ein MySQL-Dump etwa doppelt so gut komprimiert wie lz4 bei gleicher Geschwindigkeit. Die Erfahrung mit realen Daten zeigt jedoch, dass bei Nextcloud-Knoten der Unterschied in der Komprimierungsrate sehr gering ist.

Borg bietet einen zusätzlichen Bonuskomprimierungsmodus – wenn eine Datei eine hohe Entropie hat, wird überhaupt keine Komprimierung angewendet, was die Verarbeitungsgeschwindigkeit erhöht. Dies kann beim Erstellen aktiviert werden.
-C auto,zstd
für den Algorithmus zstd.
Mit dieser Option haben wir im Vergleich zur Standardkomprimierung erhalten:
560 Gb und 562 Gb jeweils. Die Daten aus dem obigen Beispiel, zur Erinnerung: ohne Komprimierung beträgt das Ergebnis 628 Gb. Das Ergebnis von 2 Gb Unterschied hat uns etwas überrascht, aber wir haben beschlossen, dass wir doch auto,zstd.

Überprüfungsmethode des Backups

Die virtuelle Maschine wird über den Scheduler direkt beim Anbieter oder beim Kunden gestartet, was die Netzwerkbelastung erheblich reduziert. Mindestens ist das günstiger, als es intern zu hosten und den Traffic zu leiten.

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 überprüfen wir die Dateien nach dem Hochladen mit einem Antivirusprogramm. Denn die Nutzer laden unterschiedliche Inhalte in Nextcloud hoch, und nicht alle haben einen Antivirus. Eine Überprüfung während des Hochladens würde viel Zeit kosten und den Geschäftsablauf stören.

Die Skalierbarkeit wird erreicht, indem Runner auf verschiedenen Knoten mit unterschiedlichen Tags gestartet werden.
In unserem Monitoring werden die Status der Backups über die GitLab API in einem Dashboard gesammelt. Im Falle von Problemen sind diese leicht zu erkennen und ebenfalls einfach zu lokalisieren.

Fazit

Das Ergebnis ist, dass wir genau wissen, dass wir Backups erstellen, dass unsere Backups valide sind und dass die Probleme, die dabei auftreten, wenig Zeit in Anspruch nehmen und auf Ebene des verantwortlichen Administrators gelöst werden. Backups benötigen im Vergleich zu tar.gz oder Bacula tatsächlich sehr wenig Speicherplatz.

Quelle: habr.com