ubuntuusers.de

Hallo zusammen,

ich möchte meinen Server bald durch eine neue Hardware und Betriebssystem ersetzen. Im Moment habe ich einen Server (ASRrock Deskmini 310) mit 8GB-Ram und ein RAID1 (2x1TB)

Als Backup (Datensicherung) verwende ich Clonezilla auf einer externen USB3.0 Platte mit 2 Partitionen,boot mit Clonezilla 500MB, Data der Rest.

So nun zum Problem:

• auf dem Server läuft Nextcloud für 7 User)

• je, PC, Tablet & Smartphone, (alles ohne Google, Whatsapp, Dropbox, O365 & MS)

• inkl. caldav, carddav, tesseract orc, face_recognition, notes, Talk - Screensharing, online meetings & web conferencing, chat

• Elasticsearch zur Volltextsuche (die Indextabellen belegen ca. 30% des Datenbestandes)

• das System ist Vollverschlüsselt

• differentielle und inkrementelle Backups sind durch die Vollverschlüsselung nicht möglich

• über Netzwerk sichern, hausintern 1GBit, extern upload 50MBit ist viel zu langsam

Das Vollbackup mache ich einmal die Woche, dann ist der Server in Downtime. Für das Vollbackup, von dem 1 TB-Plattenplatz sind ca. 750GB belegt, benötigt der Server 3,5 Stunden, als er sichert mit 3,5GB/Min.

Ein neuer Server wird nach meiner Planung wieder für 4-5 Jahre seinen Dienst tun sollen, die Achillesferse ist das Backup Wenn ich den neuen Server mit 2x8TB Platten ausstatte heisst das:

8TB sichern mit 3,5GB/Min = 35 Stunden !

Ich habe mit anderen Platten und Rechnern getestet: (Vollbackup einer verschlüsslleten Platte)

Intel i7-3520M 4x 2.9GHz (SATA3 intern > USB3.0 extern) 5,5GB/Min = 24 Stunden ! Intel i7-4810MQ 8x 2.8GHz (SATA3 intern > USB3.0 extern) 8,5GB/Min = 15,7 Stunden !

Ich wollte aber nicht in extreme Preise nach oben klettern (der ASRrock liegt bei ca. 500€)

Achso, ja mein Vollackup ist ein Disaster Recovery, da ich es auch ausser Haus lagere und auch teste (Diebstahl, Wasser, Brand, Überspannung)

Wie kann man ich verträglicher Zeit ein Backup großer Datenmengen machen

Hallo!

Ein Vorschlag: Du holst dir für den Server einen Wechselrahmen und mehrere Festplatten. Die im Rahmen bindest du dann als RAID 1 ein und wechselst die Platte regelmässig (als defekt markieren, austauschen, neuer rebuild). Dann hast du bei kurzer Downtime (die du nicht mal brauchen würdest) eine 1:1-Kopie der aktuellen Platte, die eingewechselte wird wieder auf den neuesten Stand gebracht.

Zusätzlich kannst du klassich die essentiellen Daten per rsync auf externe Festplatte sichern. Diese kann natürlich verschlüsselt sein, enthält aber nur die wirklich notwendigen (Nutzer- und Konfigurations-)Daten.

Hallo danke schon mal für die schnelle erste Antwort.

D.h. RAID und Backup

Das Entfernen einer der beiden Festplatte führt immer dazu, dass sich das RAID im Fehlerzustand (degraded) geht. Bei Wiedereinsetzen der 2-ten Platte muss die verbleibende Festplatte jedesmal komplett neu mit der neu eingesetzten Platte synchronisiert werden. In dieser Zeit wird das System nicht sinnvoll verwendbar.

Soweit das SATA-3 System perfekt arbeitet heißt das 540MByte/s (max.600MByte/s) Also Sync dauert : 8.000 GB / 0,6GB/s /3600s/h = 4,1 Stunden

Hallo sonja, die bisher vorgestellte Lösung hat nun einmal diese Beschränkungen und kostet entsprechend Rechenzeit.

Solltest Du aber Dich davon lösen wollen ist es am sichersten mit fertigen NAS-Systemen zu arbeiten. Davon werden natürlich 2 gleiche Systeme benötigt, die über eine LAN-Kopplung direkt verbunden sind. So ein "Gespann" hält sich fast in Echtzeit synchron.

Kostet allerdings eine Anschaffungsgebühr.

Dies kann man dämpfen indem man sich diese Technik z.B. mit XIGMA-NAS oder FREENAS selbst erstellt.

Wenn solche hohen Anforderungen gestellt sind, dann nutzen wir dazu Geräte von THECUS.

Bye HS

Hallo gelesen, das manche NAS auch SNAPSHOTS unterstützen. Wenn man also einen SNAPSHOT macht und diesen dann sichert, hat man nur eine kurze Ausfallzeit. Habe aber selbst keine Erfahrungen damit.

homer65 schrieb:

Hallo gelesen, das manche NAS auch SNAPSHOTS unterstützen. Wenn man also einen SNAPSHOT macht und diesen dann sichert, hat man nur eine kurze Ausfallzeit. Habe aber selbst keine Erfahrungen damit.

Das ist an dieser Stelle der richtige Hinweis. Habe gerade nicht viel Zeit, aber die generelle Herangehensweise wäre:

1. Auf dem Server ein Dateisystem (oder Abstraktionsschicht) verwenden, das Snapshots beherrscht. Da du Vollverschlüsselungs erwähnst, kann es ja durchaus sein, dass du ein LVM betreibst. Das kann auch Snapshots

2. Snapshots im Betrieb machen und Daten auf das (wiederum unabhängig verschlüsselte) Ziel übertragen.

3. Snapshot dort auf den exisiterenden Datenbestand anwenden. Die Implikation hier ist, dass das Ziel auch alle Daten lesen kann und dementsprechend unter deiner Kontrolle sein muss.

Ich habe das mal versucht, mit BTRFS aufzubauen und das hat auch geklappt, allerdings ist das btrfs-send fehlgeschlagen, wenn sich Quelle und Ziel nicht im selben lokalen Netzwerk befunden haben. Ein SSH-Tunnel, der Ziel und Quelle logsich verbunden hat, hat nicht funktioniert. Bei mir stand noch aus, das über ein VPN zu machen und damit über UDP statt TCP wie beim SSH-Tunnel, aber da bin ich dann nie zu gekommen.

Du könntest es auch mit ZFS probieren, das ja allgemein als ausgereifter gilt.

Viel Erfolg!

sonja schrieb:

• differentielle und inkrementelle Backups sind durch die Vollverschlüsselung nicht möglich

Inwiefern macht die Vollverschlüsselung solche Backups unmöglich?

Mein Lösungsansatz sieht gedacht so aus: Außer der Vollverschlüsselung auf dem Server ist auch das Backup-Medium entsprechend verschlüsselt. Für die Sicherung werden beide/alle beteiligten Medien aufgeschlossen, die volle/differentielle/inkrementelle Sicherung ausgeführt, und die Medien wieder zugeschlossen.

Du hast damit gewährleistet, dass sowohl im Live-System als auch im Bereich der Sicherungen ein Grundschutz durch die Verschlüsselung besteht. Gleichzeitig kannst du so die Dauer der Sicherungsvorgänge reduzieren. Mit ein paar Tricks vor allem der rsync-basierten Tools könntest du damit täglich ein Vollsicherungsäquivalent anlegen - sogar ganz ohne Downtime.

Vielleicht hilft das hier weiter: https://www.techrepublic.com/article/how-to-back-up-nextcloud/

sonja schrieb:

• differentielle und inkrementelle Backups sind durch die Vollverschlüsselung nicht möglich

rsync sollte eigentlich auch Binärdaten (wie man sie von einem verschlüsselten Blockdevice bekommt) per delta Transfer abgleichen können: https://blog.christophersmart.com/2014/01/15/force-rsync-to-use-delta-transfer-to-fix-corrupt-remote-file/.

sonja schrieb:

Hallo zusammen,

• auf dem Server läuft Nextcloud für 7 User)

• je, PC, Tablet & Smartphone, (alles ohne Google, Whatsapp, Dropbox, O365 & MS)

• inkl. caldav, carddav, tesseract orc, face_recognition, notes, Talk - Screensharing, online meetings & web conferencing, chat

• Elasticsearch zur Volltextsuche (die Indextabellen belegen ca. 30% des Datenbestandes)

Läuft das alles in einer Linux-Umgebung oder sind da Windows Rechner dabei? ( O365 & MS )

• das System ist Vollverschlüsselt

• differentielle und inkrementelle Backups sind durch die Vollverschlüsselung nicht möglich

Warum? Wird während des Backup die HD nicht geöffnet, oder verschlüsselt Du die Daten erst und machst dann das Backup?

Nimm rsync, das macht alles, was Du brauchst und die Backupzeiten liegen im Minutenbereich.

Wenn man noch über rsnapshot geht, ist auch rsync, aber mit interner Organisation und Historie, bleiben keine Wünsche offen.

Als Filesystem nimm BTRFS. Dann kann man online die HD auf Bitfehler testen.

Ist man paranoid, kann man alle Woche im rsync den Flag -c setzen. dann erfolgt ein Bitvergleich, der aber lange dauern kann.

Testen, ob die Daten am Ziel ankommen, die du haben willst.

Warum eigentlich Downtime?
Ist eine Datei grad in Bearbeitung, wird die unvollständig kopiert und kommt beim nächsten mal wieder dran. rsync erledigt das.

• über Netzwerk sichern, hausintern 1GBit, extern upload 50MBit ist viel zu langsam

Warum?

Ich mache Sicherungen über alte DSL-Modems. Gut nicht Terabytes, aber komplette Home-PCs schon. Alle 6 Stunden, wenige Minuten.

Oder nimm auch auf dem Server BTRFS, das kann Snapshots. Dann hat man Zeit, ein Backup ohne Downtime zu machen.

I hope this helps.

rleofield

rleofield schrieb:

sonja schrieb:

• differentielle und inkrementelle Backups sind durch die Vollverschlüsselung nicht möglich

Warum? Wird während des Backup die HD nicht geöffnet, oder verschlüsselt Du die Daten erst und machst dann das Backup?

Es wird mit Clonezilla gearbeitet, also auf Blocklevel, also ja, wird nicht geöffnet.

Nimm rsync, das macht alles, was Du brauchst und die Backupzeiten liegen im Minutenbereich.

Letzteres ist nicht korrekt. Das Problem an rsync ist, dass die Differenz zum letzten Backup erst zur Laufzeit bestimmt werden kann. Es müssen also mindestens die Zeitstempel verglichen werden. Je nach Anzahl der Dateien dauert das ewig. Bei mir hat alleine dies Tage gedauert. Werden SSDs verwendet werden, wird es bedeutend schneller gehen, aber bei hinreichender Größe wird es immer noch so lange dauern, dass man kein konsistentes Backup mehr hinbekommt. Und da wir von einer Nextcloud mit Datenbank sprechen, sind Snapshots ohnehin das Mittel der Wahl.

Insofern schließe ich mich dem Hinweis an, BTRFS zu verwenden.

Wir haben 2020, da nimmt man Borg oder restic für Backups. Aus einem laufenden System stört die Vollverschlüsselung auch nicht.

mfg Stefan

encbladexp schrieb:

Wir haben 2020, da nimmt man Borg oder restic für Backups. Aus einem laufenden System stört die Vollverschlüsselung auch nicht.

Prinzipiell richtig, ich nutze selbst Borg auf dem Laptop mit geringen Datenmengen und SSD. Aber man kann bei vielen kleinen Dateien auf großen, langsamen Datenträgern halt prinzipiell alles knicken, was erstmal ermitteln muss, was sich verändert hat - und wenn es nur Zeitstempel liest. Da sind Snapshots die einzige Möglichkeit, das integer und in vertretbarer Zeit hinzubekommen.

unbuntuS12 schrieb:

encbladexp schrieb:

Wir haben 2020, da nimmt man Borg oder restic für Backups. Aus einem laufenden System stört die Vollverschlüsselung auch nicht.

Prinzipiell richtig, ich nutze selbst Borg auf dem Laptop mit geringen Datenmengen und SSD. Aber man kann bei vielen kleinen Dateien auf großen, langsamen Datenträgern halt prinzipiell alles knicken, was erstmal ermitteln muss, was sich verändert hat - und wenn es nur Zeitstempel liest. Da sind Snapshots die einzige Möglichkeit, das integer und in vertretbarer Zeit hinzubekommen.

Über was reden wir denn hier? Nutzerdaten sollte man m.E. getrennt von den Systemdaten sichern. Für die übliche Nutzerdaten ist Borg ein hervorragendes Tool. Ich habe mehrere Systeme, die ich so sichere und die inkrementellen Backups laufen sehr zügig. Das Betriebssystem kann man von Zeit zu Zeit klonieren oder z.B. über TAR sichern.

Vielen Dank für die zahlreichen Antworten, Anregungen und eigene Erfahrungen.

Ich werde nun für meinen Anwendungsfall einiges ausprobieren, vergleichen ...

Wenn ich für mich weiter gekommen bin werde ich hier berichten wie ich den Status Quo verbessern konnte.