XigmaNAS

Hallo zusammen,

ich verwende den DeltaCopy-Client auf Windows-PCs um Verzeichnisse bzw. Dateien auf das NAS zu sichern. Dabei trat das Problem auf, dass Umlaute in Verzeichnis- und Dateiennamen von DeltaCopy durch "_" ersetzt wurden.
Ursache dafür ist, dass DeltaCopy mit einem unpassenden Charset arbeitet. Die Lösung dieses Problems ist einfach: Die Dateil cygwin1.dll muss durch http://www.oki-osk.jp/esc/utf8-cygwin/c ... 18.tar.bz2 ersetzt werden.

Die genaue Beschreibung des Problems und deren Lösung kann hier http://www.oki-osk.jp/esc/utf8-cygwin/ nachgelesen werden.

Noch besser ist es natürlich, auf Umlaute in Verzeichnissen und Dateinamen zu verzichten.

Grüsse

Ralf

Guter Tipp!

Ein Hinweis in eigener Sache
Du verwendest rsync/cygwin um eine Art Datensicherung auf dem NAS zu machen.
Backup-Techniken sind mittlerweile eine Art Hobby von mir geworden
Für per Ethernet verkabelte PCs (also nicht WLAN), habe ich eine Lösung gebastelt, die mir meine PCs mit ihren verschiedenen Betriebssystemen (Windows, Linux und andere) auf das NAS sichert.
Dabei nutze ich die Vorteile des ZFS-Dateisystems, und die Möglichkeiten von Freetz auf der Fritz!Box.
Ganz unbescheiden kann ich sagen, daß die Lösung sehr sicher, zuverlässig, effektiv und schnell ist. Auf den zu sichernden PCs muß keine Software installiert werden. Man kann Image-Backups, File-by-File-Backups und Mischformen davon einrichten. Das ganze wird mit Standard-Tools und ein paar Scripten realisiert.
Und: Ja, es ist möglich, einen PC komplett aus der Sicherung wieder herzustellen (selbst wenn die Festplatte komplett "ausgenullt" wurde). Das funktioniert sogar mit Systemen, welche sich im Hybernate-Modus befinden.

Warum schreibe ich das? Bei mir funktioniert das seit Jahren prima, und ich suche Leute, die das auch mal ausprobieren wollen, damit ich das System ggfs. weiter entwickeln kann.
Falls dich das interessiert, dann sag einfach bescheid.

Grüße
Princo

Hallo Princo,

momentan nutze ich die aus meiner (Anfänger-) Sicht komfortable und unkomplizierte Möglichkeit, bestimmte Partitionen/Verzeichnisse oder auch nur Dateien von Notebooks per DeltaCopy/rsync mit dem NAS zu synchronisieren. Sprich auf den Notebooks neu erstellte bzw. geänderte Dateien automatisierte auf das NAS zu übertragen.

Das eigentliche (Image-) Backup der Notebooks erfolgt mittels TrueImage. Die von TrueImage erstellten Images werden auf dem NAS abgelegt. Zusätzlich ist für jedes Notebook eine 2,5-Zoll-Festplatte im externen USB-Gehäuse vorhanden, auf die einmal im Monat die im Notebook verbaute Festplatte geklont wird. So kann bei einem Defekt der Notebook-Festplatte schnell weitergearbeitet werden. Die aktuellen Daten sind ja auf dem NAS vorhanden.

Wie sieht Deine Lösung aus? Sie hört sich auf jeden Fall sehr interessant an, besonders die Möglichkeit der Wiederherstellung wenn z. B. eine neue Festplatte eingebaut wurde. Ich frage mich welche Rolle Freetz dabei spielt. Ist die Einrichtung kompliziert oder auch nicht so bewanderten möglich?

Bin gespannt!

Gruß

Ralf

Princo wrote:Für per Ethernet verkabelte PCs (also nicht WLAN), habe ich eine Lösung gebastelt, die mir meine PCs mit ihren verschiedenen Betriebssystemen (Windows, Linux und andere) auf das NAS sichert. [...]
Warum schreibe ich das? Bei mir funktioniert das seit Jahren prima, und ich suche Leute, die das auch mal ausprobieren wollen, damit ich das System ggfs. weiter entwickeln kann. Falls dich das interessiert, dann sag einfach bescheid.

raaalf wrote:momentan nutze ich die aus meiner (Anfänger-) Sicht komfortable und unkomplizierte Möglichkeit, bestimmte Partitionen/Verzeichnisse oder auch nur Dateien von Notebooks per DeltaCopy/rsync mit dem NAS zu synchronisieren. Sprich auf den Notebooks neu erstellte bzw. geänderte Dateien automatisierte auf das NAS zu übertragen.

Das ist schon mal ganz gut. Allerdings verzichten die meisten Anwender dabei oft auf die Überprüfung der Dateien. rsync überträgt in der Standardeinstellung nur Dateien, deren Datum und Größe verändert wurden. Es gibt aber Anwendungen, deren Dateien sich inhaltlich ändern, ohne daß sich das Dateidatum, oder die Größe ändert. Das ist z.B. bei früheren Versionen von Truecrypt der Fall gewesen, betrifft aber auch manche Bildbearbeitungsprogramme.

raaalf wrote:Das eigentliche (Image-) Backup der Notebooks erfolgt mittels TrueImage. Die von TrueImage erstellten Images werden auf dem NAS abgelegt. Zusätzlich ist für jedes Notebook eine 2,5-Zoll-Festplatte im externen USB-Gehäuse vorhanden, auf die einmal im Monat die im Notebook verbaute Festplatte geklont wird. So kann bei einem Defekt der Notebook-Festplatte schnell weitergearbeitet werden. Die aktuellen Daten sind ja auf dem NAS vorhanden.

Das ist eine sehr gute Lösung. Allerdings braucht man für jeden Laptop immer eine eigene Duplikat-Festplatte. Wenn man viel unterwegs ist (also keine Verbindung zum NAS hat), dann ist das optimal.

raaalf wrote:Wie sieht Deine Lösung aus? Sie hört sich auf jeden Fall sehr interessant an, besonders die Möglichkeit der Wiederherstellung wenn z. B. eine neue Festplatte eingebaut wurde.

Hmm, da muß ich etwas ausholen.
Um 2007 bin ich auf Linux gewechselt. Einer der Gründe dafür war, daß man Windows nur recht umständlich backuppen konnte. Zu der Zeit wurden auch externe Festplatten billig, und ich habe mich etwas intensiver mit den Thema "Backup" beschäftigt.
Dabei bin ich auf das System-Rescue-CD-Projekt aufmerksam geworden.
Das ist nicht nur eine extrem mächtige Tool-Sammlung rund um das Thema Datenrettung, sondern auch ideal für Backups geeignet, da man es mit sog. Autorun-Dateien automatisieren kann. Eine weitere Besonderheit ist, daß man diese Funktionen entweder per Boot-CD, Boot-USB-Stick, PXE-Boot, oder per Parallel-Installation auf der lokalen Festplatte umsetzen kann.
Zuerst habe ich mir einen Backup-USB-Stick erzeugt, mit dem ich automatisiert Backups auf einer externen Festplatte angelegt habe.
Das war dann aber insofern doof, weil man mit einer externen Festplatte und einem USB-Stick hantieren mußte (Jammern auf hohem Niveau).
Ich wollte aber von den ganzen externe Platten weg, und auch nicht mehr USB-Sticks einstöpseln müssen, weil das unbequem ist (was dazu führt, daß man das Backup nicht regelmäßig macht).
Außerdem brauchte jede Maschine ihren eigenen USB-Stick, was auch nicht so prickelnd war.
Der derzeitige Stand ist, daß beim Booten per PXE ein zusätzliches Menü eingeblendet wird. Dort kann man diverse System-Tools auswählen, und auch die verschiedenen Backup/Restore Aktionen durchführen.

Was ist jetzt die Besonderheit zu anderen Backup-Tools?
Ich verwende Standard-Linux-Programme um Boot-Loader, Partitionstabellen und Datenbereiche zu sichern.
Wie ich hinterher herausgefunden habe, macht das Clonezilla-Projekt das auf fast identische Art.

Den Unterschied zwischen File-by-file-Backup und Image-Backup brauche ich dir wohl nicht erklären. Eine Kombination davon verwende ich auch bei meinem System.
Der eigentliche Knaller dabei ist aber, daß die Image-Backups in NAS4Free direkt mountbar sind!
Es ist also überhaupt kein Problem, sich irgendwelche Dateien aus dem tiefsten Windows-System-Bereich einzeln zurück zu holen.
Das geht ganz einfach per Windows-Freigabe auf dem NAS.
Der tiefere Sinn dahinter ist, daß ein normales Restore bei Windows gar nicht möglich ist, wenn sich die Hardware geändert hat (z.B. neuer Laptop). Mit dieser Methode verliert das seinen Schrecken.

raaalf wrote:Ich frage mich welche Rolle Freetz dabei spielt.

Mit Freetz kann man einen PXE-Server in Verbindung mit den NAS betreiben. Die Einrichtung ist simpel, der Nutzwert ist extrem hoch.

raaalf wrote:Ist die Einrichtung kompliziert oder auch nicht so bewanderten möglich?

Was soll man denn darauf antworten

Spaß beiseite. Man muß dafür so einige zusätzliche Dienste auf dem NAS aktivieren (z.B. tftp, nfs, rsync, www), dann muß man über die Kommandozeile des NAS eine Reihe von Datasets und Unterdatasets einrichten, und für die Konfiguration jeder einzelnen Maschine muß man einige Dateien per Hand anpassen.

Letztendlich muß man unter Linux nur zwei Befehle absetzen, damit man die nötige Grundkonfiguration einrichten kann.

Bei diesem Projekt gibt es eine ganze Reihe von Detaillösungen, deren Erklärung den Rahmen hier sprengen würde,
Das Wichtigste dabei; Es war mir ein besonderes Anliegen, daß das Backup keine lästige Pflicht ist, sondern ganz im Gegenteil als ein recht cooles Ereignis wahrgenommen wird. Man kann direkt sehen, welche Dateien übertragen werden, und wie lange das jeweils dauert.
Es gibt hier keinen nichtssagenden Ladebalken, sondern man sieht direkt, was im System passiert.
Richtig verstehen wird man das allerdings erst, wenn man es täglich nutzt.

Die Konfiguration ist auf jeden Fall einfacher, als ein VPN einzurichten

Eine chique (und idiotensichere) Oberfläche gibt es (noch) nicht dafür. Für mich alleine lohnt sich das auch nicht. Daher suche ich ja auch so verzweifelt nach weiteren Testern, da ich weitere Anregungen brauche.

Grüße
Princo

Guten Abend Princo,

die Hinterlassenschaften von "Niklas" - in erster Linie umgeknickte Bäume die Gottseidank keine Schäden verursachten - sind beseitigt. Jetzt ist wieder Zeit sich mit dem Thema NAS zu befassen.

Princo wrote:Allerdings verzichten die meisten Anwender dabei oft auf die Überprüfung der Dateien.

Du meinst die rsync-Option "-c"? Die ist bei bei den rsync-Clienten, sei es NAS4Free selbst oder DeltaCopy, gesetzt. Zusätzlich bei DeltaCopy noch "--progress". Die Synchronisierung dauert dadurch allerdings erheblich länger.

princo wrote:

raaalf wrote:Notebook-Festplatte auf externe USB-Festplatte klonen

Das ist eine sehr gute Lösung.

Danke!

princo wrote:Den Unterschied zwischen File-by-file-Backup und Image-Backup brauche ich dir wohl nicht erklären. Eine Kombination davon verwende ich auch bei meinem System.
Der eigentliche Knaller dabei ist aber, daß die Image-Backups in NAS4Free direkt mountbar sind!
Es ist also überhaupt kein Problem, sich irgendwelche Dateien aus dem tiefsten Windows-System-Bereich einzeln zurück zu holen.
Das geht ganz einfach per Windows-Freigabe auf dem NAS.
Der tiefere Sinn dahinter ist, daß ein normales Restore bei Windows gar nicht möglich ist, wenn sich die Hardware geändert hat (z.B. neuer Laptop). Mit dieser Methode verliert das seinen Schrecken.

Das klingt verdammt gut!

princo wrote:

raaalf wrote:Ich frage mich welche Rolle Freetz dabei spielt.

Mit Freetz kann man einen PXE-Server in Verbindung mit den NAS betreiben. Die Einrichtung ist simpel, der Nutzwert ist extrem hoch.

Dass heisst, ich kann z. B. nach dem Austausch einer Festplatte den PC einfach mit Hilfe des PXE-Servers per LAN booten und einen Restore anstossen?

princo wrote:Spaß beiseite. Man muß dafür so einige zusätzliche Dienste auf dem NAS aktivieren (z.B. tftp, nfs, rsync, www), dann muß man über die Kommandozeile des NAS eine Reihe von Datasets und Unterdatasets einrichten, und für die Konfiguration jeder einzelnen Maschine muß man einige Dateien per Hand anpassen.
Eine chique (und idiotensichere) Oberfläche gibt es (noch) nicht dafür. Für mich alleine lohnt sich das auch nicht. Daher suche ich ja auch so verzweifelt nach weiteren Testern, da ich weitere Anregungen brauche.

Kurz und knapp: Wann geht es los? Wie geht es los? Ich denke, zuerst muss das Freetz-Image mit dem Paket "dnsmasq" erstellt werden. dnsmasq enthält unter anderem einen TFTP-Server der, wenn ich das mit PXE und TFTP richtig verstanden habe, notwendig ist um per PXE booten zu können. Das sollte mir möglich sein.

Gruß

Ralf

raaalf wrote:Du meinst die rsync-Option "-c"? Die ist bei bei den rsync-Clienten, sei es NAS4Free selbst oder DeltaCopy, gesetzt. Zusätzlich bei DeltaCopy noch "--progress". Die Synchronisierung dauert dadurch allerdings erheblich länger.

Bei den File-by-File-Backups mache ich deswegen zwei Durchgänge: einen ohne -c, und einen mit -c.
Zu Beginn kann man auswählen, ob beide Durchläufe stattfinden sollen, oder nur der schnellere. Damit kann man quasi ein Turbo-Backup durchführen, falls gerade ein Unwetter/Hochwasser oder die Apokalypse im Anmarsch ist

raaalf wrote:Dass heisst, ich kann z. B. nach dem Austausch einer Festplatte den PC einfach mit Hilfe des PXE-Servers per LAN booten und einen Restore anstossen?

Ja, genau das bedeutet es.
Man kann aber noch viel mehr damit machen. Ich habe damit auch ein paar LIVE-Versionen diverser Linux-Distributionen eingebunden. So kann man auf jeden Rechner einfach Linux ausprobieren, ohne daß man mit CDs und USB-Sticks arbeiten muß.
Man kann sogar komplette Diskless-Workstations damit einrichten, wenn man möchte. Bei Openelec geht das sogar ganz besonders einfach.

raaalf wrote:Ich denke, zuerst muss das Freetz-Image mit dem Paket "dnsmasq" erstellt werden. dnsmasq enthält unter anderem einen TFTP-Server der, wenn ich das mit PXE und TFTP richtig verstanden habe, notwendig ist um per PXE booten zu können. Das sollte mir möglich sein.

Den TFTP-Server von dnsmasq auf der Fritz!Box nutze ich nicht, sondern den von NAS4Free. Der Grund dafür ist, daß im Bereich des TFTP-Servers die ganzen Konfigurationsdateien für das Backup liegen, und man diese öfters mal editieren wird. Das ist für mich etwas bequemer als auf der Fritz!Box.
Außerdem liegen hier evtl. mal größere Image-Dateien (z.B. für die Live-CDs).
Dazu kommt, daß ich so die ganzen Konfig-Dateien immer mit im Backup des NAS habe.

raaalf wrote:Kurz und knapp: Wann geht es los?

Im Prinzip stecken wir bereits mittendrin
Wir müssen aber noch ein paar Dinge vorher klären, und dann würde ich für die weitere Realisierung einen eigenen Thread zum Thema PC-Backup dazu aufmachen.

So müssten wir gleich zu Anfang darüber reden, wieviele NAS dabei mitspielen sollen, und wie die intern organisiert werden.
Ich habe anfangs meine PC-Backups auf meinem Haupt-NAS abgelegt.
Das funktionierte natürlich, aber wenn ich dann mein Haupt-NAS auf mein Backup-NAS abgeglichen habe (per zfs send/receive), waren die PC-Backups dort natürlich mit enthalten.
Nun, ein Backup vom Backup ist jetzt nicht unbedingt nötig. Zudem kann man einen Abgleich per Transportfestplatte recht bald vergessen, weil die abzugleichende Datenmenge sehr groß wird.
Das Problem läßt sich auf verschiedene Arten lösen. Die eleganteste Lösung wäre natürlich ein eigenes NAS für die PC-Backups.
Für den Anfang spielt das noch keine große Rolle, aber ich wollte das rechtzeitig erwähnen.

Es ist übrigens eine eigene Thematik, wie man seine NAS und die Datenpools am besten organisiert. Mehrere kleine Einheiten sind i.d.R. besser als eine Große.

raaalf wrote:Wie geht es los?

Mit dem dnsmasq und der Umstellung auf statisches DHCP.
Das bedeutet, daß der DHCP-Server von dnsmasq für die meisten Rechner in deinem Netz statische IP-Adressen vergibt. Dynamisches DHCP geht natürlich weiterhin. Der Vorteil dabei ist, daß man auf den Client-Rechnern keine festen IP-Adressen konfigurieren muß.
Konkret macht man das durch die Pflege der hosts Datei im dnsmasq Modul auf der Fritz!Box.

Grüße
Princo

Hallo Princo,

entschuldige bitte meine kurze Angebundenheit. Ich habe die gefreetze FRITZ!Box aus dem Pool der Reservegeräte nun produktiv gesetzt und bin dabei dnsmasq zu konfigurieren.

Ich werde am Wochenende ausführlich auf Deine Mail eingehen und die offenen Fragen beantworten.

Grüsse

Ralf

raaalf wrote:entschuldige bitte meine kurze Angebundenheit.

Dafür brauchst du dich nicht entschuldigen.
Wir machen das beide in unserer Freizeit, und es gibt immer wieder mal Dinge, welche einfach wichtiger sind.
Das ist für mich kein Problem, und da habe ich die Ruhe weg.
Diese dnsmasq-Geschichte ist übrigens der technisch anspruchsvollste Teil dieses Projekts, da du dir dafür eine Firmwaremodifikation der Fritz!Box bauen musst.

Bei den nachfolgenden Schritten wird es dann sehr viel einfacher. Dabei wird es darum gehen, Dateien aus ISO-Images an bestimmte Stellen zu schieben, und diverse Dienste zu konfigurieren.
Auch diese Dinge werden wir ganz gemütlich umsetzen. Dein NAS wird dabei die ganze Zeit über völlig normal zur Verfügung stehen.
Obwohl es ganz gemütlich vorangehen wird, wirst du mit jedem einzelnen Schritt einen deutlichen Fortgang des Projektes sehen.
Und so ganz nebenbei macht dich das auch für evtl. Störfälle fit

Grüße
Princo

Guten Abend Princo,

princo wrote:Mit dem dnsmasq und der Umstellung auf statisches DHCP. Das bedeutet, daß der DHCP-Server von dnsmasq für die meisten Rechner in deinem Netz statische IP-Adressen vergibt. Dynamisches DHCP geht natürlich weiterhin. Der Vorteil dabei ist, daß man auf den Client-Rechnern keine festen IP-Adressen konfigurieren muß.
Konkret macht man das durch die Pflege der hosts Datei im dnsmasq Modul auf der Fritz!Box.

das wichtigste vorweg: Alle Clients (Notebooks, NAS etc.) erhalten per dsnmasq statische IP-Adressen. Die Konfiguration von dsnmasq ist der einfachere Teil. Hilfreiche Informationen gibt es unter anderem hier http://freetz.org/wiki/packages/dnsmasq. Der aufwändigere Teil war die Erstellung des freetz-Images. Aber auch nur deshalb, weil ich nicht einfach loslegte - was funktionieren kann - sondern von den Informationen zu freetz erschlagen wurde und "zu viel" dazu gelesen habe.

princo wrote:So müssten wir gleich zu Anfang darüber reden, wieviele NAS dabei mitspielen sollen, und wie die intern organisiert werden. Ich habe anfangs meine PC-Backups auf meinem Haupt-NAS abgelegt. Das funktionierte natürlich, aber wenn ich dann mein Haupt-NAS auf mein Backup-NAS abgeglichen habe (per zfs send/receive), waren die PC-Backups dort natürlich mit enthalten. Nun, ein Backup vom Backup ist jetzt nicht unbedingt nötig. Zudem kann man einen Abgleich per Transportfestplatte recht bald vergessen, weil die abzugleichende Datenmenge sehr groß wird.
Das Problem läßt sich auf verschiedene Arten lösen. Die eleganteste Lösung wäre natürlich ein eigenes NAS für die PC-Backups. Für den Anfang spielt das noch keine große Rolle, aber ich wollte das rechtzeitig erwähnen.

Du hast recht: Ein Backup vom Backup ist zu viel des Guten. Zudem würden die Backups/Images vermutlich zu viel von der Kapazität des produktiv genutzten NAS belegen. Um gleich von Anfang an eine klare (Hardware-) Trennung zwischen dem Datenspeicher für sonstige Daten und den Backups/Images zu haben bestellte ich einen N54L der mit 16 GByte [1] ECC RAM und 3 (?) mal 3 TByte WD Red (RAID-Z1) ausgestattet werden soll (DRAM und HDs sind noch nicht bestellt). Es steht also ein für NAS ausschließlich für Backups zur Verfügung

[1] Leider ist es die N54L-Version mit 2 GByte DRAM und 250 GByte Festplatte. Mein Gedanke war, ein 8-GByte-DIMM hinzuzukaufen. Allerdings kostet ein einzelnes 8-GByte-DIMM fast 100 Euro. Da haben 16 GByte mit ca. 160 Euro ein deutlich besseres Preis-/Leistungsverhältnis.

In einem anderen Thread hast Du RAID-Z1 nicht mehr empfohlen. Stattdessen sollte selbst bei nur drei Festplatten RAID-Z2 zum Zuge kommen. Da es kein Backup vom Backup gibt würde ich auch zu RAID-Z2 mit vier Festplatten tendieren um eine höhere Ausfallsicherheit der Festplatten zu gewährleisten.

Gesichert werden müssen aktuell drei Notebooks:

- Notebook 1: 1 TByte Festplatte, ca. 500 GByte genutzt
- Notebook 2: 500 GByte Festplatte, ca. 300 GByte genutzt
- Notebook 3: 300 GByte Festplatte, ca. 250 GByte genutzt

princo wrote:Man kann aber noch viel mehr damit machen. Ich habe damit auch ein paar LIVE-Versionen diverser Linux-Distributionen eingebunden. So kann man auf jeden Rechner einfach Linux ausprobieren, ohne daß man mit CDs und USB-Sticks arbeiten muß. Man kann sogar komplette Diskless-Workstations damit einrichten, wenn man möchte. Bei Openelec geht das sogar ganz besonders einfach.

Wird immer besser!

Für eine Diskless-Workstations hätte ich sogar einen Anwendungfall. Nur leider dürfte das bei Fast-Ethernet bzw. per ausschließlich per WLAN anbindbaren PC nicht wirklich praktikabel umsetzbar sein?

Wenn ich bis jetzt alles richtig verstanden habe, so bootet - ganz grob beschrieben - der zu sichernde Client per PXE das ISO-Image (?) einer Linux-Distribution. Unter Linux wiederum werden per DD (?) usw. die Images/Backups erzeugt und auf dem NAS abgelegt?

Gruß

Ralf

raaalf wrote:Aber auch nur deshalb, weil ich nicht einfach loslegte - was funktionieren kann - sondern von den Informationen zu freetz erschlagen wurde und "zu viel" dazu gelesen habe.

Jau, freetz ist eine heftige Sache. Ich habe mich dabei auf den Einsatz von dnsmasq beschränkt, und das funktioniert wirklich super.

raaalf wrote:Es steht also ein für NAS ausschließlich für Backups zur Verfügung

Hui! Das hört man gerne.

raaalf wrote:[1] Leider ist es die N54L-Version mit 2 GByte DRAM und 250 GByte Festplatte. Mein Gedanke war, ein 8-GByte-DIMM hinzuzukaufen. Allerdings kostet ein einzelnes 8-GByte-DIMM fast 100 Euro. Da haben 16 GByte mit ca. 160 Euro ein deutlich besseres Preis-/Leistungsverhältnis.

Dieser Preis wird sicher demnächst deutlich anziehen.

raaalf wrote:In einem anderen Thread hast Du RAID-Z1 nicht mehr empfohlen. Stattdessen sollte selbst bei nur drei Festplatten RAID-Z2 zum Zuge kommen. Da es kein Backup vom Backup gibt würde ich auch zu RAID-Z2 mit vier Festplatten tendieren um eine höhere Ausfallsicherheit der Festplatten zu gewährleisten.

Achtung! Ich habe hier mehrfach etwas zur RaidZ2-Thematik geschrieben, aber das bezog sich immer auf konkrete Problemstellungen.
(Suche mal über die erweiterte Forensuche nach raidz2, author princo, im deutschen Unterforum)

Zu RaidZ2 mache ich hier mal einen kleinen Erklärungseinschub:
RaidZ2 wird meistens mit "da können bis zu zwei Festplatten ausfallen" gleichgesetzt.
Das ist zwar nicht unrichtig, aber treffender wäre: "da kann eine Festplatte ausfallen, und auf den restlichen Festplatten können einzelne Bereiche defekt sein, ohne daß man Daten verliert."
Das ist nämlich ein Problem, welches RaidZ1-Nutzer haben können, wenn ihnen eine Festplatte ausfällt: Wenn sie die neue Festplatte einbauen und den Resilvering-Prozeß starten, dann kann das schief gehen, wenn eine der restlichen Platten plötzlich einen Datendefekt bekommt, ohne dabei komplett auszufallen.

Dem kann man u.U. dadurch entgegenwirken, daß man regelmäßig einen Scrub-Lauf auf den Datenpools macht.

Ob man RaidZ2 fahren sollte, hängt von einer ganzen Reihe von Aspekten ab, die man im Einzelfall prüfen sollte. Dabei geht es um die Datenmenge, die Größen der Festplatten, die Qualität der Festplatten, und noch ein paar weitere Faktoren.

Wenn Geld keine Rolle spielt, dann kann man natürlich überall RaidZ2 einsetzen
Geht es aber darum, finanzielle Mittel möglichst ökonomisch einzusetzen und dabei die Sicherheit zu erhöhen, dann würde ich bei deiner Konfiguration eher das Haupt-NAS mit RaidZ2 ausstatten.

Der Hintergrund dazu ist folgender:
Falls das PC-Backup-NAS komplett ausfallen würde (also zwei defekte Platten bei RaidZ1), dann wären die Daten ja immer noch auf den Notebooks vorhanden. Solange gleichzeitig nichts mit den Notebooks passiert, wäre das zwar ärgerlich, aber kein Beinbruch.

Wenn du zukünftig mit drei NAS hantierst, dann ist das schon ein Idealzustand, denn dann kannst du alle Freiheiten, was Erweiterungen und "Datenpflege" betrifft.

So kopiere ich ungefähr 1x im Jahr mein PCBackup-NAS auf das Backup-NAS, und wieder zurück, um Fragmentierungseffekten entgegen zu wirken.
Das gleiche mache ich übrigens auch mit dem Haupt-NAS.

Unter ganz seltenen Umständen nutze ich das Backup-NAS auch mal für andere Zwecke. Beispielsweise um spezielle Fehlerszenarien nachzustellen, oder um eine neue N4F-Version unter realen Bedingungen zu testen. Das ist aber eine Ausnahme, denn dann habe ich im Extremfall kein Backup vom Haupt-NAS mehr. (Wobei man das Haupt-NAS (oder die wichtigsten Daten davon) durchaus zwischenzeitlich auf das PC-Backup-NAS sichern kann, wenn dort der Platz vorhanden ist.). Das hört sich etwas creepy an, und das sollte man auch nur dann machen, wenn man genau weiß, was man da tut.

Und spätestens dann ist ein RaidZ2 auf dem Haupt-NAS eine clevere Lösung.

raaalf wrote:Gesichert werden müssen aktuell drei Notebooks:

- Notebook 1: 1 TByte Festplatte, ca. 500 GByte genutzt
- Notebook 2: 500 GByte Festplatte, ca. 300 GByte genutzt
- Notebook 3: 300 GByte Festplatte, ca. 250 GByte genutzt

Das macht etwas über 1 TB an zu sichernder Datenmenge. Als Minimum für den Backup-Bereich nehme ich derzeit den Faktor 2,5 her und runde auf. Das ergibt dann 3TB als voraussichtliches Minimum. Wenn du im PC-Backup-NAS 3x3TB RaidZ1 machst, hast du dort 6TB Platz, und damit genug Luft.

Das hängt aber auch etwas von der Konfiguration der Rechner ab. Im Idealfall sind dort der Windows-Bereich und der Daten-Bereich auf getrennten Partitionen untergebracht. Leider ist das nicht die Windows-Standard-Konfiguration.

raaalf wrote:Für eine Diskless-Workstations hätte ich sogar einen Anwendungfall. Nur leider dürfte das bei Fast-Ethernet bzw. per ausschließlich per WLAN anbindbaren PC nicht wirklich praktikabel umsetzbar sein?

Fast-Ethernet ist nicht so sehr das Problem. Ich habe einen Openelec-Rechner darüber als diskless Workstation angebunden. Das ist in einigen Bereichen etwas langsam, aber ich kann HD darüber abspielen.
Das eigentliche Problem ist WLAN. PXE-Boot funktioniert darüber nicht, das geht nur per Kabel.
Meine Lösung wurde wahrscheinlich auch per WLAN funktionieren, jedoch etwas mehr Aufwand erfordern, wobei ein Image-Backup per WLAN nicht besonders effektiv sein wird.

raaalf wrote:Wenn ich bis jetzt alles richtig verstanden habe, so bootet - ganz grob beschrieben - der zu sichernde Client per PXE das ISO-Image (?) einer Linux-Distribution. Unter Linux wiederum werden per DD (?) usw. die Images/Backups erzeugt und auf dem NAS abgelegt?

[/quote]
Richtig.
Nur verwende ich dd nur für die Sicherung von Linux-Swappartitionen und den MBR. Ansonsten kommen Tools wie ntfsclone und partclone, sowie sfdisk und natürlich rsync zum Einsatz.

Themen, um die ich mich noch nicht sonderlich gekümmert habe, sind der Betrieb mit einem UEFI-Bios und GPT-Partitionen.
Windows XP wird von mir stiefmütterlich behandelt, da ich das hier gar nicht nutze. Image-Backup würden gehen. Beim File-by-File-Backup müßte ich dazu noch etwas anpassen. Nutzt das überhaupt noch jemand?

Grüße
Princo

Guten Abend Princo,

princo wrote:

raaalf wrote:Es steht also ein für NAS ausschließlich für Backups zur Verfügung

Hui! Das hört man gerne.

Der Microserver wurde gestern versandt. Vier WD RED 30EFRX-Festplatten und 16 GByte DRAM wurden bestellt. Eine Remote Management Karte habe ich bei eBay ersteigert - diese gibt es mittlerweile praktisch nicht mehr neu zu kaufen.
Wenn die Hardware hoffentlich am Wochenende komplett ist, wird das DRAM mit mem86+ einem mindestens 24stündigen Test unterzogen und die Festplatten mit "badblocks -wsv -b 4096" gequält bis alle vier Durchgänge fertig sind. Dass heißt, wenn alles gut geht, ist die Hardware am Montag kommender Woche bereit für die Konfiguration.

Um nicht in den Ruch zu kommen, dass Geld keine Rolle spielen würde: Die drei zu sichernden Notebooks sind:

- Netbook Samsung N150P (vier Jahre alt)
- Notebook Asus X51RL (7 Jahre alt)
- Notebook Asus A6U (fast 10 Jahre alt)

Die Hardware reicht meinen - bescheidenen - Ansprüchen an die Leistungsfähigkeit. Mangelnde Performance wird durch den Faktor Zeit ersetzt. Auf dem ältesten Notebook läuft noch Windows XP und die Textverarbeitung Lotus Word Pro, die, bzw. dessen Vorgänger Ami Pro unter Windos 3.1, ich seit ca. 1994 nutze. Das zweitälteste Notebook wird für die Encodierung von Audio-CDs mit EAC genutzt. Das Netbook ist das tägliche Arbeitsgerät zum Surfen, Mailen etc.

Klar, man könnte alles als VM auf einem modernem, leistungsstarken Notebook laufen lassen, aber...

princo wrote:

ralf wrote:Mein Gedanke war, ein 8-GByte-DIMM hinzuzukaufen. Allerdings kostet ein einzelnes 8-GByte-DIMM fast 100 Euro. Da haben 16 GByte mit ca. 160 Euro ein deutlich besseres Preis-/Leistungsverhältnis.

Dieser Preis wird sicher demnächst deutlich anziehen.

Die Preise sind schon interessant. Den N54L kaufte ich für 179,00 Euro. Einen Tag später lag der Preis bei 229,00 Euro. So erging es mir auch bei der Bestellung des ersten N54L, für den ich 199,00 Euro zahlte. Der zweite N54L kostete dann beim selben Händler ein paar Tage später 219,00 Euro.

princo wrote:_VIele interessante und aufschlußreiche Informationen gelöscht_

Ich nehme aus Deinen ausführlichen, interessanten und aufschlußreichen Ausführungen (vielen Dank dafür!) mit, dass ich ein RAID-Z2 auf dem NAS-Imags einsetzen werde. Und zwar aus dem Grund, da der Datenbestand des NAS-Produktiv durch das NAS-Backup geschützt ist. Der Ausfall von x Festplatten würde beim NAS-Produktiv "keine Rolle spielen".
Eine Rolle für mich spielen würde, wenn ich auf ein auf dem NAS-Images gesichertes, älteres Image nicht mehr zugreifen kann, weil ein Festplattenschaden vorliegt. Deshalb der Einsatz von RAID-Z2 um eine höhere Sicherheit gegen Ausfälle zu haben. Um z. B. eine neue NAS4-Free-Version auszuprobieren habe ich ein paar PCs zum Testen.

princo wrote:Das macht etwas über 1 TB an zu sichernder Datenmenge. Als Minimum für den Backup-Bereich nehme ich derzeit den Faktor 2,5 her und runde auf. Das ergibt dann 3TB als voraussichtliches Minimum. Wenn du im PC-Backup-NAS 3x3TB RaidZ1 machst, hast du dort 6TB Platz, und damit genug Luft.
Das hängt aber auch etwas von der Konfiguration der Rechner ab. Im Idealfall sind dort der Windows-Bereich und der Daten-Bereich auf getrennten Partitionen untergebracht. Leider ist das nicht die Windows-Standard-Konfiguration.

Seit jeher kommen bei mir alle Daten auf eine extra Partition. Das macht die Datensicherung wesentlich einfacher.

princo wrote:

ralf wrote:Für eine Diskless-Workstations hätte ich sogar einen Anwendungfall.

Meine Lösung wurde wahrscheinlich auch per WLAN funktionieren, jedoch etwas mehr Aufwand erfordern, wobei ein Image-Backup per WLAN nicht besonders effektiv sein wird.

Mein Anwendungsfall rechtfertigt einen zusätzlichen Aufwand nicht. Eventuell habe ich irgendwann die Möglichkeit, den betreffenden PC drahtgebunden anzubinden. Dann ist der Rest kein Problem mehr.

princo wrote:Themen, um die ich mich noch nicht sonderlich gekümmert habe, sind der Betrieb mit einem UEFI-Bios und GPT-Partitionen. Windows XP wird von mir stiefmütterlich behandelt, da ich das hier gar nicht nutze. Image-Backup würden gehen. Beim File-by-File-Backup müßte ich dazu noch etwas anpassen. Nutzt das überhaupt noch jemand?

UEFI kennen die Notebooks auf Grund ihres Alters - Gottseidank (?) - nicht. GPT setze ich nicht ein. Ein Image-Backup des unter Windows XP laufenden Notebooks würde zwar genügen. Wenn es kein allzugroßer Aufwand ist, wäre die Anpassung für File-by-File-Backups schön. Aber, wie gesagt: Muss nicht sein.

Grüsse

Ralf

raaalf wrote:und 16 GByte DRAM wurden bestellt.

Ich gehe davon aus, daß du damit ECC-RAM meinst.

raaalf wrote:Eine Remote Management Karte habe ich bei eBay ersteigert - diese gibt es mittlerweile praktisch nicht mehr neu zu kaufen.

Mit diesen Karten habe ich leider gar keine Erfahrung.
Habe die noch nie vermisst. Für mich ist nur wichtig, daß man das NAS remote per WOL aufwecken kann, und das war zwischenzeitlich bei diversen N4F Versionen auf dem N54L nicht möglich.

Das bringt mich aber zu einem wichtigen Punkt: Derzeit setze ich auf meinen NASsen noch die Version 9.1.0.1 - Sandstorm (revision 847) ein (also auch auch dem NAS für die PC-Backups).
Der Hauptgrund dafür, daß ich bisher nicht auf die 9.2 oder die 9.3 Version upgedatet habe, war die zwischenzeitlich fehlende WOL-Unterstützung für den N54L.
Da bei meinem System die Clients den Backup-Server aufwecken, wenn sie eine Sicherung machen wollen, war das für mich ein KO-Kriterium.
Zwar wurde das WOL in späteren 9.3 Versionen nachgereicht, aber dafür machten wiederum andere Dienste neue, und sehr heftige Probleme.
Daher habe ich hier den Stand vorerst auf 9.1 Rev. 847 eingefroren.
Seit vorgestern gibt es die 9.3.0.2.1391 Version von NAS4Free. Auf den ersten Blick ist die neue Version glücklicherweise nicht so katastrophal wie die anderen 9.3 Versionen. Da hat sich viel getan, und darüber bin ich sehr froh.
Allerdings will ich das erst noch ausgiebig testen. Bei "meiner" Backup-Lösung will ich natürlich eine ganz stabile Grundlage haben, der ich auch vertrauen kann.
Daher mein Vorschlag: wir richten dein PC-Backup-NAS erst mal mit der Version 9.1.0.1 Rev. 847 ein.
Diese Version ist zwar nicht mehr downloadbar, aber ich könnte sie dir zukommen lassen.
In der Zwischenzeit werde ich mir die aktuelle N4F-Version anschauen, und wenn die etwas taugt, dann können wir dein PC-Backup-NAS einfach upgraden.
Für dich ergeben sich dadurch keine Nachteile. Wir installieren zwar erst mal eine ältere Version, aber die ist dafür auch ordentlich durchgetestet.

raaalf wrote:und die Festplatten mit "badblocks -wsv -b 4096" gequält bis alle vier Durchgänge fertig sind.

Da bin ich mir nicht so sicher, ob der badblocks-Test tatsächlich etwas bringt.
N4F scheint sich um diese Einträge gar nicht zu scheren. Der einzige Nutzen ist womöglich nur, daß die Festplatten ordentlich ran genommen werden, und u.U. schon im Testzeitraum ausfallen (was in diesem Fall sogar gut wäre).

raaalf wrote:Das heißt, wenn alles gut geht, ist die Hardware am Montag kommender Woche bereit für die Konfiguration.

Du brauchst hier übrigens noch nichts konfigurieren, also kein RaidZ? einrichten oder irgendetwas anderes mit dem PC-Backup-NAS machen.
Sämtliche Konfiguationsschritte werden wir mit Hilfe eines Skripts und einer vordefinierten Konfigurationsdatei durchführen.
Das erscheint mir sinnvoller, als die ganzen Einzelschritte in mehreren Postings abzuhandeln.
Keine Angst, das wird total transparent für dich ablaufen. Es geht nur darum, lästige Tippfehlerprobleme auszuschließen.

raaalf wrote:Um nicht in den Ruch zu kommen, dass Geld keine Rolle spielen würde: Die drei zu sichernden Notebooks sind:

- Netbook Samsung N150P (vier Jahre alt)
- Notebook Asus X51RL (7 Jahre alt)
- Notebook Asus A6U (fast 10 Jahre alt)

OK, jetzt weiß ich, daß wir es hier überwiegend mit Fast Ethernet und mit 32-Bit-Systemen zu tun haben. Das ist nicht unwichtig.

raaalf wrote:Ich nehme aus Deinen ausführlichen, interessanten und aufschlußreichen Ausführungen (vielen Dank dafür!) mit, dass ich ein RAID-Z2 auf dem NAS-Imags einsetzen werde. Und zwar aus dem Grund, da der Datenbestand des NAS-Produktiv durch das NAS-Backup geschützt ist. Der Ausfall von x Festplatten würde beim NAS-Produktiv "keine Rolle spielen".

Ich werde jetzt natürlich einen Teufel tun, und dir das RaidZ2 auf dem PC-Backup-NAS ausreden wollen.
Allerdings glaube ich, daß diese Konfiguration in der Praxis oversized ist, da wir sehr wahrscheinlich von der tatsächlichen Datenmenge gaaaanz weit darunter liegen werden. Das wird dir aber erst nach einigen Wochen im regulären Betrieb richtig verständlich werden.

Es kann dabei rauskommen, daß 3TB Platz auf dem PC-Backup-NAS völlig ausreichen. Das könnte man entweder mit einem dreifach Mirror, oder einem RaidZ2 aus drei Platten erreichen. Aber es ist gut zu wissen, daß wir auch mit vier Platten arbeiten können.

raaalf wrote:Eine Rolle für mich spielen würde, wenn ich auf ein auf dem NAS-Images gesichertes, älteres Image nicht mehr zugreifen kann, weil ein Festplattenschaden vorliegt. Deshalb der Einsatz von RAID-Z2 um eine höhere Sicherheit gegen Ausfälle zu haben.

Guter Punkt.
Ich habe einen Laptop. Für diesen Laptop gibt es genau ein historisch wichtiges Image, und zwar das Image des Auslieferungszustandes. Dieses Image habe ich (auch) auf dem Haupt-NAS abgelegt.

raaalf wrote:Um z. B. eine neue NAS4-Free-Version auszuprobieren habe ich ein paar PCs zum Testen.

Wenn du da einen frei verfügbaren PC hast, dann könntest du dort doch sicher auch mal eine Linux-Installation vornehmen, oder?
Das wäre insofern hilfreich, da wir ein paar Dateien aus ISO-Images und komprimierten Archiven extrahieren, und auf das NAS schieben müssen.
Mit Linux wäre das viel einfacher, als mit Windows, weil die erforderlichen Entpackprogramme bereits vorhanden sind.
Wenn dieser PC über PXE booten könnte, dann wäre das übrigens auch ein idealer Testkandidat für eine vollständige Backup/Restore-Übung.

raaalf wrote:Seit jeher kommen bei mir alle Daten auf eine extra Partition. Das macht die Datensicherung wesentlich einfacher.

Mit dieser Info bin ich mir jetzt ziemlich sicher, daß du mit 3TB auf dem PC-Backup-NAS auskommen wirst. Aber das werden wir sehen.

raaalf wrote:Mein Anwendungsfall rechtfertigt einen zusätzlichen Aufwand nicht. Eventuell habe ich irgendwann die Möglichkeit, den betreffenden PC drahtgebunden anzubinden. Dann ist der Rest kein Problem mehr.

Die simpelste Möglichkeit wäre der Einsatz von Powerline-Adaptern (falls es eine Standortfrage ist), Da gibt es 2er-Sets schon für ~35€. Ich habe das hier im Einsatz, und es funktioniert sehr gut.

raaalf wrote:Ein Image-Backup des unter Windows XP laufenden Notebooks würde zwar genügen. Wenn es kein allzugroßer Aufwand ist, wäre die Anpassung für File-by-File-Backups schön. Aber, wie gesagt: Muss nicht sein.

Da du deine Daten überall auf einer extra Partition abgelegt hast, stellt sich das "Problem" für dich gar nicht. File-by-file-Backup ist möglich.
Das "Problem" ist übrigens total trivial, und eigentlich weiß ich auch, wie das zu lösen ist. Ich habe nur gerade keinen XP-Rechner aufgesetzt, und kann die Lösung daher nicht unter Echtbedingungen testen.

Aber, wie gesagt, es betrifft dich gar nicht.

Grüße
Princo

Guten Morgen Princo,

Princo wrote:Ich gehe davon aus, daß du damit ECC-RAM meinst.

ECC-DRAM halte ich für den Einsatzzweck für unnötig (siehe Signatur). Deshalb habe ich darauf vezichtet. Sollte ja kein Problem sein, oder?

princo wrote:[Remote Management Karte]Mit diesen Karten habe ich leider gar keine Erfahrung. Habe die noch nie vermisst. Für mich ist nur wichtig, daß man das NAS remote per WOL aufwecken kann, und das war zwischenzeitlich bei diversen N4F Versionen auf dem N54L nicht möglich.

Wegen der Virtual-KVM-Funktion bin ich ein großer Anhänger der Remote-Management-Karten. So kann ich mir LC-Display, Maus und Tastatur sparen und alle administrativen Dinge, die direkt am Server durchgeführt werden müssen (Zugriff auf das BIOS z. B.), bequem vom Notebook aus erledigen. Finde ich sehr, sehr praktisch.

princo wrote:Derzeit setze ich auf meinen NASsen noch die Version 9.1.0.1 - Sandstorm (revision 847) ein. [...] Daher mein Vorschlag: wir richten dein PC-Backup-NAS erst mal mit der Version 9.1.0.1 Rev. 847 ein.

Ich habe überhaupt kein Problem damit, wenn das "NAS-IMAGES" auf der NAS4Free-Version 9.1.0.1 aufbaut. Wichtig ist in erster Linie die Funktion und nicht, dass die aktuellste NAS4-Free-Version verwendet wird. Kannst Du mir bitte die entsprechende *.img-Datei zukommen lassen?

princo wrote:Da bin ich mir nicht so sicher, ob der badblocks-Test tatsächlich etwas bringt.
N4F scheint sich um diese Einträge gar nicht zu scheren. Der einzige Nutzen ist womöglich nur, daß die Festplatten ordentlich ran genommen werden, und u.U. schon im Testzeitraum ausfallen (was in diesem Fall sogar gut wäre).

Bitte berichtigen wenn ich Unsinn erzähle: Die Firmware moderner ATA-/SATA-Festplatten hat ein Bad-Block-Management. Deshalb kann mit "badblocks" nur mit der Option -w bzw. -n erst dann ein Bad Block erkannt werden, wenn die von der Festplatte vorgehaltenen Reserveblöcke aufgebraucht sind.

So gesehen ist der mehrtägige Durchlauf mit "badblocks" mehr ein Burn-in. Bzw., wenn Bad Blocks gefunden werden sollten, ein klares Zeichen dafür die Festplatte zu ersetzen, da die Reserveblöcke aufgebraucht sind.

princo wrote:Du brauchst hier übrigens noch nichts konfigurieren, also kein RaidZ? einrichten oder irgendetwas anderes mit dem PC-Backup-NAS machen. Sämtliche Konfiguationsschritte werden wir mit Hilfe eines Skripts und einer vordefinierten Konfigurationsdatei durchführen.

Perfekt! Da kann beim Aufsetzen des Systems ja nichts mehr schief gehen. Super.

princo wrote:OK, jetzt weiß ich, daß wir es hier überwiegend mit Fast Ethernet und mit 32-Bit-Systemen zu tun haben. Das ist nicht unwichtig.

Ja, alles 32-Bit-Systeme und - leider - nur Fast-Ethernet. Ob es 32- oder 64-Bit-Systeme sind spielt eine Rolle für die verwendete Linux-Distribution die per PXE gebootet wird und nicht für das Imagen als solches, oder?

princo wrote:Ich werde jetzt natürlich einen Teufel tun, und dir das RaidZ2 auf dem PC-Backup-NAS ausreden wollen. Allerdings glaube ich, daß diese Konfiguration in der Praxis oversized ist, da wir sehr wahrscheinlich von der tatsächlichen Datenmenge gaaaanz weit darunter liegen werden. [...] Es kann dabei rauskommen, daß 3TB Platz auf dem PC-Backup-NAS völlig ausreichen.

Sollte sich herausstellen, dass die zur Verfügung stehenden 4 x 3 TByte Festplatten zu viel des Guten sind, dann kann ich immer noch hergehen und die vierte Festplatte in das NAS-PRODUKTIV einbauen, dort als RAID-Z2 konfigurieren und anschließend alle Daten vom NAS-BACKUP zurückspielen. "Backup" meint hier Backup vom NAS-PRODUKTIV und nicht NAS zur Speicherung der Images/Backups eines PCs bzw. Notebooks. Meine Namensgebung ist:

NAS-PRODUKTIV
NAS-BACKUP (Backup vom NAS-PRODUKTIV)
NAS-IMAGES (Images/Backups von PCs bzw. Notebooks)

princo wrote:

raaalf wrote:Eine Rolle für mich spielen würde, wenn ich auf ein auf dem NAS-Images gesichertes, älteres Image nicht mehr zugreifen kann, weil ein Festplattenschaden vorliegt.

Guter Punkt. Ich habe einen Laptop. Für diesen Laptop gibt es genau ein historisch wichtiges Image, und zwar das Image des Auslieferungszustandes. Dieses Image habe ich (auch) auf dem Haupt-NAS abgelegt.

In der Vergangenheit erstellte ich monatlich ein Festplattenimage mit TrueImage und speicherte so viele Images, bis die Kapazität der externen USB-Festplatte (2 TByte) erschöpft war um dann das älteste Image zu löschen.

princo wrote:Wenn du da einen frei verfügbaren PC hast, dann könntest du dort doch sicher auch mal eine Linux-Installation vornehmen, oder?

Kein Problem. Eine Ubuntu-14.04-LTE-Installation steht zur Verfügung.

princo wrote:Das wäre insofern hilfreich, da wir ein paar Dateien aus ISO-Images und komprimierten Archiven extrahieren, und auf das NAS schieben müssen. Mit Linux wäre das viel einfacher, als mit Windows, weil die erforderlichen Entpackprogramme bereits vorhanden sind. Wenn dieser PC über PXE booten könnte, dann wäre das übrigens auch ein idealer Testkandidat für eine vollständige Backup/Restore-Übung.

Das Booten über PXE ist auch kein Problem. Ubuntu 14.04 LTE wurde auf dem Notebook Asus X51RL - auf einer extra Festplatte - installiert. Ich muß nur die Festplatten tauschen. Diese etwas ungewöhnliche Lösung wählte ich deshalb, weil ich kein Dual-Boot-System (Linux/Windows) einrichten wollte und ausreichend große 2,5-Zoll-Festplatten für die Installation zur Verfügung habe.

princo wrote:

raaalf wrote:Mein Anwendungsfall rechtfertigt einen zusätzlichen Aufwand nicht. Eventuell habe ich irgendwann die Möglichkeit, den betreffenden PC drahtgebunden anzubinden. Dann ist der Rest kein Problem mehr.

Die simpelste Möglichkeit wäre der Einsatz von Powerline-Adaptern (falls es eine Standortfrage ist), Da gibt es 2er-Sets schon für ~35€. Ich habe das hier im Einsatz, und es funktioniert sehr gut.

Nach dem leider enttäuschenden Test mit einem PowerLine-Adapter vor ein paar Wochen wäre meine Überlegung, zwei Access-Points im Client-Mode zu verbinden und den PC dann per Fast-Ethernet an dem Access-Point anzuschließen. So müsste PXE eigentlich funktionieren, da die WLAN-Verbindung transparent ist?

princo wrote:

raaalf wrote:Ein Image-Backup des unter Windows XP laufenden Notebooks würde zwar genügen. Wenn es kein allzugroßer Aufwand ist, wäre die Anpassung für File-by-File-Backups schön.

Da du deine Daten überall auf einer extra Partition abgelegt hast, stellt sich das "Problem" für dich gar nicht. File-by-file-Backup ist möglich.

Princo, langsam aber sicher werde ich immer neugieriger, wie das Erstellen der Images bzw. Backups real abläuft, funktioniert.

Grüsse

Ralf

raaalf wrote:ECC-DRAM halte ich für den Einsatzzweck für unnötig (siehe Signatur). Deshalb habe ich darauf vezichtet. Sollte ja kein Problem sein, oder?

Du setzt ZFS ein. Dann brauchst du ECC-RAM. Dein System unterstützt ECC-RAM.
Ich halte es für falsch, gerade an dieser Stelle zu sparen.

raaalf wrote:Wegen der Virtual-KVM-Funktion bin ich ein großer Anhänger der Remote-Management-Karten. So kann ich mir LC-Display, Maus und Tastatur sparen und alle administrativen Dinge, die direkt am Server durchgeführt werden müssen (Zugriff auf das BIOS z. B.), bequem vom Notebook aus erledigen. Finde ich sehr, sehr praktisch.

Praktisch ist das schon, aber nutzen tut man das nur für die Einrichtung und danach kaum noch.
Wichtiger wäre es, ECC-RAM im System zu haben.

raaalf wrote:Ich habe überhaupt kein Problem damit, wenn das "NAS-IMAGES" auf der NAS4Free-Version 9.1.0.1 aufbaut. Wichtig ist in erster Linie die Funktion und nicht, dass die aktuellste NAS4-Free-Version verwendet wird. Kannst Du mir bitte die entsprechende *.img-Datei zukommen lassen?

Das Wochenende habe ich dazu genutzt, die aktuelle NAS4Free Version 9.3.0.2.1391 zu testen.
Sieht sehr gut aus, es hat alles funktioniert. Auch das Einbinden der Backup-Images als Freigabe funktioniert, und das war meine größte Sorge bei der neuen Version.
Daher glaube ich, daß wir die aktuelle Version für dein NAS-IMAGES nehmen können. Dies ist insofern von Vorteil, da wir dann auch die neue Kompressionsmethode lz4 einsetzen können, was sehr sinnvoll ist.

raaalf wrote:Bitte berichtigen wenn ich Unsinn erzähle: Die Firmware moderner ATA-/SATA-Festplatten hat ein Bad-Block-Management. Deshalb kann mit "badblocks" nur mit der Option -w bzw. -n erst dann ein Bad Block erkannt werden, wenn die von der Festplatte vorgehaltenen Reserveblöcke aufgebraucht sind.

So gesehen ist der mehrtägige Durchlauf mit "badblocks" mehr ein Burn-in. Bzw., wenn Bad Blocks gefunden werden sollten, ein klares Zeichen dafür die Festplatte zu ersetzen, da die Reserveblöcke aufgebraucht sind.

Das kann man so nicht pauschal sagen. Es macht bei ZFS nichts aus, wenn eine Festplatte Badblocks aufweist, solange der Pool mit ausreichender Redundanz betrieben wird. Es wird nur dann kritisch, wenn permanent neue Badblocks hinzukommen.
Das ist die Besonderheit bei ZFS: Es kommt auch mit schlechten Festplatten klar. Umso wichtiger ist es übrigens, daß man sein System mit ECC-RAM betreibt.

raaalf wrote:Ja, alles 32-Bit-Systeme und - leider - nur Fast-Ethernet. Ob es 32- oder 64-Bit-Systeme sind spielt eine Rolle für die verwendete Linux-Distribution die per PXE gebootet wird und nicht für das Imagen als solches, oder?

Richtig, und sehr gut beobachtet.
Die Linux-Distribution, die ich für das Backup verwende, ist sowohl für 32Bit- als auch für 64Bit-Systeme geeignet.
Das Einzige, was man bei 32Bit-Systemen eher antrifft, ist evtl. etwas wenig Arbeitsspeicher. Aber das schätze ich nicht als kritisch ein. Da muß man dann halt etwas rumprobieren.

raaalf wrote:Sollte sich herausstellen, dass die zur Verfügung stehenden 4 x 3 TByte Festplatten zu viel des Guten sind, dann kann ich immer noch hergehen und die vierte Festplatte in das NAS-PRODUKTIV einbauen, dort als RAID-Z2 konfigurieren und anschließend alle Daten vom NAS-BACKUP zurückspielen. "Backup" meint hier Backup vom NAS-PRODUKTIV und nicht NAS zur Speicherung der Images/Backups eines PCs bzw. Notebooks. Meine Namensgebung ist:

NAS-PRODUKTIV
NAS-BACKUP (Backup vom NAS-PRODUKTIV)
NAS-IMAGES (Images/Backups von PCs bzw. Notebooks)

Dieses "Sollte sich herausstellen, dass", ist ein Knackpunkt.
Wie definiert man diesen Punkt?
Im Kern geht es darum, ob du für die Backups 3TB, oder 6TB Platz brauchst, und mit welcher Sicherheitsstufe (RaidZ1 oder RaidZ2) das NAS betrieben werden sollte.
Das kann man tatsächlich erst im praktischen Betrieb herausfinden.
Dabei muß man berücksichtigten, daß man gerade in der Anfangsphase recht abnorme Werte erreicht, welche sich später (im dauerhaften Betrieb) drastisch nach unten verändern werden.

Mein "NAS-IMAGES" besteht aus 4x1TB Platten im RaidZ1-Verbund, also nutzbare 3TB. Davon sind ~2TB belegt. Darauf sind mehr als fünf Rechner abgespeichert. Allerdings bin ich bemüht, die Datenmenge auf diesen Rechnern möglichst gering zu halten. Daten sollten möglichst nur auf dem Haupt-NAS gespeichert werden. Auf den "anderen" Rechnern sollten sich immer nur die aktuell benötigten Daten befinden.

raaalf wrote:In der Vergangenheit erstellte ich monatlich ein Festplattenimage mit TrueImage und speicherte so viele Images, bis die Kapazität der externen USB-Festplatte (2 TByte) erschöpft war um dann das älteste Image zu löschen.

Ja, genau so habe ich das früher auch gemacht.
Dabei fand ich es aber schwierig, die Balance zwischen dem Speicherplatz für die Image-Backups und dem, was für die File-by-File-Backups zur Verfügung stehen soll, zu finden. Das trifft es aber nicht ganz. Eher hatte ich Probleme damit, das programmtechnisch umzusetzen. Ich bin leider kein guter Programmierer
Noch komplizierter wird es, wenn man nur eine externe Backup-Platte für mehrere Rechner hat.
Gibt es Rechner, die wichtiger als die anderen sind? Wie regelt man es, welche alten Backup-Sätze zuerst gelöscht werden?
Die Problematik ist nicht ganz trivial.
Ich habe hier einen Rechner, der seit vielen Jahren jeden Tag sein File-by-File-Backup auf eine externe Festplatte (750 GB) macht. Das ist so ein Langzeit-Experiment von mir. Falls der Platz zu klein wird, werden automatisch so viele alte Backup-Stände gelöscht, daß die Sicherung durchgeführt werden kann.
In der Praxis hat sich gezeigt, daß ich damit ein ganzes Jahr lückenlos backuppen kann. Man kann jederzeit den Systemzustand zu einem bestimmten Datum des letzten Jahres wiederherstellen.
Aber,
das habe ich tatsächlich noch nie gebraucht...
Wenn ich doch mal auf das Backup zurückgreifen mußte, dann betraf es entweder das letzte, oder in ganz seltenen Fällen, das vorletzte Backup.

Da ich die Backups zentral auf dem NAS haben wollte, dabei aber auch alle Vorzüge von ZFS ausnutzen wollte, brauchte ich eine Lösung, wie man das mit den verschiedenen Backup-Ständen handhabt.

Ich habe daher zuerst nach einer Notlösung gegriffen, indem ich dafür die Autosnapshot-Funktion von NAS4Free genutzt habe.
Dabei wird jeden Tag um 20 Uhr ein Autosnapshot auf die jeweiligen Backup-Verzeichnisse gemacht.
Da man bei den Autosnapshots individuell einstellen kann, wie lange sie aufgehoben werden, (1 Woche, 2 Wochen, 30 Tage, 60 Tage, 180 Tage, oder "für immer") kann man das so einstellen, daß die Kapazität des NAS gut ausgenutzt wird.
Das, was ursprünglich eine Notlösung war, hat sich in der Praxis aber ausnehmend gut bewährt. so daß ich dabei geblieben bin. Das System eignet sich gut für tägliche File-by-File-Sicherungen, und für regelmäßige Image-Backups des Windows-Systembereichs.
Der Ansatz klingt sicher etwas schräg, aber er funktioniert in der Praxis sehr gut.

princo wrote:Wenn du da einen frei verfügbaren PC hast, dann könntest du dort doch sicher auch mal eine Linux-Installation vornehmen, oder?

raaalf wrote:Kein Problem. Eine Ubuntu-14.04-LTE-Installation steht zur Verfügung.
...
Das Booten über PXE ist auch kein Problem. Ubuntu 14.04 LTE wurde auf dem Notebook Asus X51RL - auf einer extra Festplatte - installiert. Ich muß nur die Festplatten tauschen. Diese etwas ungewöhnliche Lösung wählte ich deshalb, weil ich kein Dual-Boot-System (Linux/Windows) einrichten wollte und ausreichend große 2,5-Zoll-Festplatten für die Installation zur Verfügung habe.

Ein Dualboot mit Windows/Linux ist eigentlich keine schlechte Sache, wenn man tatsächlich viel mit Linux arbeitet. Auf den Rechnern, bei denen bei mir noch ein Windows vorhanden ist, habe ich ich überall ein Dualboot mit Linux eingerichtet. Das Liegt aber auch daran, daß ich zu mehr als 99,9% mit Linux arbeite.

raaalf wrote:Nach dem leider enttäuschenden Test mit einem PowerLine-Adapter vor ein paar Wochen wäre meine Überlegung, zwei Access-Points im Client-Mode zu verbinden und den PC dann per Fast-Ethernet an dem Access-Point anzuschließen. So müsste PXE eigentlich funktionieren, da die WLAN-Verbindung transparent ist?

Uups, das ist natürlich schade. Normalerweise sollten die Powerline-Adapter sauber funktionieren, wenn sie direkt in die Wandsteckdosen gesteckt werden. Diese Dinger verwende ich hier selber für meinen Hauptrechner, um das Internet anzubinden.
Geschwindigkeitsrekorde kann man nicht erwarten, aber besser (stabiler) als WLAN sollte es schon sein. Zuerst war ich auch skeptisch, aber die Teile funktionieren bei mir.

raaalf wrote:Princo, langsam aber sicher werde ich immer neugieriger, wie das Erstellen der Images bzw. Backups real abläuft, funktioniert.

*lach*
Du, das ist viel einfacher als du denkst Das Brimborium drumherum dient eigentlich nur dazu, daß das Ganze sehr bedienerfreundlich wird.
Und wenn "Backup" bedienerfreundlich ist, dann wird man es auch regelmäßig durchführen.

Wie geht es weiter?
Wenn wir hier alle offenen Fragen abgehandelt haben, würde ich zu dem Thema "PXE gestütztes Backup" eine neuen Thread aufmachen.
Dort würde ich die Ausgangslage zusammenfassen, und auf die Rahmenbedingungen für dieses Projekt hinweisen (Notwendigkeit eines PXE-Servers).
Als nächsten Schritt werden wir die PXE-Funktionalität einrichten, und testen.
Wenn das geklappt hat, werden wir die Backup/Restore Funktionalität für deine einzelnen Rechner definieren und natürlich auch ausprobieren.

Was kann schiefgehen?
"Kritisch" ist das Nichtvorhandensein von Gigabit-Ethernet, und daß bei der Übertragung WLAN-Strecken mit im Spiel sind.
Dazu kommt, daß wir es mit relativ großen Datenmengen zu tun haben.

Warum kann das trotzdem klappen?
Du hast darauf geachtet, daß dein System und die Daten auf getrennten Partitionen liegen. Dadurch bekommen wir ein kleines System-Image, und können die Daten als File-by-File-Backup sehr elegant (zeitsparend) übertragen.
Du hast bereits eine bestehende Backup-Lösung, und dir ist klar, daß fehlende Übertragungskapazität durch "Zeit" ausgeglichen wird.
Dazu kommt, daß du über das ausreichende technisches Verständnis, sowie die notwendige Geduld und Übersicht verfügst, um so etwas durchzuziehen.

Ich bin da sehr optimistisch.

Grüße
Princo

Guten Morgen Princo,

Princo wrote:

raaalf wrote:ECC-DRAM halte ich für den Einsatzzweck für unnötig (siehe Signatur). Deshalb habe ich darauf vezichtet. Sollte ja kein Problem sein, oder?

Du setzt ZFS ein. Dann brauchst du ECC-RAM. Dein System unterstützt ECC-RAM. Ich halte es für falsch, gerade an dieser Stelle zu sparen.

ich wollte ironisch sein, hat nicht funktioniert. Sorry! Es sind natürlich 16 GByte ECC-DRAM, ich kenne ja das Mantra des Forums.

Gruß

Ralf

Servus Princo,

princo wrote:Das Wochenende habe ich dazu genutzt, die aktuelle NAS4Free Version 9.3.0.2.1391 zu testen. Sieht sehr gut aus, es hat alles funktioniert.

Prima! Der USB-Stick mit NAS4Free 9.3.0.2.1391 (Embedded-Installation) ist vorbereitet und steckt bereits im internen USB-Port des N54L.

Vorab habe ich bereits die grundlegenden Dinge konfiguriert wie E-Mail-Report etc.

princo wrote:Das kann man so nicht pauschal sagen. Es macht bei ZFS nichts aus, wenn eine Festplatte Badblocks aufweist, solange der Pool mit ausreichender Redundanz betrieben wird. Es wird nur dann kritisch, wenn permanent neue Badblocks hinzukommen. Das ist die Besonderheit bei ZFS: Es kommt auch mit schlechten Festplatten klar. Umso wichtiger ist es übrigens, daß man sein System mit ECC-RAM betreibt.

ECC-DRAM ist natürlich vorhanden, habe nur einen Spass gemacht. Ich habe bzw. hätte ein ungutes Gefühl, wenn eine Festplatte mit Bad Blocks im Einsatz wäre. Ich denke, so teuer sind Festplatten nicht (mehr), dass man sie nicht umgehend austauschen könnte sobald Bad Blocks auftauchen. Auch wenn dank der Besonderheiten von ZFS ist kein Datenverlust zu befürchten ist.

princo wrote:Das Einzige, was man bei 32Bit-Systemen eher antrifft, ist evtl. etwas wenig Arbeitsspeicher. Aber das schätze ich nicht als kritisch ein. Da muß man dann halt etwas rumprobieren.

Der Arbeitsspeicher ist bei allen Geräten maximal ausgebaut: 2 GByte beim Samsung N150P,
3 GByte beim ASUS X51RL (das BIOS erkennt von den 4 GByte leider nur 3 GByte) und beim ASUS A6U 2 GByte.

princo wrote:Dieses "Sollte sich herausstellen, dass", ist ein Knackpunkt.
Wie definiert man diesen Punkt? Im Kern geht es darum, ob du für die Backups 3TB, oder 6TB Platz brauchst, und mit welcher Sicherheitsstufe (RaidZ1 oder RaidZ2) das NAS betrieben werden sollte. Das kann man tatsächlich erst im praktischen Betrieb herausfinden. Dabei muß man berücksichtigten, daß man gerade in der Anfangsphase recht abnorme Werte erreicht, welche sich später (im dauerhaften Betrieb) drastisch nach unten verändern werden.

Dann wird es darauf hinauslaufen, dass sich mit der Zeit zeigen wird, ob sich die von mir gewählte RAID-Z2-Konfiguration bewährt was die zur Verfügunge stehende Kapazität betrifft. Ein RAID-Z2 ist mir für den Anwendungsfall eines "NAS-IMAGES" wichtig.

princo wrote:Noch komplizierter wird es, wenn man nur eine externe Backup-Platte für mehrere Rechner hat. Gibt es Rechner, die wichtiger als die anderen sind? Wie regelt man es, welche alten Backup-Sätze zuerst gelöscht werden? Die Problematik ist nicht ganz trivial.

Wenn nur eine externe Festplatte bzw., wie in meinem Fall, zwei externe Festplatten im "RAID-1-Modus für Arme" (die Master-Festplatte wurde regelmässig auf die Slave-Festplatte geklont) zur Verfügung steht muss man Kompromisse eingehen die ich nicht mehr eingehen will. Ich kann keine Priorisierung der auf den drei Notebooks gespeicherten Daten festlegen. Die Daten jedes Notebooks sind gleich wichtig, da unwiderbringlich.

princo wrote:Ich habe hier einen Rechner, der seit vielen Jahren jeden Tag sein File-by-File-Backup auf eine externe Festplatte (750 GB) macht. Falls der Platz zu klein wird, werden automatisch so viele alte Backup-Stände gelöscht, daß die Sicherung durchgeführt werden kann. In der Praxis hat sich gezeigt, daß ich damit ein ganzes Jahr lückenlos backuppen kann. Aber, das habe ich tatsächlich noch nie gebraucht... Wenn ich doch mal auf das Backup zurückgreifen mußte, dann betraf es entweder das letzte, oder in ganz seltenen Fällen, das vorletzte Backup.

"Früher", als es 2,5 Zoll-Festplatten nicht mit den Kapazitäten gab wie 3,5-Zoll-Festplatten, musste ich oft auf den Notebooks äufräumen (Daten löschen) und war darauf angewiesen, dass ich im Falle des Falles auf ein Bakup der aus Platzgründen gelöschten Daten zurückgreifen konnte. Das hat sich mittlerweile entspannt, da 2,5-Zoll-Festplatten in Kapazitäten zur Verfügung stehen, die meinen Platzbedarf bei weitem übersteigen. Ich denke, wenn auf Daten, Images, Backups von vor einem Jahr zurückgegriffen werden können ist das mehr als ausreichend.

princo wrote:Da man bei den Autosnapshots individuell einstellen kann, wie lange sie aufgehoben werden, (1 Woche, 2 Wochen, 30 Tage, 60 Tage, 180 Tage, oder "für immer") kann man das so einstellen, daß die Kapazität des NAS gut ausgenutzt wird.
Das, was ursprünglich eine Notlösung war, hat sich in der Praxis aber ausnehmend gut bewährt. so daß ich dabei geblieben bin. Das System eignet sich gut für tägliche File-by-File-Sicherungen, und für regelmäßige Image-Backups des Windows-Systembereichs.
Der Ansatz klingt sicher etwas schräg, aber er funktioniert in der Praxis sehr gut.

Die einfachsten Lösungen sind doch oft die besten.

princo wrote:Ein Dualboot mit Windows/Linux ist eigentlich keine schlechte Sache, wenn man tatsächlich viel mit Linux arbeitet. Auf den Rechnern, bei denen bei mir noch ein Windows vorhanden ist, habe ich ich überall ein Dualboot mit Linux eingerichtet. Das Liegt aber auch daran, daß ich zu mehr als 99,9% mit Linux arbeite.

Ich verwende Linux bzw. Ubuntu nur auf einem älteren PC mit vormals Windows XP für den ich keine Windows-7-Lizenz habe und auf dem ASUS X51RL als "Dualboot" um damit Erfahrungen zu sammeln.
Seit meinen ersten Erfahrungen mit Linux von vor 20 Jahren, als man den Kernel noch selbst kompilieren musste und dies nicht unbedingt für Anfänger so einfach war, habe ich nichts mehr damit zu tun gehabt. Da Linux aber praktisch überall drinsteckt sind Linux-Kenntnisse immer hilfreich. Leider mangelt es mir an über das grundlegende, einfachste hinausgehende Kenntnisse.

princo wrote:Uups, das ist natürlich schade. Normalerweise sollten die Powerline-Adapter sauber funktionieren, wenn sie direkt in die Wandsteckdosen gesteckt werden. Diese Dinger verwende ich hier selber für meinen Hauptrechner, um das Internet anzubinden.
Geschwindigkeitsrekorde kann man nicht erwarten, aber besser (stabiler) als WLAN sollte es schon sein. Zuerst war ich auch skeptisch, aber die Teile funktionieren bei mir.

Die Übertragungsraten mit den Powerline-Adaptern waren extrem schlecht. Wenn die FRITZ!Box 7270 nicht das Problem hätte, dass die CPU bei der Übertragung von etlichen GByte per WLAN überhitzt und in Folge dessen neu gebootet werden muss, würde die Sache mit dem Access-Point im Client-Mode einwandfrei funktionieren. Aber das betrifft die Netzwerkinstallation bei meiner Freundin, wo auch der Anwendungsfall für eine Diskless-Station wäre. Bei mir sind alle Notebooks während des Backups bzw. der Imageerstellung per LAN angebunden.

Ich möchte in diesem Thread kein Durcheinander verursachen und werde deshalb nur noch vom aktuellen Fall (NAS-IMAGES) sprechen und nicht mehr die Installation bei meiner Freundin zur Sprache bringen.

princo wrote:Du, das ist viel einfacher als du denkst. Das Brimborium drumherum dient eigentlich nur dazu, daß das Ganze sehr bedienerfreundlich wird. Und wenn "Backup" bedienerfreundlich ist, dann wird man es auch regelmäßig durchführen.

Ja, die Bedienerfreundlichkeit ist ein großes Problem bei Backups bzw. wenn vorhanden ein sehr, sehr großer Pluspunkt!

princo wrote:

raaalf wrote:Wie geht es weiter?

Wenn wir hier alle offenen Fragen abgehandelt haben, würde ich zu dem Thema "PXE gestütztes Backup" eine neuen Thread aufmachen. Dort würde ich die Ausgangslage zusammenfassen, und auf die Rahmenbedingungen für dieses Projekt hinweisen (Notwendigkeit eines PXE-Servers).
Als nächsten Schritt werden wir die PXE-Funktionalität einrichten, und testen.
Wenn das geklappt hat, werden wir die Backup/Restore Funktionalität für deine einzelnen Rechner definieren und natürlich auch ausprobieren.

Gibt es noch offene Fragen die geklärt werden müssen? Die Hardware ist getestet und bereit für die Installation.

princo wrote:"Kritisch" ist das Nichtvorhandensein von Gigabit-Ethernet, und daß bei der Übertragung WLAN-Strecken mit im Spiel sind. Dazu kommt, daß wir es mit relativ großen Datenmengen zu tun haben.

Aktuell sind keine WLAN-Strecken im Spiel.

Das wäre nur dann notwendig um einen PC bei meiner Freundin als Diskless-Station betreiben zu können. Da würde ich einen Access-Point im Client-Mode betreiben, da sich der diskless zu betreibende PC im Nachbarhaus befindet und nicht per LAn angebunden werden kann, da dazu durch zwei Decken gebohrt werden müsste. Das hat abolut keinerlei Priorität und wäre nur eine Spielerei mit der ich mich vielleicht beschäftige, wenn ich einmal Zeit und Luste dazu habe.

princo wrote:Warum kann das trotzdem klappen? Du hast darauf geachtet, daß dein System und die Daten auf getrennten Partitionen liegen. Dadurch bekommen wir ein kleines System-Image, und können die Daten als File-by-File-Backup sehr elegant (zeitsparend) übertragen.
Du hast bereits eine bestehende Backup-Lösung, und dir ist klar, daß fehlende Übertragungskapazität durch "Zeit" ausgeglichen wird. Dazu kommt, daß du über das ausreichende technisches Verständnis, sowie die notwendige Geduld und Übersicht verfügst, um so etwas durchzuziehen.

Princo, danke für die Blumen!

Zwischeninfo: Antwort ist in Arbeit.
Grüße
Princo

princo wrote:Das Wochenende habe ich dazu genutzt, die aktuelle NAS4Free Version 9.3.0.2.1391 zu testen. Sieht sehr gut aus, es hat alles funktioniert.

Inzwischen habe ich auch die Revision 1480 getestet.

raaalf wrote:Prima! Der USB-Stick mit NAS4Free 9.3.0.2.1391 (Embedded-Installation) ist vorbereitet und steckt bereits im internen USB-Port des N54L.

Vorab habe ich bereits die grundlegenden Dinge konfiguriert wie E-Mail-Report etc.

Damit hast du bereits eine Konfiguration vorgenommen.
Meine Idee war, daß ich dir einen kompletten Konfigurationssatz bereit stelle.
Dabei würde dein NAS komplett eingerichtet werden.
Also: Die nackten Platten würden in einem Pool zusammengefasst werden, es werden diverse Datasets angelegt, und am Ende wird eine genau definierte NAS4Free Konfigurationsdatei eingespielt.
Damit wäre jedoch jegliche Vorkonfiguration deinerseits hinfällig, und du müßtest sie erneut vornehmen.
Dieses Vorgehen würde jedoch eine evtl. notwendige Fehlersuche wesentlich erleichtern.

raaalf wrote:ECC-DRAM ist natürlich vorhanden, habe nur einen Spass gemacht. Ich habe bzw. hätte ein ungutes Gefühl, wenn eine Festplatte mit Bad Blocks im Einsatz wäre. Ich denke, so teuer sind Festplatten nicht (mehr), dass man sie nicht umgehend austauschen könnte sobald Bad Blocks auftauchen. Auch wenn dank der Besonderheiten von ZFS ist kein Datenverlust zu befürchten ist.

Den Spaß habe ich schon verstanden, aber ich mußte darauf entsprechend antworten, da es einige Leute gibt, die solche Postings gerne als Argument "gegen" ECC-RAM verwenden, i.S.v. "ist alles nicht so wild".

raaalf wrote:Dann wird es darauf hinauslaufen, dass sich mit der Zeit zeigen wird, ob sich die von mir gewählte RAID-Z2-Konfiguration bewährt was die zur Verfügunge stehende Kapazität betrifft. Ein RAID-Z2 ist mir für den Anwendungsfall eines "NAS-IMAGES" wichtig.

OK, so langsam verstehe ich.
Für mich ist dieses Projekt insofern wichtig, als daß ich darüber erfahre, wie andere Leute mit ihren Systemen umgehen. Und hier kommen wir gerade zu einem Kernpunkt.

raaalf wrote:Wenn nur eine externe Festplatte bzw., wie in meinem Fall, zwei externe Festplatten im "RAID-1-Modus für Arme" (die Master-Festplatte wurde regelmässig auf die Slave-Festplatte geklont) zur Verfügung steht muss man Kompromisse eingehen die ich nicht mehr eingehen will. Ich kann keine Priorisierung der auf den drei Notebooks gespeicherten Daten festlegen. Die Daten jedes Notebooks sind gleich wichtig, da unwiderbringlich.

Bingo!
Hiermit haben wir den den neuragilschen Punkt bei diesem Projekt ermittelt.
Nach meiner Philosophie gehören solche unwiederbringlichen Daten auf das Haupt-NAS.
Auf den Client-Rechnern arbeitet man nur mit Kopien dieser Daten.
In dieser Philosophie liegt der Schwerpunkt auf dem Haupt-NAS, und nicht auf den Clients.
Das Haupt-NAS wird durch ein Backup-NAS abgesichert.
Damit werden die Clients relativ unwichtig, und sind damit leicht austauschbar.

Um das zu verdeutlichen:
Ich photographiere z.B. recht gerne.
Die erzeugten Bilder lasse ich von den CF- oder SD-Karten auf meine diversen Client-Rechner überspielen. Dabei werden sie in eine bestimmte Dateisystemstruktur überführt.
Von dort aus verschiebe ich diese Dateien sofort auf mein Haupt-NAS.
Wenn ich diese Bilder bearbeiten möchte, kopiere ich sie mir vom Haupt-NAS auf einen Client-PC.
Die Ergebnisse dieser Bearbeitung werden wieder auf das Haupt-NAS verschoben.
Mit dieser Methode halte ich den Datenbestand auf den Client-Rechnern niedrig.
Im Idealfall befinden sich auf den Client-Rechnern nur die Bearbeitungsprogramme, aber kaum wichtige Daten (weil die ja auf dem Haupt-NAS sind).

Der tiefere Hintergrund dabei ist eigentlich ganz einfach:
Wenn ich meine Daten ausschließlich auf den Client-Rechnern bunkere, dann habe ich nur wenig Schutz vor unwillkürlicher Datenveränderung.
Das Problem ist, daß sich auf den Client-Systemen ungewollt Daten verändern können (z.B. durch Viren, durch schlechte Software, oder durch Hardwareprobleme, wie z.B. das Rotten-Disk-Syndrom)
Um das zu umgehen, transferiere ich wichtige Daten (z.B. Bilder, besser: eigene Werke) so schnell wie nur irgendmöglich auf mein Haupt-NAS.
Das Haupt-NAS ist in meiner Betrachtung ein "Safe-Place", welcher auch durch ein Backup-NAS abgesichert wird.

Anders verhält es sich mit Daten, welche "nur" (i.S.v. exclusiv) auf Client Rechnern vorgehalten werden.
Diesen Datenbestand versuche ich extrem niedrig zu halten.
Wie bereits erwähnt, sollten sich auf den Client-Rechnern langfristig keine unersetzlichen Daten befinden.
Das hängt natürlich auch stark von der persönlichen Arbeitsweise, und der Art der Daten ab.
Da du auf deinen Client-Rechnern einen ziemlich hohen Datenbestand (>500G) verwaltest, scheinst du das etwas anders zu handhaben.
Machbar ist das natürlich, aber ich würde das eher vermeiden wollen.
Bei "meiner" Backup-Methode hat das jedoch nur Einfluß auf das Erst-Backup (und natürlich auf ein Restore).

raaalf wrote:Ich denke, wenn auf Daten, Images, Backups von vor einem Jahr zurückgegriffen werden können ist das mehr als ausreichend.

Vorsicht!
Ich habe hier ein Szenario mit einer dedizierten Backup-Festplatte für ein einzelnes Gerät beschrieben.
In einer reinen NAS-Umgebung können sich völlig andere Verhältnisse einstellen.
Hier bevorzuge ich eine Backup-Speicherdauer von einer Woche (bei Systemen welche täglich genutzt werden).
Bei selten genutzten Systemen würde ich eine Speicherdauer von einem Monat empfehlen.
Mein Ansatz dabei ist, daß man sich gegen offensichtliche Fehlfunktionen absichert. Bei einem täglich genutzten Gerät werden diese recht schnell auffallen. Bei einem eher selten genutzten Gerät durchaus sehr viel später.
Eine Langzeitarchivierung von Client-Rechnern habe ich dabei weniger im Sinn, obwohl sie durchaus möglich ist.
Mit "Backup-Speicherdauer von einer Woche" ist gemeint, daß auf verschiedene Backup-Stände in dieser Woche zugegriffen werden kann. Wenn man also 14 Tage kein Backup macht, dann kann nur noch auf den letzten Backup-Stand zurückgegriffen werden, da die Backup-Stände quasi "gleitend" sind.
Wenn ein Client-PC defekt ist, oder irgendetwas an ihm seltsam erscheint (z.B. Virenbefall), dann wird man einfach die automatische Snapshot-Erstellung für diesen Client-PC anhalten, und hat alle Zeit der Welt, um das Problem zu lösen.

raaalf wrote:Ich verwende Linux bzw. Ubuntu nur auf einem älteren PC mit vormals Windows XP für den ich keine Windows-7-Lizenz habe und auf dem ASUS X51RL als "Dualboot" um damit Erfahrungen zu sammeln.
Seit meinen ersten Erfahrungen mit Linux von vor 20 Jahren, als man den Kernel noch selbst kompilieren musste und dies nicht unbedingt für Anfänger so einfach war, habe ich nichts mehr damit zu tun gehabt. Da Linux aber praktisch überall drinsteckt sind Linux-Kenntnisse immer hilfreich. Leider mangelt es mir an über das grundlegende, einfachste hinausgehende Kenntnisse.

Ich habe die Entwicklung von Windows und Linux über die Jahrzehnte hinweg verfolgt. Windows fand ich aus diversen Gründen irgendwie immer doof, und Linux war am Anfang für den Endanwender immer viel zu kompliziert.
Mit Ubuntu ist da glücklicherweise ordentlich Drive in die Angelegenheit gekommen.
Leider hat sich Ubuntu im Bereich der Bedieneroberfläche in eine Richtung entwickelt, welche mir überhaupt nicht gefällt.
Daher bin ich vor einiger Zeit auf die Distribution "Linux Mint" umgeschwenkt. Die basiert auf Ubuntu, daher kann man prima auf die Ubuntu-Dokumentation zurückgreifen, bietet aber eine viel bessere Bedieneroberfläche an.

Welche Linux Distribution man einsetzt, ist für das Backup zum Glück egal. Linux läßt sich generell viel einfacher backuppen, als Windows.

Was mich bei Windows so richtig angepisst hat: bei Windows 7 kann man nur bei der Professional und der Enterprise Version eine Datensicherung über das Netzwerk machen. Bei Windows Home geht das z.B. nicht, sondern nur mit lokalen Datenträgern.

Was soll denn bitte dieser Blödsinn? Da haben irgendwelche Marketing-Fuzzis eine essentiell wichtige Funktionalität beschnitten. Das ist nicht gerade professionell, und sowas bringt mir die Galle hoch.

raaalf wrote:Die Übertragungsraten mit den Powerline-Adaptern waren extrem schlecht. Wenn die FRITZ!Box 7270 nicht das Problem hätte, dass die CPU bei der Übertragung von etlichen GByte per WLAN überhitzt und in Folge dessen neu gebootet werden muss, würde die Sache mit dem Access-Point im Client-Mode einwandfrei funktionieren. Aber das betrifft die Netzwerkinstallation bei meiner Freundin, wo auch der Anwendungsfall für eine Diskless-Station wäre. Bei mir sind alle Notebooks während des Backups bzw. der Imageerstellung per LAN angebunden.

Komisch, meine alte 7170 ist nur dann ausgestiegen, wenn sie gleichzeitig zuviele Verbindungen handlen sollte (z.B. bei P2P-Anwendungen). Das konnte ich aber mit den richtigen Einstellungen bändigen.
Allerdings ist mir dort auch mal das Netzteil abgeraucht, und mit dem neuen Netzteil (nicht von AVM), wurde die Box etwas instabiler.

raaalf wrote:Ich möchte in diesem Thread kein Durcheinander verursachen und werde deshalb nur noch vom aktuellen Fall (NAS-IMAGES) sprechen und nicht mehr die Installation bei meiner Freundin zur Sprache bringen.

Notiert

raaalf wrote:Gibt es noch offene Fragen die geklärt werden müssen? Die Hardware ist getestet und bereit für die Installation.

Die Zwischenzeit habe ich genutzt, und mein PCIMAGE-NAS auf die Version 9.3.0.2 (revision 1480) umgestellt. Dabei habe ich besonders auf die nun mögliche Komprimierungsart "lz4" getestet, und bin angenehm überrascht worden. Mit dieser Kompressionsmethode läßt sich tatsächlich die Übertragungszeit verringern, und es gibt eine signifikante Platzersparnis.
Gut, die Übertragungszeit spielt bei deiner Infrastruktur keine Rolle, aber die Platzersparnis wird sich durchaus auswirken.

raaalf wrote:Aktuell sind keine WLAN-Strecken im Spiel.

Das wäre nur dann notwendig um einen PC bei meiner Freundin als Diskless-Station betreiben zu können. Da würde ich einen Access-Point im Client-Mode betreiben, da sich der diskless zu betreibende PC im Nachbarhaus befindet und nicht per LAn angebunden werden kann, da dazu durch zwei Decken gebohrt werden müsste. Das hat abolut keinerlei Priorität und wäre nur eine Spielerei mit der ich mich vielleicht beschäftige, wenn ich einmal Zeit und Luste dazu habe.

Prinzipiell kann das durchaus funktionieren, aber so richtig Spaß wird das nicht machen.
Ich probiere soetwas ähnliches gerade mit einer Openelec-Installation aus, welche per Powerline-Adapter (100Mb/s) angebunden ist. Im Großen und Ganzen ist das relativ brauchbar, aber es gibt dabei manchmal recht derbe Wartezeiten.

princo wrote:Warum kann das trotzdem klappen? Du hast darauf geachtet, daß dein System und die Daten auf getrennten Partitionen liegen. Dadurch bekommen wir ein kleines System-Image, und können die Daten als File-by-File-Backup sehr elegant (zeitsparend) übertragen.
Du hast bereits eine bestehende Backup-Lösung, und dir ist klar, daß fehlende Übertragungskapazität durch "Zeit" ausgeglichen wird. Dazu kommt, daß du über das ausreichende technisches Verständnis, sowie die notwendige Geduld und Übersicht verfügst, um so etwas durchzuziehen.

raaalf wrote:Princo, danke für die Blumen!

Das sollte man durchaus mal loben. Ist nicht so häufig, daß sich jemand ernsthaft mit dem Thema Backup auseinander setzt.

Hallo Princo,

Princo wrote:Das Wochenende habe ich dazu genutzt, die aktuelle NAS4Free Version 9.3.0.2.1391 zu testen. Sieht sehr gut aus, es hat alles funktioniert. Inzwischen habe ich auch die Revision 1480 getestet.

das Image der Revision 1480 ist auf den USB-Stick des NAS-IMAGES kopiert.

princo wrote:Meine Idee war, daß ich dir einen kompletten Konfigurationssatz bereit stelle. Dabei würde dein NAS komplett eingerichtet werden.
Also: Die nackten Platten würden in einem Pool zusammengefasst werden, es werden diverse Datasets angelegt, und am Ende wird eine genau definierte NAS4Free Konfigurationsdatei eingespielt.
Damit wäre jedoch jegliche Vorkonfiguration deinerseits hinfällig, und du müßtest sie erneut vornehmen.
Dieses Vorgehen würde jedoch eine evtl. notwendige Fehlersuche wesentlich erleichtern.

Alles klar. Einfacher und "idiotensicherer" kann die Konfiguration des NAS ja nicht sein. Perfekt!!!
Es ist natürlich kein Problem, wenn nach dem Durchlauf Deines Konfigurationssatzes die paar Einstellungen, die ich gemacht habe, nochmal gemacht werden müssen. Bzw. würde ich erst dann die Konfiguration ändern wenn alles so läuft wie es soll. So kann ausgeschlossen werden, dass ich unbeabsichtigt Fehler einbaue.

princo wrote:Bingo! Hiermit haben wir den den neuragilschen Punkt bei diesem Projekt ermittelt. Nach meiner Philosophie gehören solche unwiederbringlichen Daten auf das Haupt-NAS. Auf den Client-Rechnern arbeitet man nur mit Kopien dieser Daten.

Dein Ansatz ist auch aus meiner Sicht der richtige.

Allerdings, und hier kommen wir zu meinem "Problem" bzw. dem Grund, weshalb ich die Daten auf den Clients vorhalten muss, funktioniert die zentrale Datenhaltung auf dem NAS nur dann, wenn man auch Zugriff auf das NAS hat.
Ich bin Wochenendpendler und müsste sowohl bei mir als auch bei meiner Partnerin einen jeweils identischen Satz an NASen zur Verfügung haben. Auf Grund dessen, dass ich bei meiner Partnerin keinen Zugriff auf mein NAS habe muss ich die Daten auf den Clients (Notebooks) mitnehmen.
Wenn in Deutschland der Breitbandausbau in ländlichen Gegenden nicht so erbärmlich wäre - bei meiner Partnerin sind das Höchste der Gefühle gigantische 2,3 MBit/s Downstream, und daran wir sich auf laaange Sicht auch nichts ändern, da die Gemeinde einen regionalen Internetprovider bei der Installation eines Outdoor-DSLAMs finaziell unterstützte - wäre das kein Problem. Von der Telekom wird DSLlight angeboten...
Stünde ein DSL-Anschluß mit einer ernstzunehmenden Bandbreite zur Verfügung, könnte ich per OpenVPN (okay, erstmal konfigurieren können) einen Tunnel zu meinem NAS aufbauen. So bleibt mir nichts anderes übrig, als die Daten auf den Clients (Notebooks) vorzuhalten.

princo wrote:In einer reinen NAS-Umgebung können sich völlig andere Verhältnisse einstellen. Hier bevorzuge ich eine Backup-Speicherdauer von einer Woche (bei Systemen welche täglich genutzt werden).
Bei selten genutzten Systemen würde ich eine Speicherdauer von einem Monat empfehlen.
Mein Ansatz dabei ist, daß man sich gegen offensichtliche Fehlfunktionen absichert. Bei einem täglich genutzten Gerät werden diese recht schnell auffallen. Bei einem eher selten genutzten Gerät durchaus sehr viel später.
Eine Langzeitarchivierung von Client-Rechnern habe ich dabei weniger im Sinn, obwohl sie durchaus möglich ist.
Mit "Backup-Speicherdauer von einer Woche" ist gemeint, daß auf verschiedene Backup-Stände in dieser Woche zugegriffen werden kann. Wenn man also 14 Tage kein Backup macht, dann kann nur noch auf den letzten Backup-Stand zurückgegriffen werden, da die Backup-Stände quasi "gleitend" sind.
Wenn ein Client-PC defekt ist, oder irgendetwas an ihm seltsam erscheint (z.B. Virenbefall), dann wird man einfach die automatische Snapshot-Erstellung für diesen Client-PC anhalten, und hat alle Zeit der Welt, um das Problem zu lösen.

Wie bzw. wo wird die Speicherdauer eines Backups eingestellt bzw. kann diese "einfach" geändert werden, um nach einer Testphase reagieren zu können? Über die Speicherdauer der Backups muss ich mir noch Gedanken machen.

princo wrote:Was mich bei Windows so richtig angepisst hat: bei Windows 7 kann man nur bei der Professional und der Enterprise Version eine Datensicherung über das Netzwerk machen. Bei Windows Home geht das z.B. nicht, sondern nur mit lokalen Datenträgern.

Was soll denn bitte dieser Blödsinn? Da haben irgendwelche Marketing-Fuzzis eine essentiell wichtige Funktionalität beschnitten. Das ist nicht gerade professionell, und sowas bringt mir die Galle hoch.

Warum Microsoft die Windows-7-Versionen teilweise extrem beschneidet (warum kann bei Windows 7 Starter nichteinmal der Desktophintergrund geändert werden?) weiß ich auch nicht. Deine Verärgerung darüber kann ich sehr gut nachvollziehen.

Auch wenn berechtigterweise viel über Windows bzw. Microsoft geschimpft wird muss man Bill Gates eines zugutehalten: Wo wäre die PC-Welt ohne Standards wie MS-DOS und Windows bzw. "Monopole"?
Oder, anders herum, warum war der IBM-PC trotz seiner Unzulänglichkeiten und der hohen Anschaffungskosten für IBM ein voller Erfolg? Doch deshalb, weil die Kunden wussten, dass IBM einen Industriestandard setzen wird und die Investition in die teuere Hardware zukunftsfähig ist, da Soft- und Hardware dafür entwickelt werden wird.
Es reicht nicht die "bessere" Hard- oder Software zu entwickeln wenn sie am Markt keine Bedeutung hat weil die Soft- oder Hardwareentwickler kein Vertrauen haben können, dass sich das System durchsetzen wird. Aber das ist ein anderes Thema.

princo wrote:Komisch, meine alte 7170 ist nur dann ausgestiegen, wenn sie gleichzeitig zuviele Verbindungen handlen sollte (z.B. bei P2P-Anwendungen). Das konnte ich aber mit den richtigen Einstellungen bändigen. Allerdings ist mir dort auch mal das Netzteil abgeraucht, und mit dem neuen Netzteil (nicht von AVM), wurde die Box etwas instabiler.

Das Hitzproblem bei der FRITZ!Box 7270 habe ich mit einem temperaturgesteuerten Lüfter behoben. Nach dem Abgleich des NAS-PRODUKTIV mit dem NAS-BACKUP mit entsprechenden Datenmengen sollte das Problem ohnehin nicht mehr auftreten, da nur mehr geringe Datenmengen abgeglichen werden müssen. Aber, das betrifft die Installation bei meiner Partnerin! Ups, jetzt habe ich wieder über die Installation bei meiner Partnerin geschrieben. Das war jetzt aber das letzte Mal in diesem Thread.

princo wrote:Das sollte man durchaus mal loben. Ist nicht so häufig, daß sich jemand ernsthaft mit dem Thema Backup auseinander setzt.

Backup/Datensicherung mache ich "schon immer". Zumindest seit dem Umstieg auf einen IBM-kompatiblen PC. Zu Zeiten von Windows 3.1 auf einem 386SX-20 mit 9 MByte RAM habe ich Backups auf DC2120-Bänder erstellt. Dabei wurde am Sonntag ein vollständiges Backup gemacht und jeden Wochentag ein inkrementelles. Und im Wochenrhythmus wurden die vorhandenen zwei Sätze an DC2120-Bändern gewechselt. Lang, lang ist es her... Weiter ging es mit der Erstellung von Images auf USB-Festplatten mit Ghost und später, als Ghost meiner Meinung nach immer schlechter wurde, mit TrueImage.

Grüß Dich Princo,

princo wrote:Vorsicht!
In einer reinen NAS-Umgebung können sich völlig andere Verhältnisse einstellen.
Hier bevorzuge ich eine Backup-Speicherdauer von einer Woche (bei Systemen welche täglich genutzt werden).
Bei selten genutzten Systemen würde ich eine Speicherdauer von einem Monat empfehlen.
Mein Ansatz dabei ist, daß man sich gegen offensichtliche Fehlfunktionen absichert. Bei einem täglich genutzten Gerät werden diese recht schnell auffallen. Bei einem eher selten genutzten Gerät durchaus sehr viel später.
Eine Langzeitarchivierung von Client-Rechnern habe ich dabei weniger im Sinn, obwohl sie durchaus möglich ist.
Mit "Backup-Speicherdauer von einer Woche" ist gemeint, daß auf verschiedene Backup-Stände in dieser Woche zugegriffen werden kann. Wenn man also 14 Tage kein Backup macht, dann kann nur noch auf den letzten Backup-Stand zurückgegriffen werden, da die Backup-Stände quasi "gleitend" sind.
Wenn ein Client-PC defekt ist, oder irgendetwas an ihm seltsam erscheint (z.B. Virenbefall), dann wird man einfach die automatische Snapshot-Erstellung für diesen Client-PC anhalten, und hat alle Zeit der Welt, um das Problem zu lösen.

Nachtrag zu dem Thema Speicherdauer der Backups. Bei dem täglich genutzten PC sind 14 Tage sicher zweckmässig, wobei mir länger immer lieber ist solange die dafür notwendige Festplattenkapazität zur Verfügung steht.
Allerdings habe ich auch PCs die nur selten genutzt werden. Beispielsweise das Notebook zum Encoden von Audio-CDs und für die Speicherung und "Nachbearbeitung" von Fotos. Dieses Notebook wird unter Umständen monatelang nicht genutzt, vom sporadischem Einschalten zum Einspielen von Windows-Updates einmal abgesehen. Hier wäre eine lange Haltezeit der Backups wichtig.

Guten Abend,

ich habe ein Problem mit rsync. Ich nutze rsync unter Windows 10 mittels Cygwin um die Daten der Partition D:\ auf das NAS zu sichern. Ich verwende die aktuelle Cygwin-Version (vergangene Woche heruntergeladen). Der Aufruf ist:

--exclude=/cygdrive/d/$RECYCLE.BIN/ --exclude=/cygdrive/d/System\ Volume\ Information/ --checksum --progress --stats --human-readable --verbose --verbose --log-file=/cygdrive/d/NAS-Logfiles/Partition_D.log

Der Windows-Papierkorb ($RECYCLE.BIN) und die Daten des "Systemschutz für lokale Laufwerke" (System Volume Information) sollen nicht mitgesichert werden. Die entsprechenden Optionen

--exclude=/cygdrive/d/$RECYCLE.BIN/ --exclude=/cygdrive/d/System\ Volume\ Information/

führen leider nicht zum Erfolg. Ich habe alle möglichen Varianten durch: Mit Hochkomma (--exclude='/cygdrive/d/$RECYCLE.BIN/'), mit Anführungszeichen (--exclude="/cygdrive/d/$RECYCLE.BIN/"), mit oder ohne Schrägstrich am Ende (--exclude=/cygdrive/d/$RECYCLE.BIN/, --exclude=/cygdrive/d/$RECYCLE.BIN) etc.

Das Logfile wird jedoch korrekt angelegt (--log-file=/cygdrive/d/NAS-Logfiles/Partition_D.log).

Hat jemand das Problem in den Griff bekommen bzw. kennt den korrekten Syntax und kann mir einen Tipp geben?

Grüße

Ralf