Wie GitLab Ihnen beim Sichern großer NextCloud-Speicher hilft

Hey Habr!

Heute möchte ich über unsere Erfahrungen bei der Automatisierung der Sicherung großer Datenmengen aus Nextcloud-Speichern in verschiedenen Konfigurationen sprechen. Ich arbeite als Servicestation bei Molniya AK, wo wir das Konfigurationsmanagement von IT-Systemen durchführen; Nextcloud wird für die Datenspeicherung verwendet. Einschließlich mit verteilter Struktur und Redundanz.

Die Probleme, die sich aus den Eigenschaften der Installationen ergeben, bestehen darin, dass viele Daten vorhanden sind. Die von Nextcloud bereitgestellte Versionierung, Redundanz, subjektive Gründe und mehr führen zu vielen Duplikaten.

Vorgeschichte

Bei der Verwaltung von Nextcloud stellt sich das Problem, ein effektives Backup zu organisieren, das verschlüsselt werden muss, da die Daten wertvoll sind.

Wir bieten Optionen zur Speicherung von Backups bei uns oder beim Kunden auf separaten Maschinen von Nextcloud an, was einen flexiblen automatisierten Verwaltungsansatz erfordert.

Es gibt viele Clients, alle mit unterschiedlichen Konfigurationen, alle auf ihren eigenen Websites und mit ihren eigenen Eigenschaften. Dies ist eine Standardtechnik, wenn die gesamte Website Ihnen gehört und Backups aus Kronen erstellt werden; sie passt nicht gut.

Schauen wir uns zunächst die Eingabedaten an. Wir brauchen:

• Skalierbarkeit in Bezug auf einen oder mehrere Knoten. Bei großen Installationen nutzen wir minio als Speicher.
• Informieren Sie sich über Probleme bei der Durchführung von Backups.
• Sie müssen ein Backup bei Ihren Kunden und/oder bei uns aufbewahren.
• Lösen Sie Probleme schnell und einfach.
• Clients und Installationen unterscheiden sich stark voneinander – eine Einheitlichkeit kann nicht erreicht werden.
• Die Wiederherstellungsgeschwindigkeit sollte in zwei Szenarien minimal sein: vollständige Wiederherstellung (Katastrophe), ein Ordner wurde versehentlich gelöscht.
• Deduplizierungsfunktion ist erforderlich.

Um das Problem der Backup-Verwaltung zu lösen, haben wir GitLab installiert. Weitere Details nach Tackle.

Natürlich sind wir nicht die Ersten, die ein solches Problem lösen, aber es scheint uns, dass unsere praktischen, hart erarbeiteten Erfahrungen interessant sein können und wir sind bereit, sie zu teilen.

Da unser Unternehmen eine Open-Source-Politik verfolgt, waren wir auf der Suche nach einer Open-Source-Lösung. Im Gegenzug teilen wir unsere Entwicklungen und veröffentlichen sie. Auf GitHub gibt es zum Beispiel unser Plugin für Nextcloud, die wir unseren Kunden zur Verfügung stellen und die Datensicherheit im Falle einer versehentlichen oder vorsätzlichen Löschung erhöhen.

Backup-Tools

Wir begannen unsere Suche nach Lösungsmethoden mit der Auswahl eines Backup-Erstellungstools.

Normales tar + gzip funktioniert nicht gut – die Daten werden dupliziert. Ein Inkrement enthält oft nur sehr wenige tatsächliche Änderungen und viele der Daten in einer einzelnen Datei werden wiederholt.
Es gibt noch ein weiteres Problem – die Redundanz der verteilten Datenspeicherung. Wir verwenden Minio und seine Daten sind grundsätzlich redundant. Oder Sie mussten ein Backup über Minio selbst erstellen – laden Sie es und verwenden Sie alle Abstandshalter zwischen dem Dateisystem, und, was nicht weniger wichtig ist, besteht die Gefahr, dass Sie einige Buckets und Metainformationen vergessen. Oder nutzen Sie Deduplizierung.

Backup-Tools mit Duplizierung sind in Open Source verfügbar (auf Habré gab es). Artikel zu diesem Thema) und unsere Finalisten waren Kaution и Rest. Unser Vergleich der beiden Anwendungen finden Sie weiter unten. Zunächst erklären wir Ihnen jedoch, wie wir das gesamte Schema organisiert haben.

Backups verwalten

Borg und Restic sind gut, aber keines der Produkte verfügt über einen zentralisierten Kontrollmechanismus. Zur Verwaltung und Kontrolle haben wir uns für ein bereits implementiertes Tool entschieden, ohne das wir uns unsere Arbeit inklusive Automatisierung nicht vorstellen können – das ist das bekannte CI/CD – GitLab.

Die Idee ist wie folgt: Gitlab-Runner wird auf jedem Knoten installiert, der Nextcloud-Daten speichert. Der Läufer führt nach einem Zeitplan ein Skript aus, das den Backup-Prozess überwacht, und startet Borg oder Restic.

Was haben wir bekommen? Feedback aus der Ausführung, komfortable Kontrolle über Änderungen, Details im Fehlerfall.

Hier hier auf GitHub Wir haben Beispiele des Skripts für verschiedene Aufgaben gepostet und es schließlich nicht nur dem Backup von Nextcloud, sondern auch vielen anderen Diensten angehängt. Es gibt dort auch einen Scheduler, wenn Sie ihn nicht manuell konfigurieren möchten (und wir möchten das nicht), und .gitlab-ci.yml

Es gibt noch keine Möglichkeit, das CI/CD-Timeout in der Gitlab-API zu ändern, aber es ist klein. Es muss erhöht werden, sagen wir 1d.

GitLab kann glücklicherweise nicht nur nach einem Commit, sondern nur nach einem Zeitplan starten, das ist genau das, was wir brauchen.

Nun zum Wrapper-Skript.

Für dieses Skript stellen wir folgende Bedingungen ein:

• Es sollte sowohl vom Läufer als auch manuell von der Konsole aus mit der gleichen Funktionalität gestartet werden.
• Es müssen Fehlerhandler vorhanden sein:
• Rückgabe Code.
• Suchen Sie im Protokoll nach einer Zeichenfolge. Für uns kann ein Fehler beispielsweise eine Meldung sein, die das Programm nicht als schwerwiegend ansieht.
• Verarbeitungszeitüberschreitung. Die Vorlaufzeit muss angemessen sein.
• Wir benötigen ein sehr detailliertes Protokoll. Aber nur im Fehlerfall.
• Vor dem Start werden außerdem zahlreiche Tests durchgeführt.
• Kleine Komfortboni, die wir während des Supportprozesses als nützlich empfanden:
• Der Beginn und das Ende werden im Syslog der lokalen Maschine aufgezeichnet. Dies hilft, Systemfehler und Backup-Vorgänge zu verbinden.
• Ein Teil des Fehlerprotokolls, falls vorhanden, wird auf stdout ausgegeben, das gesamte Protokoll wird in eine separate Datei geschrieben. Es ist praktisch, sich CI sofort anzusehen und den Fehler zu bewerten, wenn er trivial ist.
• Debugging-Modi.

Das vollständige Protokoll wird als Artefakt in GitLab gespeichert; wenn kein Fehler vorliegt, wird das Protokoll gelöscht. Wir schreiben das Skript in Bash.

Wir freuen uns über Anregungen und Kommentare zu Open Source – willkommen.

Wie funktioniert das

Auf dem Backup-Knoten wird ein Runner mit einem Bash-Executor gestartet. Laut Planer wird der Job CI/CD in einer speziellen Rübe gestartet. Für solche Aufgaben startet der Runner ein universelles Wrapper-Skript, das die Gültigkeit des Backup-Repositorys, der Mount-Punkte und allem, was wir wollen, überprüft und dann das alte sichert und bereinigt. Das fertige Backup selbst wird an S3 gesendet.

Wir arbeiten nach diesem Schema – es handelt sich um einen externen AWS-Anbieter oder ein russisches Äquivalent (es ist schneller und die Daten verlassen die Russische Föderation nicht). Oder wir installieren für diese Zwecke einen separaten Minio-Cluster für den Kunden auf seiner Website. Normalerweise tun wir dies aus Sicherheitsgründen, wenn der Kunde nicht möchte, dass die Daten überhaupt seinen Kontakt verlassen.

Die Funktion zum Senden von Backups per SSH haben wir nicht genutzt. Dies erhöht die Sicherheit nicht und die Netzwerkfähigkeiten des S3-Anbieters sind viel höher als die unserer einzigen SSH-Maschine.

Um Ihren lokalen Computer vor einem Hacker zu schützen, müssen Sie die Versionierung aktivieren, da dieser Daten auf S3 löschen kann.
Das Backup verschlüsselt immer das Backup.

Borg verfügt über einen unverschlüsselten Modus none, aber wir raten dringend davon ab, es einzuschalten. In diesem Modus findet nicht nur keine Verschlüsselung statt, sondern es wird auch keine Prüfsumme der geschriebenen Daten berechnet, was bedeutet, dass die Integrität nur indirekt über Indizes überprüft werden kann.

Ein separater Planer prüft Backups auf die Integrität von Indizes und Inhalten. Die Prüfung ist langsam und langwierig, daher führen wir sie einmal im Monat separat durch. Es kann mehrere Tage dauern.

Readme auf Russisch

Grundfunktionen

• prepare Ausbildung
• testcheck Bereitschaftsprüfung
• maincommand Kern Team
• forcepostscript eine Funktion, die am Ende oder irrtümlicherweise ausgeführt wird. Wir verwenden es, um die Partition auszuhängen.

Servicefunktionen

• cleanup Wir protokollieren Fehler oder löschen die Logdatei.
• checklog Analysieren Sie das Protokoll auf das Auftreten einer Zeile mit einem Fehler.
• ret Exit-Handler.
• checktimeout Überprüfen Sie, ob eine Zeitüberschreitung vorliegt.

Arbeitsumfeld

• VERBOSE=1 Wir zeigen Fehler sofort auf dem Bildschirm an (stdout).
• SAVELOGSONSUCCES=1 Speichern Sie das Protokoll bei Erfolg.
• INIT_REPO_IF_NOT_EXIST=1 Erstellen Sie ein Repository, falls es noch nicht vorhanden ist. Standardmäßig deaktiviert.
• TIMEOUT maximale Zeit für die Hauptoperation. Sie können es am Ende als „m“, „h“ oder „d“ festlegen.

Speichermodus für alte Kopien. Default:

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

Variablen im Skript

• ERROR_STRING – Zeichenfolge für das Eincheckprotokoll für Fehler.
• EXTRACT_ERROR_STRING – Ausdruck zum Anzeigen der Zeichenfolge bei Fehler.
• KILL_TIMEOUT_SIGNAL — Signal zum Töten bei Zeitüberschreitung.
• TAIL — wie viele Zeichenfolgen mit Fehlern auf dem Bildschirm angezeigt werden.
• COLORMSG — Farbe der Nachricht (Standard: Gelb).

Dieses Skript namens WordPress hat einen bedingten Namen. Der Trick besteht darin, dass es auch die MySQL-Datenbank sichert. Dies bedeutet, dass es für Einzelknoten-Nexcloud-Installationen verwendet werden kann, bei denen Sie auch die Datenbank sichern können. Der Vorteil besteht nicht nur darin, dass sich alles an einem Ort befindet, sondern auch, dass der Inhalt der Datenbank nah am Inhalt der Dateien liegt, da der Zeitunterschied minimal ist.

Restic gegen Borg

Es gibt auch Vergleiche zwischen Borg und Restic hier auf Habré, und wir hatten nicht die Aufgabe, nur ein weiteres zu erschaffen, sondern unser eigenes. Es war uns wichtig, wie es auf unseren Daten aussehen würde, mit unseren Besonderheiten. Wir bringen sie.

Unsere Auswahlkriterien, zusätzlich zu den bereits genannten (Deduplizierung, schnelle Wiederherstellung usw.):

• Widerstand gegen unvollendete Arbeit. Auf Kill prüfen -9.
• Größe auf der Festplatte.
• Bedarf an Ressourcen (CPU, Speicher).
• Größe der gespeicherten Blobs.
• Arbeiten mit S3.
• Integritätsprüfung.

Zum Testen haben wir einen Client mit echten Daten und einer Gesamtgröße von 1,6 TB genommen.
Bedingungen.

Borg weiß nicht, wie man direkt mit S3 arbeitet, und wir haben die Festplatte per montiert doof. Restic hat es an S3 selbst gesendet.

Goofys funktioniert sehr schnell und gut, und das gibt es Festplatten-Cache-Modul, was die Arbeit noch weiter beschleunigt. Es befindet sich in der Beta-Phase, und ehrlich gesagt sind wir bei Tests (anderen) aufgrund von Datenverlust abgestürzt. Der Vorteil besteht jedoch darin, dass der Sicherungsvorgang selbst nicht viel Lesen, sondern hauptsächlich Schreiben erfordert, sodass wir den Cache nur bei Integritätsprüfungen verwenden.

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

Vergleichstestergebnisse.

• Kill -9 mit einem weiteren Neustart waren beide erfolgreich.
• Größe auf der Festplatte. Borg kann komprimieren, daher sind die Ergebnisse wie erwartet.

Backuper
Größe

Kaution
562Gb

Rest
628Gb

• Nach CPU
  Borg selbst verbraucht mit der Standardkomprimierung wenig, muss aber zusammen mit dem Goofys-Prozess ausgewertet werden. Insgesamt sind sie vergleichbar und nutzen etwa 1,2 Kerne auf derselben virtuellen Testmaschine.
• Erinnerung. Restic ist etwa 0,5 GB groß, Borg etwa 200 MB. Im Vergleich zum Systemdateicache ist das jedoch alles unbedeutend. Daher ist es ratsam, mehr Speicher zuzuweisen.
• Der Unterschied in der Blobgröße war auffällig.

Backuper
Größe

Kaution
ca. 500 MB

Rest
ca. 5 MB

• Die S3-Erfahrung von Restic ist ausgezeichnet. Die Arbeit mit Borg über Goofys wirft keine Fragen auf, es wurde jedoch festgestellt, dass es ratsam ist, nach Abschluss der Sicherung einen umount durchzuführen, um den Cache vollständig zurückzusetzen. Die Besonderheit von S3 besteht darin, dass zu wenig gepumpte Chunks niemals in den Bucket geschickt werden, was bedeutet, dass unvollständig gefüllte Daten zu großem Schaden führen.
• Die Integritätsprüfung funktioniert in beiden Fällen gut, allerdings unterscheidet sich die Geschwindigkeit deutlich.
  Restisch 3,5 Stunden.
  Borg, mit 100 GB SSD-Dateicache – 5 Stunden.Ungefähr die gleiche Geschwindigkeit ergibt sich, wenn sich die Daten auf einer lokalen Festplatte befinden.
  Borg liest direkt von S3 ohne Cache 33 Stunden. Ungeheuer lang.

Das Fazit ist, dass Borg komprimieren kann und über größere Blobs verfügt – was die Speicherung und GET/PUT-Vorgänge in S3 billiger macht. Dies geht jedoch mit einer komplexeren und langsameren Überprüfung einher. Was die Wiederherstellungsgeschwindigkeit angeht, konnten wir keinen Unterschied feststellen. Restic benötigt nachfolgende Backups (nach dem ersten) etwas länger, aber nicht wesentlich.

Nicht zuletzt war die Größe der Community ausschlaggebend für die Wahl.

Und wir haben uns für Borg entschieden.

Ein paar Worte zur Komprimierung

Borg hat einen hervorragenden neuen Komprimierungsalgorithmus in seinem Arsenal – zstd. Die Komprimierungsqualität ist nicht schlechter als bei gzip, aber viel schneller. Und in der Geschwindigkeit vergleichbar mit dem Standard-LZ4.

Beispielsweise wird ein MySQL-Datenbank-Dump bei gleicher Geschwindigkeit doppelt so gut komprimiert wie lz4. Erfahrungen mit realen Daten zeigen jedoch, dass es kaum Unterschiede im Komprimierungsverhältnis des Nextcloud-Knotens gibt.

Borg verfügt über einen eher Bonus-Komprimierungsmodus: Wenn die Datei eine hohe Entropie aufweist, wird die Komprimierung überhaupt nicht angewendet, was die Geschwindigkeit erhöht. Durch Option beim Erstellen aktiviert
-C auto,zstd
für den zstd-Algorithmus
Mit dieser Option erhalten wir also im Vergleich zur Standardkomprimierung
560 GB bzw. 562 GB. Ich möchte Sie daran erinnern, dass die Daten aus dem obigen Beispiel ohne Komprimierung 628 GB betragen. Das Ergebnis von 2 GB Unterschied hat uns etwas überrascht, aber wir dachten, dass wir uns doch dafür entscheiden würden. auto,zstd.

Sicherungsüberprüfungsmethode

Laut Scheduler wird die virtuelle Maschine direkt vom Provider oder vom Client gestartet, was die Netzwerklast stark reduziert. Zumindest ist es billiger, als es selbst aufzuziehen und den Verkehr anzukurbeln.

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 dem gleichen Schema überprüfen wir Dateien (nachträglich) mit einem Antivirenprogramm. Schließlich laden Benutzer unterschiedliche Dinge auf Nextcloud hoch und nicht jeder verfügt über ein Antivirenprogramm. Die Durchführung von Inspektionen zum Zeitpunkt des Gießens nimmt zu viel Zeit in Anspruch und beeinträchtigt den Geschäftsbetrieb.

Skalierbarkeit wird erreicht, indem Läufer auf verschiedenen Knoten mit unterschiedlichen Tags ausgeführt werden.
Unser Monitoring sammelt Backup-Status über die GitLab-API in einem Fenster; bei Bedarf werden Probleme leicht erkannt und ebenso leicht lokalisiert.

Abschluss

Dadurch wissen wir sicher, dass wir Backups erstellen, dass unsere Backups gültig sind, dass damit auftretende Probleme wenig Zeit in Anspruch nehmen und auf der Ebene des diensthabenden Administrators gelöst werden. Backups nehmen im Vergleich zu tar.gz oder Bacula wirklich wenig Platz ein.

Source: habr.com