Backup-Frage (kleines NAS)

[Midian]

Ich habe ein kleines NAS mit FreeBSD, und da mir scheinbar vor ein paar Tagen das Board abgeraucht ist, überlege ich ob ich das NAS direkt etwas aufwerte.
Hauptsächlich stelle ich mir gerade die Frage, wie ich meine Daten am besten sichern kann.

Ich habe momentan eine SSD als Bootplatte und 2 HDDs im Raid (Mirror) im Einsatz. Ein echtes Backup ist das natürlich nicht, und viele Daten habe ich auch nur auf dem NAS. Folgende Ideen hatte ich dazu bisher:
- kleines, billiges NAS mit 1 HDD kaufen, und per LAN automatisiert dorthin sichern (eventuell per wake on lan + abschalten nach dem backup)
- manuell per eSata Platte + Backup Script
- manuell auf optischem Medium (DVD, BD?)
- verschlüsseltes Archiv erstellen und online hochladen und archivieren (bei irgendeinem Hoster)

Was für Backupmechanismen habt ihr, bzw. was empfiehlt sich bei meinem doch eher gerigen Volumen? (die HDDs haben 2TB, sind aber nichtmal halbvoll. Und davon nochmal die Hälfte könnte ich auch problemlos nicht ins Backup nehmen, da weniger wichtig)

[Olodin]

Zitat von Midian

- manuell per eSata Platte + Backup Script

So mach ich das hier seit Jahren. Datenumfang ist ähnlich, via Skript sichere ich nur wichtiges (Familienfotos/-videos, Mails, Dokumente und sowas).
Vorteil gegenüber Sicherung via NAS+Netz: die Daten sind bei Entnahme der Platte aus dem eSATA Gehäuse/Adapter komplett offline, d.h. evlt. Blitzeinschlag kann die Platte nicht über Netz erreichen. Nachteil: Handarbeit.

Wichtig ist, dass man da auch die Daten rotiert und mehrere externe Platten nutzt.

[Midian]

Zitat von Olodin

So mach ich das hier seit Jahren. Datenumfang ist ähnlich, via Skript sichere ich nur wichtiges (Familienfotos/-videos, Mails, Dokumente und sowas).
Vorteil gegenüber Sicherung via NAS+Netz: die Daten sind bei Entnahme der Platte aus dem eSATA Gehäuse/Adapter komplett offline, d.h. evlt. Blitzeinschlag kann die Platte nicht über Netz erreichen. Nachteil: Handarbeit.

Wichtig ist, dass man da auch die Daten rotiert und mehrere externe Platten nutzt.

Die gleiche Idee hatte ich dabei auch. In dem Zusammenhang hab ich auch was von ZFS und Snapshots/inkrementelle Backups gelesen. Könnte man das mit der eSata-Version verbinden?

Außerdem eine Idee: Könnte man eventuell eine zeitgesteuerte Steckdose verwenden, an die man die eSata-Platte hängt, welche beim einschalten automatisch erkannt wird und das Backup-Script triggert?

[edit] http://breden.org.uk/2008/05/12/home...zfs-snapshots/

[Olodin]

Zitat von Midian

Die gleiche Idee hatte ich dabei auch. In dem Zusammenhang hab ich auch was von ZFS und Snapshots/inkrementelle Backups gelesen. Könnte man das mit der eSata-Version verbinden?

Warum nicht? Hab aber mit ZFS noch wenig Erfahrungen, hier ist noch UFS.

Außerdem eine Idee: Könnte man eventuell eine zeitgesteuerte Steckdose verwenden, an die man die eSata-Platte hängt, welche beim einschalten automatisch erkannt wird und das Backup-Script triggert?

Das geht mit devd oder automounter. Schau dazu auch mal hier rein: http://www.bsdforen.de/showthread.php?t=24501

[Yamagi]

Mit ZFS kann man problemlos inkrementelle Backups erstellen, siehe "zfs send" und "zfs receive". Ob man die sich ergebenden Streams kpomprimiert speichert oder sofort auf einem Dateisystem wieder einspielt, ist eine philosophische Frage. Ich tendiere zu letzterem, denn ein vollständiges, lesbares Dateisystem ist einfacher zu handhaben und gerade im Katastrophenfall angenehmer. Aber das ist ein komplexes Thema, was ja noch nicht ganz aktuell ist...

[Midian]

Zitat von Yamagi

Mit ZFS kann man problemlos inkrementelle Backups erstellen, siehe "zfs send" und "zfs receive". Ob man die sich ergebenden Streams kpomprimiert speichert oder sofort auf einem Dateisystem wieder einspielt, ist eine philosophische Frage. Ich tendiere zu letzterem, denn ein vollständiges, lesbares Dateisystem ist einfacher zu handhaben und gerade im Katastrophenfall angenehmer. Aber das ist ein komplexes Thema, was ja noch nicht ganz aktuell ist...

Das ist tatsächlich auch eine gute Idee (Backup auf dem zweiten Filesystem wiederherstellen). Das könnte man ja gut mit der eSata-Platte machen.

Lohnt denn ZFS überhaupt, wenn ich nur 2 HDDs habe (2x2TB), vorrausgesetzt ich hätte genug RAM (8GB)? Ich hab da auch ein neues Gehäuse im Visier, in das ich problemlos mehr Platten packen könnte bei Bedarf. Wie leicht könnte ich ZFS da eigentlich erweitern? (Sorry, bin totaler ZFS Anfänger)

[h^2]

Also vorweg: Alles bloss kein Backup auf optische Medien. Da kann man gleich nach /dev/null sichern.

Zitat von Midian

Das ist tatsächlich auch eine gute Idee (Backup auf dem zweiten Filesystem wiederherstellen). Das könnte man ja gut mit der eSata-Platte machen.

Ist das performanteste, aber du musst dir ueberlegen ob sie permanent dran haengt (dann kannst du sie auch reintun). Hat den vorteil, dass du per cron sichern kannst. Hat den Nachteil, dass es im selben Gehaeuse ist, vlt auch vom Blitz getroffen wird oder vom Kaninchen angefressen, was die Hauptplatten gerade futtert etc.
Selber anschliessen hat den Vorteil der erhoehten Lebenszeit, und man kann die Platte zwischen den Backups in einem anderen Raum, vlt sogar im Safe aufbewahren.

Lohnt denn ZFS überhaupt, wenn ich nur 2 HDDs habe (2x2TB), vorrausgesetzt ich hätte genug RAM (8GB)?

Ja.

Ich hab da auch ein neues Gehäuse im Visier, in das ich problemlos mehr Platten packen könnte bei Bedarf. Wie leicht könnte ich ZFS da eigentlich erweitern?

garnicht einfach. Siehe dazu andere Threads hier im Forum.

[Yamagi]

Ich werde hier ja immer gern so zitiert, dass man ZFS nicht braucht, wenn man fragt ob ZFS für einen sinnvoll ist. Allerdings hat sich FreeBSD in Sachen ZFS deutlich weiterentwickelt, spätestens mit 8.3 bzw. 9.0 ist ZFSv28 sehr schnell, zuverlässig und schon lange keine solche Ressourcensau mehr, wir noch zum Anfang. Es krallt sich zwar gern viel RAM, gibt ihm aber auch schnell wieder frei, wenn andere Parteien Bedarf anmelden. Insgesamt überwiegen die Vorteile von ZFS in meinen Augen immer, sofern man die notwendigen Ressourcen hat. Selbst, wenn man die Myriade fortgeschrittener Funktionen nicht nutzt. Daher sollte man die Aussage in "Nutze ZFS, solange du keinen trivtigen Grund dagegen hast" ändern.

Zitat von h^2

garnicht einfach. Siehe dazu andere Threads hier im Forum.

Hm? Man kann zwar einzelne vdev nicht vergrößern, mann kann allerdings weitere vdev in den Pool hängen...

[Bummibaer]

"Nutze ZFS, solange du keinen trivtigen Grund dagegen hast" kann ich bärig so ned unterschreiben. Es ist sinnbefreit ZFS zu nutzen wenn man z.B. weder weiss was es tut noch wie und schon der Pool falsch angelegt ist und/oder die Datasets total schwachsinnig erzeugt wurden - z.B. mit garkeinen oder den völlig falschen Options für den jeweiligen Verwendungszweck.

Man sollte grundsätzlich eher das einsetzen was sich in der Praxis bewährt hat und was man im Griff hat. Sofern man ZFS im Griff hat ist es, die entsprechenden technischen Voraussetzungen als gegeben angenommen, sicherlich aktuell sinnvoller ZFS statt UFS einzusetzen (bezogen auf 8.3 bzw. 9.0 mit entsprechender Hardware und Konfiguration).

Backup auf externe Ziele ist btw immer eine sehr gute Idee, sofern die Ziele auch ausreichend sicher und verlässlich sind. eSATA hat sich für kleinere Backups mit externen Platten oft bewährt. Für größere Datenbestände bieten sich Tape Library Systeme bärig fein an - vorzugsweise mit Autoloader und Barcode System. Für regelmäßige Sicherungen mit sehr großen Datenmengen bieten sich externe Zwischenspeicher auf Basis von Software / Hardware Raid Systemen an. Als "Endziel" dann die Tape Library bärig fein.

Gruß Bummibär

[Yamagi]

Zitat von Bummibaer

"Nutze ZFS, solange du keinen trivtigen Grund dagegen hast" kann ich bärig so ned unterschreiben. Es ist sinnbefreit ZFS zu nutzen wenn man z.B. weder weiss was es tut noch wie und schon der Pool falsch angelegt ist und/oder die Datasets total schwachsinnig erzeugt wurden - z.B. mit garkeinen oder den völlig falschen Options für den jeweiligen Verwendungszweck.

Nun ja, das stimmt natürlich. Aber andererseits ging ich einfach davon aus, dass ein Nutzer, der ein System wie FreeBSD nutzen möchte, auch bereit ist sich in die Materie einzulesen und sie zu verstehen. Wenn man ZFS einfach nur als Dateisystem nutzen möchte, ist ein "zpool create" kaum komplizierter als "newfs". Und für ZFS spricht sicherlich sehr, dass man praktisch umsonst Dinge wie integrierte Konsistenzprüfung und sehr effiziente Snapshots (die Basis vieler Online-Backup-Lösungen) erhält.

[Kamikaze]

Zitat von Yamagi

Nun ja, das stimmt natürlich. Aber andererseits ging ich einfach davon aus, dass ein Nutzer, der ein System wie FreeBSD nutzen möchte, auch bereit ist sich in die Materie einzulesen und sie zu verstehen. ...

Zumindest auf mich trifft das nicht zu.

[Midian]

Zitat von Yamagi

Nun ja, das stimmt natürlich. Aber andererseits ging ich einfach davon aus, dass ein Nutzer, der ein System wie FreeBSD nutzen möchte, auch bereit ist sich in die Materie einzulesen und sie zu verstehen. Wenn man ZFS einfach nur als Dateisystem nutzen möchte, ist ein "zpool create" kaum komplizierter als "newfs". Und für ZFS spricht sicherlich sehr, dass man praktisch umsonst Dinge wie integrierte Konsistenzprüfung und sehr effiziente Snapshots (die Basis vieler Online-Backup-Lösungen) erhält.

Da ich niemand bin, der tagtäglich mit FreeBSD Kontakt hat, beschränken sich mein Wissen und meine Erfahrung damit (leider) auf alle paar Jahre Server aufsetzen und ab dann nur noch benutzen
Nichtsdestotrotz lese ich mich immer gerne in die Materie ein, nicht zuletzt auch weil ich mich einfach für das Betriebssystem sowie die Technik interessiere. Dennoch stehe ich bei ZFS noch ganz am Anfang, aber das lässt sich sicherlich ändern

Da wir gerade beim Thema Anfänger sind: Da meine FreeBSD-Root Platte ja den Geist aufgegeben hat, habe ich jetzt nur noch meine 2 Datenplatten die in einem gmirror verbunden sind.
Kann ich den mirror einfach wieder einbinden, sobald ich das System neu aufgesetzt habe? Oder kann ich eventuell irgendwie einfach den Raid "deaktivieren", so dass ich eine der Platten an einen anderen PC hängen kann, um a) zu schauen ob sie noch funktioniert und b) Daten kopieren kann?

[Yamagi]

Zu ZFS:
Der große Vorteil von ZFS liegt darin, dass man diverse Dinge "umsonst" integriert hat, die man mit anderen Dateisystemen erst aufwändig und oftmals auch teuer im Sinne des Ressourcenverbrauchs nachrüsten muss. Wie ich schon oben schrieb, sind da vor allem die integrierte Konsistenzprüfung und im Falles von Redundanzen auch Fehlerkorrektur zu nennen. Wirklich interessant wird ZFS aber erst, wenn man die "höheren" Funktionen nutzen möchte. Zum Beispiel das integrierte Backup-System oder die Möglichkeit Dateisysteme im Sekunden zu klonen. Der Nachteil an ZFS ist allerdings, dass es sich doch recht deutlich von klassischen Dateisystemen unterscheidet und man das Konzept aus Pool (Storagemanager) und Dataset (Dateisystem) erst einmal begreifen muss. In fast allen Fällen ist es den Aufwand von maximal einigen Stunden aber wert. Wenn man vorhandene Daten hat, will die Migration auf ZFS jedoch gut vorbereitet sein, denn man muss alle Daten mindestens einmal umkopieren.

Zu gmirror:
Gmirrors sind nicht an ein System gebunden und die Metadaten sind am Ende der Festplatte gespeichert. Daher kannst du die Platten einfach ins neues System hängen und es funktioniert. Hängst du nur eine Platte ein, kannst du sie wie eine ganze normale einzelne Festplatte nutzen.

[Midian]

Zitat von Yamagi

Zu ZFS:
Der große Vorteil von ZFS liegt darin, dass man diverse Dinge "umsonst" integriert hat, die man mit anderen Dateisystemen erst aufwändig und oftmals auch teuer im Sinne des Ressourcenverbrauchs nachrüsten muss. Wie ich schon oben schrieb, sind da vor allem die integrierte Konsistenzprüfung und im Falles von Redundanzen auch Fehlerkorrektur zu nennen. Wirklich interessant wird ZFS aber erst, wenn man die "höheren" Funktionen nutzen möchte. Zum Beispiel das integrierte Backup-System oder die Möglichkeit Dateisysteme im Sekunden zu klonen. Der Nachteil an ZFS ist allerdings, dass es sich doch recht deutlich von klassischen Dateisystemen unterscheidet und man das Konzept aus Pool (Storagemanager) und Dataset (Dateisystem) erst einmal begreifen muss. In fast allen Fällen ist es den Aufwand von maximal einigen Stunden aber wert. Wenn man vorhandene Daten hat, will die Migration auf ZFS jedoch gut vorbereitet sein, denn man muss alle Daten mindestens einmal umkopieren.

Wie ist das eigentlich mit den ZFS Snapshots. Wenn ich auf diese Weise automatisierte (und inkrementelle) Backups realisieren möchte, füllt das nicht mit der Zeit die Platte auf? Mein Verständnis ist, dass bei Anlage eines Snapshots alle folgenden Writes (= nur Änderungen) an eine neue Position auf der Platte geschrieben werden, somit also mehr Speicherplatz belegt ist als zuvor.

Zu gmirror:
Gmirrors sind nicht an ein System gebunden und die Metadaten sind am Ende der Festplatte gespeichert. Daher kannst du die Platten einfach ins neues System hängen und es funktioniert. Hängst du nur eine Platte ein, kannst du sie wie eine ganze normale einzelne Festplatte nutzen.

Hach, ich bin entzückt

[Crest]

Beim Anlegen eines Snapshots werden die Daten, die der Snapshot abdeckt, nicht mehr frei gebe bis der Snapshot zerstört wird. Die ab der Entstehung des Snapshots anfallenden Änderungen benötigen natürlich ebenfalls ihren Platz im Pool.