Nextcloud Umzug: einfach machen, nicht einfacher.

„So einfach wie möglich. Aber nicht einfacher.“

Dieses Zitat stammt von Albert Einstein und heißt maximal ausformuliert in etwa „mach dir ein Problem so einfach, dass du es lösen kannst, nicht aber einfacher als es sein muss, denn dann geht der Sinn in dem Problem verloren“.


Der Titel-Satz hat vom Ursprung her zwar überhaupt nichts mit IT zu tun, und doch musste ich mich Anfang der Woche daran erinnern.

Ich habe auf meinem Homeserver unter anderem eine selbst gehostete Nextcloud auf Docker-Basisi am laufen. Der Einfachheit halber habe ich damals als Datenbankgrundlage SQLite genommen, eine kleine, selbsständige Datenbank, die oft in beengten Situationen, wie Mobiltelefonen oder kleinen Anwendungen verwendet wird.

Für mich als einzigen Nutzer ist das an sich auch ausreichend, jedoch kamen in Vergangenheit immer mal wieder Situationen aus, die mich störten: das Laden des Web-GUI dauerte länger, Befehle aus der Dokumentation funktionierten nicht (weil diese eine MySQL Datenbank vorraussetzten) oder, noch viel schlimmer, Backups von Kontakten und Kalendern konnten nicht importiert werden, bzw. nur auf Biegen und Brechen mit massiven Fehlern.

Deswegen wollte ich meinen Unterbau auffrischen mit dem Ziel: einen Container für die Nextcloud, und einen für eine MySQL/MariaDB Datenbank.

Weil der Mensch faul ist, wovon ich mich nicht auch ausschließen kann, wollte ich es schnell und einfach. Nicht dreckig, aber rückblickend wäre es das doch wohl geworden. Wenn ich etwas mache, dann denke ich in die Zukunft und will es direkt ordentlich machen.

Versuch 1: schnell einfach = Denkfehler

Zuerst habe ich die neue Nextcloud mit einem Compose-File aufgesetzt und gestartet. Ich dachte, allein die Angabe meines vorhandenen Datenverzeichnisses genügt, um die neue Installation nutzen zu können.


Wie zu erwarten, hat es das nicht: die Nutzer wurden in der Loginmaske nicht erkannt, die Installation forderte das Administratorkonto einer Erstinstallation.

Versuch 2: mehr denken führt auch mal zu Problemen

Als nächstes dachte ich, ich starte die neue Nextcloud, fahre den alten Container runter, damit dieser nicht in die Datenverzeichnisse schreibt und beim Import inkonsistente Daten hervorruft, und kopiere die Daten aus dem Web-GUI in die neue NC.

Fehler 1:

wenn die alte Nextcloud nicht läuft, kann ich nicht auf die Daten zugreifen (hätte man sich auch denken können…). Weiter KÖNNEN garnicht beide Nextcloud-Instanzen laufen, da immer nur ein Container das darunterliegende Image nutzen kann!

Fehler 2:

per SFTP konnte ich auch nicht an die Daten, da das Datenverzeichnis zwingend dem User „www-data“ gehören MUSS. Der Root-User kann dass zwar umgehen („Ich bin Root, ich darf das!“), aus Sicherheitsgründen habe ich aber den Root-Login auf meinen Server deaktiviert und der Nutzer „www-data“ hat außerhalb meiner Nextcloud nichts zu melden.


Ergebnis: Daten nicht grafisch aufrufbar.

Versuch 3: umständlich von Anfang an = (fast immer) erfolgreich

Dann musste ich doch in den sauren Apfel beißen: Nextcloud wurde mit neuer MariaDB gestartet, und meine Nutzer der alten Nextcloud manuell angelegt und die Konten und Apps wie vorher eingerichtet.


Danach habe ich per SSH-Terminal von meinem Server die Daten von Verzeichnis „Alt“ (/mnt/hdd/nextcloud/USER/files/) mittels rekursiven Copy-Befehls („cp -r“) in das neue User-Verzeichnis kopiert (/mnt/hdd/ncdata/USER/files/).


Damit noch nicht getan, denn die Nextcloud, bzw. besser die Datenbank weiß noch nichts davon, dass die Daten jetzt vorliegen.


Zum Glück hat Nextcloud dafür einen schönen, wenn auch langen Indexier-Befehl parat:

„sudo docker exec -ti –user www-data [nextcloud-app] /var/www/html/occ files:scan –all“

Danach waren alle Ordner und Dateien im Web-GUI wieder vorhanden und auch meine Kalender und Kontakte wurde fehlerfrei importiert.

Was lernen wir daraus: manchmal muss es doch etwas mehr sein als „eben mal schnell“. Sich die Dinge genau zu überlegen verhindert viele Probleme, kann aber auch in die falsche Richtung leiten.


Eben nach dem Motto „mach es dir einfach und stressfrei, aber nicht einfacher, denn dann ist es keine zufriedenstellende Lösung“.


Auf jeden Fall habe ich einiges dazugelernt, was ich bestimmt in Zukunft nochmal gebrauchen kann.


Und denkt immer dran: vor solchen Operationen am offenen Herzen sind Backups ein Muss und ersparen euch haufenweise Stress und Ärger!

Over and Out


– Boba Fett

Keine Angst vor Backups (4): Duplicati

Rückblick: Im ersten Artikel habe ich euch erklärt, wie ihr euch eine passende Backupstrategie überlegt und was es dabei zu beachten gibt. Im Folgeartikel wurden Arten von Sicherungen erläutert und miteinander verglichen. Im darauffolgenden Artikel wurde das Thema Raid auf der Serverseite angesprochen und wie sich damit Backups noch sicherer und effizienter gestalten lassen. In diesem, und auch letzten Artikel der Reihe „Kein Backup, kein Mitleid!“, möchte ich euch schließlich ein Programm vorstellen.

Ein Tool für Alle:

Das Tool Duplicati ist ein plattformunabhängiges Open-Source Tool, um Backups verschlüsselt und inkrementell an verschiedenen Speicherorten automatisiert zu sichern. Das Tool ist für Windows, MacOS und Linux sowie als Docker-Container verfügbar, läuft ressourcenarm lokal als Hintergrunddienst und wird über den Browser verwaltet.

Die Software:

Ist die Software installiert und mit einem Doppelklick gestartet, öffnet sich ein Browserfenster mit der noch nackten Hauptansicht.

Eine neue Sicherung erstellt ihr mit „Sicherung hinzufügen“. Ihr gebt einen Namen und optional eine Beschreibung ein. Ihr könnt, und solltet diese Option bei Cloud-Backups auch nutzen (siehe erster Artikel), die Backups per AES-256 verschlüsseln. Dafür denkt ihr euch eine lange, zufällige Passphrase aus und notiert euch diese extern. Nur damit lassen sich später Backups wiederherstellen.

Auf der nächsten Seite gebt ihr euer Ziel an. Hier habt ihr alle erdenklichen Möglichkeiten: lokale HDD am PC, Samba/CIFS/SMB, FTP, SFTP/SSH, WebDAV, sowie proprietäre Formate wie Dropbox, OneDrive, Azure, Google Drive, MEGA und viele mehr.

Je nach Anbieter solltet ihr das passende Protokoll wählen, ich empfehle aufgrund der Geschwindigkeiten der Übertragung SFTP/SSH, mit Samba/SMB als Allrounder macht ihr aber auch nichts falsch. Je nach Protokoll müsst ihr Angaben zu Benutzer und Passwort tätigen. Darunter lässt sich direkt die Verbindung direkt prüfen.

Jetzt folgen die zu sichernden Dateien. Lest euch gerne dazu meinen ersten Artikel dieser Reihe durch.


Über die Filter und „Ausschließen“ lassen sich temporäre oder Systemdateien sowie eigene Dateien aus der Sicherung ausschließen.

Im nächsten Abschnitt folgt die Automatisierung mit dem Sicherungsintervall. Siehe dazu Artikel 1 für weiter Infos.

Im letzten Reiter legt man fest, wie die Sicherungen erhalten werden sollen. Ich empfehle mindesten 3 Stück, oder wählt „Sicherungen löschen, die älter sind als X Monate“ aus, um regelmäßig alte Sicherungen zu entfernen, um Platz zu sparen.

Achtet aber darauf, immer genug Sicherungen zu behalten, falls eine davon mal streiken sollte.

Eure Sicherung ist nun fertig erstellt und wird zeitnah ausgeführt.


Von jetzt an müsst ihr nichts weiter mehr tun, außer sicherzustellen, dass das Ziellaufwerk auch erreichbar bzw. angeschlossen ist.

Natürlich könnt ihr auch gleichzeitig mehrere Backup-Pläne erstellen, um auf verschiedene Laufwerke oder außer Haus zu sichern (siehe Artikel 1 für weitere Infos).

Tipps zur Wiederherstellung:

Da die Sicherungen inkrementell gespeichert werden, belegen sie weniger Platz, und sind deshalb nicht per „Drag and Drop“ wiederherzustellen.

Die Backup-Pläne lassen sich aber einfach als JSON Konfigurationsdatei exportieren, die sich dann auf jeder neuen Duplicati Instanz laden lassen, was den Zugriff auf die Backups erlaubt.

Auch wenn diese Datei nicht vorhanden ist, gibt es noch einen Rettungsversuch: Aus der „Wiederherstellen“ Seite könnt ihr entweder direkt aus den Sicherungsdateien, indem ihr die JSON Konfig Dateien ladet, oder aus einem vorhanden Backup-Plan Daten wiederherstellen. Damit ist man nochmals abgesichert und kommt immer an seine Dateien ran.

Was tun bei Error-Meldungen:

Hin und wieder kann es vorkommen, dass Meldungen mit Warnungen aufploppen. Diese haben meist (hauptsächlich unter Windows aufgrund der Berechtigungsstruktur) damit zu tun, dass Benutzerrechte Probleme bereiten, System- und Temp-Dateien sich nicht sichern lassen, oder Dateien doppelt vorliegen.

Diese Meldungen sind nicht schlimm und führen (meist) nicht zu fehlerhaften Backups. Kommen jedoch Fehlermeldungen (Errors) in rot, meist ganz viele, sollte man sich diese ansehen, dann hat etwas nicht geklappt und die Infos dazu geben gute Hinweise, wo man den Fehler suchen muss.

Abschließende Worte:

Damit habe ich die Reihe „Kein Backup, kein Mitleid!“ zu Ende geführt. Die Idee dazu kam mir, weil ich damals selten einen ausführlichen, aber anfängerfreundlichen Guide gefunden habe und mir alle Schritte einzeln zurechtlesen musste. Gefolgt von vielen Umbauten, Neukonfigurationen und schlechten Backups. Mit dieser Reihe habe ich euch hoffentlich genug Infos und Material an die Hand gegeben, damit ihr einfach, sicher, zuverlässig und vor allem regelmäßig (!) Backups erstellen (lassen) könnt.

Wenn ihr trotzdem noch Fragen habt, schreibt diese gerne in der Kommentarsektion.

„Kein Backup, kein Mitleid!“ – Konfuzius


„Raid ist kein Backup!“ – Dante


„Das ist doch eh irgendwie alles in der Cloud!“ – Mona Lisa

„Die Cloud ist nur der Computer von jemand anderem. Mitsamt all seinen Schwächen.“ – Satz aus dem Lehrbuch eines Systemadministrators

Kein Backup, kein Mitleid (3): Raid Level

Dieser kleine Exkurs gehört eigendlich nicht in die Reihe „Kein Backup, kein Mitleid“ hinein und müsste streng genommen „Raid ist kein Backup“ heißen.


Trotzdem will ich kurz das Thema des „Verbundes“ ansprechen.

Ein Raid Verbund einrichten lässt sich auf Festplatten und SSDs einrichten, bei USB-Sticks und SD-Karten sollte man darauf aber verzichten.


Bei einem Raid, auch Festplattenverbund genannt, verbindet man Festplatten in verschiedener Weise miteinander, um neben den regelmäßigen Backups zur Datensicherheit eine Ausfallsicherheit im Backup-Speicherort zu gewährleisten.


Dabei werden in der Praxis verschiedene Raid Typen am häufgsten verwendet: Raid 0, 1, 5, 6 und 10.


Weil aber Raid 0 auf Geschwindigkeit augelegt ist, indem man mehrere Plattenkapazitäten einfach addiert und eine „große“ Festplatte daraus macht, eigent sich dieser Typ nicht als Option für Backupspeicher, da bei einem Festplattendefekt alle Daten auf allen Festplatten verloren sind.


Zu Raid 6 und 10 komme ich gleich noch.

Raid 0 – nicht für Backups geeignet

Erstellen lassen sich Raids entweder als Hardware-Raid per dediziertem Raidcontroller, oder als Software-Raid per Software bei Synology, UgreenOS Pro, OpenMediaVault, TrueNAS oder einem reinen Linux und Windows Server.

Raid 1:

Bei einem Raid 1, auch Spiegelung oder Mirror genannt, werden die Daten 1:1 auf alle Festplatten gleichermaßen gespeichert.


Bei zwei mal 1TiB Festplatten hat man also auch nur 1TiB als Speicher zur Verfügung.


Wenn eine der Festplatten jedoch ausfällt, kann man diese austauschen und das Raid kopiert die Daten der funktionierenden HDD auf die neue Festplatte.

Vorteile:
  • einfach einzurichten
  • sehr hohe Aufallsicherheit
Nachteile:
  • halbe Kapazität
  • Neuaufbau des Raids kann je nach Festplatten sehr lange dauern

Raid 1 – die Empfehlung in fast allen Fällen

Raid 5:

Ist einem die hohe „Speicherverschwendung“ eines Raid 1 nicht recht, kann man ein Raid 5 einrichten.


Hierbei benötigt man zwingend 3 oder mehr gleich große Festplatten, denn: jede Festplatte beinhaltet von jedem Datenblock einen Teil, und zusätzlich einen Paritätsblock. Dieser ist dann wichtig, wenn eine der Festplatten ausfällt: Aus der Paritätssumme lässt sich der Wert berechnen, der auf der ausgefallenen Festplatte gelegen hat, und kann dann bei einbau einer neuen Platte wiederhergestellt werden.

Vorteile:
  • schneller als Raid 1, da Grundidee wie bei einem Raid 0 besteht
  • Kapazität ist mit der „Summe aller Festplatten – eine Festplatten“ größer als bei Raid 1 (von 1 1 1 1 TiB sind 3TiB verfügbar)
Nachteile:
  • Ausfall einer Festplatte ist möglich, fallen aber direkt 2 aus, sind alle Daten weg
  • mehr Anschaffungskosten und mehr Stromverbrauch

Raid 5 – wenn vie Speicherplatz gefragt ist

Raid 6:

Ein Raid 6 ist die verbesserte Version eines Raid 5, da es auf jeder Platte 2 Paritätsblöcke gibt, es können also bis zu 2 Festplatten ausfallen, bevor Daten verloren gehen.

Vorteile:
  • schneller als Raid 1
  • Kapazitätsrechnung wie bei Raid 5
Nachteile:
  • mindestens 4 Festplatten nötig, dadurch mehr Verbrauch und höhere Kosten
  • weniger Geschwindigkeit als bei Raid 5

Raid 6 – wenn Typ 5 nicht sicher genug ist

Raid 10:

Ein Raid 10 ist eine Mischung aus Raid 1 und 0, mit dem man Redundanz und Geschwindigkeit verbinden möchte: man erstellt aus 4 Festplatten jeweils 2 Raid 1, und verbindet diese Raids dann zu einem großen Raid 0

Voteile:
  • schnell und sicher
Nachteile:
  • Konfiguration komplex
  • hohe Anschaffungskosten

Raid 10 – schnell, sicher, teuer

Wenn es sich anbietet, was bei fertigen NAS Lösungen von Synology, Ugreen, Qnap und co. meist der Fall ist, sollte man ein Raid einrichten (lassen).


Es schützt explizit NICHT (!) vor Datenverlust, ein Raid ersetzt in keinster Weise ein vernünftiges und regelmäßiges Backup (siehe Artikel 1 und 2). Es ist aber eine Hilfe bei einem Festplattendefekt, die Backupdaten nicht zu verlieren.


Man erspart sich also langwieriges Neukonfigurieren und Kopieren aller Daten auf die neue Backup Platte.

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.

ACEPTAR
Aviso de cookies