Ergebnis 1 bis 12 von 12

Thema: Backupstrategie in mittelgroßer Einrichtung

  1. #1
    Defender of Freedom

    Administrator

    Avatar von Metal_Warrior
    Registriert seit
    Aug 2013
    Ort
    /dev/mapper/home
    Beiträge
    5.887
    ngb:news Artikel
    7

    Backupstrategie in mittelgroßer Einrichtung

    Ich spiel mal mit in unserem kleinen Wettbewerb. Was ich hier beschreibe ist die Lösung, die ich mir für ein hybrides Netzwerk einer HiOrg überlegt (und natürlich umgesetzt) hab.

    Alle Benutzer der Windows-Rechner speichern ihren Käse remote auf einem Debian-Server mit 2 TB Speicherplatz in einem RAID1-Verbund. Ist nicht viel, reicht aber bisher für die rund 300 GB an Daten locker aus. Die Rechtestruktur ist ziemlich simpel, es gibt Gruppen, die sich Shares teilen und für jeden einen privaten Bereich. Alle Daten werden einmal täglich vollständig auf eine externe 3TB-Platte synchronisiert, nach Wochentag aufgeschlüsselt. Dank rsync dauert das nur ein paar Minuten, weil sich innerhalb einer Woche nicht so viel ändert. Länger aufbewahrt wird jeder Sonntags-Snapshot, nämlich einen Monat lang, wobei rotierend umbenannt wird:

    So-4 -> So-0
    So-3 -> So-4
    So-2 -> So-3
    So-1 -> So-2
    So-0 -> So-1

    Anschließend wird auf So-1 synchronisiert, der ja den Inhalt von vor vier Wochen gespeichert hat. Damit ist rsync auch innerhalb kurzer Zeit fertig.

    Zusätzlich wird jeder 1. im Monat separat auf einer zweiten externen 4TB-Platte gespeichert, die mit BTRFS formatiert ist. Dabei wird nur der 1. Januar als eigenes, unabhängiges Subvolume erstellt, alle anderen Monate sind BTRFS-Snapshots zum 1. des jeweiligen Vormonats hin, was sich auf eine vollständige Kopie und jeweils 11 aufeinander aufbauende inkrementelle Backups pro Jahr summiert. Der Speicherplatzbedarf pro Jahr beträgt dabei ca. 400 GB, so dass ich theoretisch erst im 10. Jahr löschen müsste, gleichbleibende Nutzung vorausgesetzt. Ein Offsite-Backup existiert derzeit nicht, und ist aktuell auch nicht in Planung. Theoretisch möglich wäre es, die Langzeit- und Rolling-Backupplatten per Raspi in einen anderen Raum zu versetzen, um hier zumindest eine teilweise Trennung zu erreichen.

    Aktuell existiert ein Projekt, die Windows-Rechner mit zwei Domänenkontrollern zu verwalten, die je 1,2 TB in einem RAID5 zur Verfügung stellen und wesentlich mehr Nutzerdaten speichern (d. h. die gesamten Home-Verzeichnisse, was aktuell nicht gemacht wird). Im weiteren Schritt wäre es möglich, auf dem Linux-Server in ein bis zweistündigem Abstand inkrementelle Backups der aktuellen Domäne zu sichern, was Infektionen mit Locky oder anderen Cryptotrojanern nochmal weniger Spielraum zur Schädigung bieten würde. In Aussicht ist ebenfalls, die derzeitigen Backup-Festplatten (die ja via USB am Server hängen) durch einen 24 TB RAID6-Fiberchannel-Storage zu ersetzen, aber das ist noch nicht spruchreif. Zumal da auch noch nicht sicher ist, ob ich den zumindest teilweise als Home-Partition an die AD-Server anbinde, weil ich schon vermute, dass die 1,2 TB auf Dauer etwas knapp werden könnten, auch wenn ich aggressiv Cache-Dateien weglösche.
    Geändert von Metal_Warrior (17.01.20 um 22:23 Uhr) Grund: RAID-Setups ergänzt, weil vergessen
    GCM/IT/S/O d-(--) s+:- a? C++(+++) UL+++(++++)$ P L+++>++++ W++ w@$ M--$ PS+(++) PE(-) Y+(++) PGP++(+++) t+ 5(+) R* !tv b+(++++) DI(++) G++ e+>++++ h(--) y?
    Das Ende ist nahe: Dem Harleyschen Kometen folgt der Gammablitz beim Scheißen.

  2. #2
    Zeitreisender

    Administrator

    Avatar von drfuture
    Registriert seit
    Jul 2013
    Ort
    in der Zukunft
    Beiträge
    6.699
    ngb:news Artikel
    17

    Re: Backupstrategie in mittelgroßer Einrichtung

    Hmm wenn sich die Daten so selten ändern - was hast du für einen Vorteil das quasie 3x zu sichern (Täglich, monatlicher Snapshot + Monatliche auf Btrfs)?
    Gerade zum zurücksichern / auswählen der passenden Version eventuell nicht ganz simpel?

    Mit einer Platte mehr (aktuelles Setup) könntest du eventuell ein RAID5 mit BTRFS erstellen und dort tägliche Snapshots erstellen - ebenfalls 10 jahre lang?
    Mit dem Vorteil direkt auf alle Versionen zugreifen zu können.

    @Ransomware - dabei ist darauf zu achten das mehr als genug Luft im Backup ist bzw. was passiert wenn das Zielverzeichnis voll läuft / das Backup hängen bleibt.
    Die Menge der Inkrementellen Daten steigt ja schlagartig an - und je nachdem wie viele Daten es sind und wie schnell verschlüsselt wird / ob, wann es jemand merkt könnte ich mir vorsellen das das auch mehrere Snapshots betrifft.
    |_|D *`~{ Ich kenne deine Zukunft }~´* |_|D

  3. #3
    Defender of Freedom

    Administrator

    (Threadstarter)

    Avatar von Metal_Warrior
    Registriert seit
    Aug 2013
    Ort
    /dev/mapper/home
    Beiträge
    5.887
    ngb:news Artikel
    7

    Re: Backupstrategie in mittelgroßer Einrichtung

    @drfuture: Ich hab mit der Hardware gearbeitet, die ich bekommen konnte. Und die war mager. Daher die Teilung. Zumal sich der Inhalt zwar selten ändert, aber es immer Leute gibt, die ganze Ordnerbäume ständig umbauen und damit Differenzen anlegen, die BTRFS nicht ganz so einfach mittracken kann. Das hab ich mit "Monatlich" dann etwas minimiert, weil die kurzfristigen Hin&Her-Änderungen dann zumindest wegfallen.
    Für diesen Beitrag bedankt sich drfuture
    GCM/IT/S/O d-(--) s+:- a? C++(+++) UL+++(++++)$ P L+++>++++ W++ w@$ M--$ PS+(++) PE(-) Y+(++) PGP++(+++) t+ 5(+) R* !tv b+(++++) DI(++) G++ e+>++++ h(--) y?
    Das Ende ist nahe: Dem Harleyschen Kometen folgt der Gammablitz beim Scheißen.

  4. #4
    Asoziale Ausbilderin Avatar von sia
    Registriert seit
    Mar 2015
    Ort
    FFM (NSFW)
    Beiträge
    5.825
    ngb:news Artikel
    4

    Re: Backupstrategie in mittelgroßer Einrichtung

    Warum verschlüsselst du die Backups nicht?

    Warum rsync und kein rsnapshot oder borg(matic)?
    *mit Linux wäre das natürlich nicht passiert™
    Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say. – Edward Snowden
    tilde.fun – dein kostenloser Linux-Account in der Cloud | Inoffizielle ngb-Telegram-Gruppe
    GCM/S/TW d s+:- a-----? C++$ UL+++$ P-- L+++ E---- W++++ !N ?K w- M-- !P[A-Z] Y++ PGP R* tv-- b++>++++ DI++\:\( G+ e+>++++ h*

  5. #5
    Defender of Freedom

    Administrator

    (Threadstarter)

    Avatar von Metal_Warrior
    Registriert seit
    Aug 2013
    Ort
    /dev/mapper/home
    Beiträge
    5.887
    ngb:news Artikel
    7

    Re: Backupstrategie in mittelgroßer Einrichtung

    @sia:

    1. Warum nicht verschlüsselt: Weil das auf LUKS-Devices liegt, und zwar alles.
    2. Warum nicht inkrementell mit $PROGRAMM: Weil es inkrementell auf Dateisystemebene ist. Die Wahrscheinlichkeit, dass $PROGRAMM Bullshit treibt ist höher als dass eines der größten Dateisysteme an dieser Stelle Bugs hat.
    Für diesen Beitrag bedankt sich sia
    GCM/IT/S/O d-(--) s+:- a? C++(+++) UL+++(++++)$ P L+++>++++ W++ w@$ M--$ PS+(++) PE(-) Y+(++) PGP++(+++) t+ 5(+) R* !tv b+(++++) DI(++) G++ e+>++++ h(--) y?
    Das Ende ist nahe: Dem Harleyschen Kometen folgt der Gammablitz beim Scheißen.

  6. #6
    Asoziale Ausbilderin Avatar von sia
    Registriert seit
    Mar 2015
    Ort
    FFM (NSFW)
    Beiträge
    5.825
    ngb:news Artikel
    4

    Re: Backupstrategie in mittelgroßer Einrichtung

    Sind die LUKS-Devices dauerhaft entschlüsselt? Kannst du mehr dazu sagen, warum du dich für btrfs entschieden hast? Das Dateisystem ist ja auch noch relativ neu.

    Wie deduplizierst du? Dauerhaft oder mit scrub/zusätzlichem Dedup-Programm?
    *mit Linux wäre das natürlich nicht passiert™
    Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say. – Edward Snowden
    tilde.fun – dein kostenloser Linux-Account in der Cloud | Inoffizielle ngb-Telegram-Gruppe
    GCM/S/TW d s+:- a-----? C++$ UL+++$ P-- L+++ E---- W++++ !N ?K w- M-- !P[A-Z] Y++ PGP R* tv-- b++>++++ DI++\:\( G+ e+>++++ h*

  7. #7
    Defender of Freedom

    Administrator

    (Threadstarter)

    Avatar von Metal_Warrior
    Registriert seit
    Aug 2013
    Ort
    /dev/mapper/home
    Beiträge
    5.887
    ngb:news Artikel
    7

    Re: Backupstrategie in mittelgroßer Einrichtung

    @sia: BTRFS ist zwar relativ neu, aber mittlerweile bei SLES 15 der OS-Standard (und ich glaub bei RHEL 7+ auch). Das ist mittlerweile also ausführlichst und auf breiter Front getestet. Zumal es sehr schnell geht - ein Subvolume mit Snapshot ist nach ner Sekunde fertig, danach muss ich nur noch die Differenzen mit rsync abgleichen, und das ist auch flott (<30 min). Für alle nachfolgenden Operationen ist es so, als hätte ich ein vollständiges Backup auf der Platte, ohne irgendwelche Hardlinks etc. Ich kann ganz normal über rsync oder cp zurück-restoren ohne auf irgendwas achten zu müssen.

    LUKS ist dauerhaft entschlüsselt, ja, das macht aber nix. Der Server bietet es nicht den Clients an, d. h. für einen Restore muss ein Linux-Admin an die Kiste ran, aber das ist selten.

    Duplikate suche ich nicht, die sind auch selten so groß, dass sie relevant werden. Mal ein oder zwei Word-Dokumente, mehr ist das nicht. Insofern irrelevant.
    Für diesen Beitrag bedankt sich sia
    GCM/IT/S/O d-(--) s+:- a? C++(+++) UL+++(++++)$ P L+++>++++ W++ w@$ M--$ PS+(++) PE(-) Y+(++) PGP++(+++) t+ 5(+) R* !tv b+(++++) DI(++) G++ e+>++++ h(--) y?
    Das Ende ist nahe: Dem Harleyschen Kometen folgt der Gammablitz beim Scheißen.

  8. #8
    Mitglied
    Registriert seit
    Jul 2013
    Ort
    /dev/null
    Beiträge
    2.749

    Re: Backupstrategie in mittelgroßer Einrichtung

    Zitat Zitat von sia Beitrag anzeigen
    Kannst du mehr dazu sagen, warum du dich für btrfs entschieden hast? Wie deduplizierst du?
    Die 2. Frage ist die Antwort auf die erste.

    BTRFS kann Snapshots anlegen. Unveränderte Dateien werden über Hardlinks adressiert. Damit hast du die Dedup-Funktion schon per Default eingebaut.

    Ich verwende BTRFS seit ca. 8-10 Jahren. Also eigentlich seit dem Zeitpunkt, als es keine Reiser4-Patches mehr gab. BTRFS hat mit Snapshots und Online-Kompression schon ein paar nette Features. Einen Datenverlust hatte ich bisher nicht.

    Die "Kontraargumente", sofern man sich daran stören will:


    Suse pflegt und patcht BTRFS ziemlich häufig und hat es auch zumindest bei SLES12 zum Defaultdateisystem auserkoren. Redhat hingegen hat BTRFS komplett rausgeschmissen und setzt stattdessen auf XFS. Grund dafür war, dass sie die hohe Patchfrequenz nicht mitgehen wollten, da das beim Backporting auf die alten Enterprise-Kernelversionen zuviel Aufwand bedeutete.

    Die Alternative zu BTRFS wäre noch ZFS on Linux. Da ZFS aber nicht im Kernel enhalten ist, benötigt man hier wieder extern installierte Module, was man bei einem Dateisystem eigentlich nicht will.
    Für diesen Beitrag bedankt sich sia
    Geändert von musv (19.05.20 um 08:30 Uhr)

  9. #9
    Asoziale Ausbilderin Avatar von sia
    Registriert seit
    Mar 2015
    Ort
    FFM (NSFW)
    Beiträge
    5.825
    ngb:news Artikel
    4

    Re: Backupstrategie in mittelgroßer Einrichtung

    @Metal_Warrior: Mich würden Details zur Implementierung interessieren, u.a. die verwendeten rsync-Scripte. Ich habe in der Vergangenheit versucht, rsnapshot in bash nachzubauen und als ich das gemerkt habe, hatte ich dann doch wieder rsnapshot genommen. Das hat auch mittlerweile ein recht geniales GUI.

    Zitat Zitat von musv Beitrag anzeigen
    Die 2. Frage ist die Antwort auf die erste.
    BTRFS kann Snapshots anlegen. Unveränderte Dateien werden über Hardlinks adressiert. Damit hast du die Dedup-Funktion schon per Default eingebaut.
    Ist das dann wirklich Deduplikation oder sind es einfach snapshots, die dann inkrementelle Backups erlauben?

    https://btrfs.wiki.kernel.org/index.php/Deduplication:
    Deduplication takes this a step further, by actively identifying when the same data has been written twice, and retrospectively combining them into an extent with the same copy-on-write semantics.
    […]
    Inband / synchronous / inline deduplication is deduplication done in the write path, so it happens as data is written to the filesystem. This typically requires large amounts of RAM to store the lookup table of known block hashes. Patches are currently being worked on and have been in development since at least 2014.
    Siehe auch: https://lwn.net/Articles/679031/

    Hat einer von euch irgendwo in-band deduplication aktiviert? Wenn ja, warum und wie viel RAM benötigt das für einen Backupserver der angegebenen Größe (300GiB Daten? 1.2TiB/24TiB)?
    Metal_Warrior meinte ja auch, es würde sich nicht lohnen, weil's in der Regel eher 2 gleiche Worddateien sind, deren Größe im Vergleich zum Aufwand vernachlässigbar ist.

    In meiner Erfahrung funktioniert die in-band deduplication noch nicht und ich nutze für Btrfs, wo ich es einsetze, in der Regel duperemove. Anderslautende Erfahrungsberichte fände ich aber äußerst spannend!
    *mit Linux wäre das natürlich nicht passiert™
    Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say. – Edward Snowden
    tilde.fun – dein kostenloser Linux-Account in der Cloud | Inoffizielle ngb-Telegram-Gruppe
    GCM/S/TW d s+:- a-----? C++$ UL+++$ P-- L+++ E---- W++++ !N ?K w- M-- !P[A-Z] Y++ PGP R* tv-- b++>++++ DI++\:\( G+ e+>++++ h*

  10. #10
    Zeitreisender

    Administrator

    Avatar von drfuture
    Registriert seit
    Jul 2013
    Ort
    in der Zukunft
    Beiträge
    6.699
    ngb:news Artikel
    17

    Re: Backupstrategie in mittelgroßer Einrichtung

    Zum Thema Deduplication:
    Das ist denke ich stark abhängig von den Daten die vorliegen.

    Bei uns in der Firma nutzt das Storage für die NFS-Shares Deduplication und spart damit wenn ich mich recht erinnere ~30% Platz ein.
    Das ist durchgängig von Betriebsdaten hin zu Backup-Daten.
    Die genauere Rate müsste ich sonst bei Interesse erfragen.

    Aber z.B. wenn von irgend einem Event Fotos im Intranet veröffentlicht werden und jeder 2. Mitarbeiter der Meinung ist diese "privat" in sein Privates Netzlaufwerk sichern zu müssen - dann liegen die Daten danach halt nur 1x im Netzwerk (Passiert wirklich häufiger und man kann am Storage wunderbar sehen wie die Belegung nach einem Ereignis zunimmt und danach wieder abnimmt wenn der DDub läuft.

    Das ist aber ne große Netapp ...
    |_|D *`~{ Ich kenne deine Zukunft }~´* |_|D

  11. #11
    Asoziale Ausbilderin Avatar von sia
    Registriert seit
    Mar 2015
    Ort
    FFM (NSFW)
    Beiträge
    5.825
    ngb:news Artikel
    4

    Re: Backupstrategie in mittelgroßer Einrichtung

    Zitat Zitat von drfuture Beitrag anzeigen
    Das ist aber ne große Netapp ...
    In Zahlen? 100TiB? 100PiB? 1EiB?
    *mit Linux wäre das natürlich nicht passiert™
    Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say. – Edward Snowden
    tilde.fun – dein kostenloser Linux-Account in der Cloud | Inoffizielle ngb-Telegram-Gruppe
    GCM/S/TW d s+:- a-----? C++$ UL+++$ P-- L+++ E---- W++++ !N ?K w- M-- !P[A-Z] Y++ PGP R* tv-- b++>++++ DI++\:\( G+ e+>++++ h*

  12. #12

    Re: Backupstrategie in mittelgroßer Einrichtung

    Zitat Zitat von sia Beitrag anzeigen
    [post=1044203]Ist das dann wirklich Deduplikation oder sind es einfach snapshots, die dann inkrementelle Backups erlauben?
    Snapshots brauchen keine Deduplikation. Sie belegen nämlich erst dann wirklich Platz, wenn Dateien geändert werden. Im Snapshot bleiben die "überschriebenen" Blöcke erhalten (Anführungszeichen, weil die Blöcke wegen COW [ist aber wohl abschaltbar] eh nicht überschrieben werden). Eine Deduplikation bringt da nichts, da eh nur geänderte Blöcke gespeichert werden. Mit Hardlinks ist das nur bedingt vergleichbar.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •