• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

Backupstrategie in mittelgroßer Einrichtung

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
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.
 
Zuletzt bearbeitet:

drfuture

Zeitreisender
Teammitglied

Registriert
14 Juli 2013
Beiträge
8.730
Ort
in der Zukunft
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.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
  • Thread Starter Thread Starter
  • #3
@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.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
  • Thread Starter Thread Starter
  • #5
@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.
 

sia

gesperrt

Registriert
26 März 2015
Beiträge
5.931
Ort
FFM (NSFW)
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?
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
  • Thread Starter Thread Starter
  • #7
@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.
 

musv

Bekannter NGBler

Registriert
15 Juli 2013
Beiträge
3.453
Ort
/dev/null
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:
  • Die miese Performance lt. Phoronix.
  • 2010 hatte Edvard Shishkin (2) mal BTRFS analysiert und bezeichnete BTRFS als broken by design. Gut 2010 ist lange her. Aber gewöhnlich ändert man bei einem Dateisystem nach der Finalisierung der Datenstruktur daran nichts mehr. Der Fehler könnte also noch immer drin sein. Und noch heute liest man über Probleme mit der Anzeige des freien Speichers.

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.
 
Zuletzt bearbeitet:

sia

gesperrt

Registriert
26 März 2015
Beiträge
5.931
Ort
FFM (NSFW)
@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.

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!
 

drfuture

Zeitreisender
Teammitglied

Registriert
14 Juli 2013
Beiträge
8.730
Ort
in der Zukunft
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 ...
 

sia

gesperrt

Registriert
26 März 2015
Beiträge
5.931
Ort
FFM (NSFW)
Snapshots brauchen keine Deduplikation.

Das war nicht die Frage.

Deduplikation und Snapshots sind zwei verschiedene paar Schuhe.

Wenn in einem einzelnen Dateisystembaum mehrere Kopien derselben Datei sind, kann man sie deduplizieren. Dann belegen die nur 1x Speicherplatz.

Bei Snapshots belegen die dann dennoch 3x Speicherplatz. Nur eben nicht beim nächsten Backup erneut.

Ich hoffe, mit dieser Erklärung ist klar, worauf meine Frage abgezielt hat.
 
Oben