Eigenbau NAS mit Dedup

Mete888

Semiprofi
Thread Starter
Mitglied seit
05.01.2007
Beiträge
1.853
Ort
Zürich, Schweiz
Hallo zusammen

Wie würdet Ihr das anstellen, ich möchte gerne ein NAS mit Deduplizierung zusammenbauen.
Hardware:
Asus Board
i7 2600 4x3.4GHz
32GB DDR3 RAM
LSI 9265-8i mit 8x 3TB HDD @ RAID6

Betriebssystem:
Am liebsten Debian 7 x64

Der Speicher soll auf verschiedene Arten zur verfgügung gestellt werden können (jeweils teile davon, wie z.B. bei den Synologys):
iSCSI
SMB
FTP
rSync

Lässt sich ja relativ simpel mit Linux realisieren, nur, wie lässt sich die Deduplizierung am besten bewerkstelligen? Kenne dies nur von "ready to use" Enterprise Lösungen.

Über konstruktive Beiträge würde ich mich sehr freuen.

Gruss Mete
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
wozu der Aufwand im heimbereich

LSI 9265-8i hat Raid 6 .... mehr wirste nicht brauchen

Asus Board
i7 2600 4x3.4GHz
deuten auf homeserver

Deduplizierungs-Lösungen zielen darauf ab, Daten nur einmal auf das Speichermedium zu bringen und bereits gespeicherte, redundante Informationen vom Backup-Prozess auszuschließen beziehungsweise zu indizieren.
 
Zuletzt bearbeitet:
Ich glaube nicht, dass du im Heimbereich Vorteile durch Dedup haben wirst. Welcher Art sind denn die Daten, die auf dem NAS gespeichert werden sollen?
Weiterhin ist die CPU gnadenlos überdimmensioniert.
Versuche dich etwas in ZFS --> Sammeltread einzulesen. Gerade eine sinnvolle Hardwareausstatung bei Dedup Nutzung ist nicht ganz einfach. Hier brauchst du schnelle SSD's als Cache und solche Sachen.
Ob du im Anschluss ZFS mit Linux oder auf BSD oder auf Solaris und Consorten einsetzt, ist dann 'fast' zweitrangig.
 
Zuletzt bearbeitet:
Zudem sind 32 GB für dedublication etwas wenig. Vor allem bei der Menge an Daten.

Dedub wird sicherlich was bringen, wenn du 15 VMs mit gleichem OS hast. Bei Office-Daten oder Medien ist die Ersparnis an Speicherplatz gegen Null.
 
Bei Freenas stehen einige Infos bezüglich ZFS, RAM und dedup.

Hardware Recommendations - Freenas

If you plan to use ZFS deduplication, a general rule of thumb is 5 GB RAM per TB of storage to be deduplicated. Note that there is no upper limit to how much RAM you may need for deduplication. If you do not have enough RAM you may not be able to mount your pool on bootup. In this case, the only solution is to install more RAM or restore from backup. Very few users will find deduplication provides space savings over using compression.
 
Zuletzt bearbeitet:
Guten Morgen

Danke erstmals für die Antworten.

Ich sollte einige Systeme Backupen, und ich denke, da werden wohl 20TB an Space kaum ausreichen... deshalb auch die Anfrage betreffend Dedup... Ich werde mich mal im ZFS Thread bisschen umsehen. Wenn 32GB RAM nicht reichen sollten, so wird es halt ein Xeon Prozessor und 128 bzw. 256GB RAM... so einfach ist das :)

Gruss Mete
 
Das hört sich nicht unbedingt mehr privat an. Aber besser das du da bereit bist, die Hardware 'ne Nummer größer zu planen. Ist ja nicht Usus hier ;-)
 
Guten Morgen

Danke erstmals für die Antworten.

Ich sollte einige Systeme Backupen, und ich denke, da werden wohl 20TB an Space kaum ausreichen... deshalb auch die Anfrage betreffend Dedup... Ich werde mich mal im ZFS Thread bisschen umsehen. Wenn 32GB RAM nicht reichen sollten, so wird es halt ein Xeon Prozessor und 128 bzw. 256GB RAM... so einfach ist das :)

Gruss Mete

Wie viele Daten willst du denn tatsächlich sichern?
Durch die ZFS Snapshot Funktion und die Kompression lässt sich bei täglichen Backups (bpsw. mit Rsync) schon wahnsinnig viel Speicher sparen.
Klar kann Dedup da noch einiges rausholen, allerdings steht der Aufwand dafür häufig in keinem sinnvollen Verhältnis.
 
Wie viele Daten willst du denn tatsächlich sichern?
Durch die ZFS Snapshot Funktion und die Kompression lässt sich bei täglichen Backups (bpsw. mit Rsync) schon wahnsinnig viel Speicher sparen.
Klar kann Dedup da noch einiges rausholen, allerdings steht der Aufwand dafür häufig in keinem sinnvollen Verhältnis.

Moin

10TB gibt es ca. zu sichern...

5 Daily Backups (Incremental)
4 Weekly Backups (Full)
12 Monthly Backups (Full)
10 Yearly Backups (Full)

Gruss Mete
 
Die Vorgehensweise bei ZFS ist ja folgende:

- Daten werden per zfs send (Replication) oder rsync bzw robocopy (Filebasiert) zwischen
einem Quellsystem und einem Backupsystem syncronisiert.

Davon macht man dann Snapshots. In diesen Snapshots verbrauchen nur geänderte Daten Platz.
Je nach Snapshot-Historie hat man dann Lesezugriff auf den Datenstand (letzte Woche, letztes Jahr, 1.10. 2012: 10:00 Uhr etc)
am Einfachsten über Windows - Vorherige Version.

Man macht also keine 4 Weekly Full Backups mit 4 Kopien sondern Snapshots.
Diese benötigen bei nichtveränderten Daten gar keinen Platz. Vier Duplikate Anlegen ist nicht sinnvoll.

Verringern kann man den Platz ohne Probleme zudem mit Kompression, am Besten LZ4.


Deduplikation ist bei diesem Vorgehen nicht hilfreich, da die damit erzielbaren Dedupraten
minimal sind. Besser also noch eine zwei Platten mehr einplanen.
 
Moin

10TB gibt es ca. zu sichern...

5 Daily Backups (Incremental)
4 Weekly Backups (Full)
12 Monthly Backups (Full)
10 Yearly Backups (Full)

Gruss Mete

Die Vollbackups kannst du dir bei ZFS sparen.
Die Fragen lauten bei einem solchen Konzept:

1) Wie viel Daten gibt es aktuell.
2) Wie viel ändert sich jeden Tag.
3) Wie komprimierbar sind diese Daten.
 
BTRFS soll bald(TM) zumindest offline [Edit: out-of-band, also schon mit eingehängtem Dateisystem aber nicht während des Schreibens] dedup können, gilt aber generell immer noch als experimentell.

ZFS traue ich seit dem Verkauf an Oracle nicht über den Weg, aber an next-gen Dateisystemen hapert's ohnehin generell.
 
Zuletzt bearbeitet:
Also aktuell gibt es ca. 9TB Daten, ändern tun sich ca. 10GB am Tag an Files mit einer Gesamtgrösse von ca. 500GB.
Die Daten sind sehr schlecht komprimierbar (eventuell 10%).

Gruss Mete
 
Also aktuell gibt es ca. 9TB Daten, ändern tun sich ca. 10GB am Tag an Files mit einer Gesamtgrösse von ca. 500GB.
Die Daten sind sehr schlecht komprimierbar (eventuell 10%).

Gruss Mete

Ich würde es an deiner Stelle mit 8x4 TB im Raid Z2 versuchen und die Platten einfach gegen größere durchtauschen, wenn dir irgendwann der Speicher ausgeht.
Die Alternative wäre mit mindestens 128 GB Ram und Dedup zu arbeiten.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh