Hallo allerseits, ich habe mir ein trueNAS -Server als Backupdevice aufgesetzt. Leider dauert das Backup via rsnapshot nun 4-5 mal solange (d.h. ca. 16 Stunden!) wie mit der vorigen Lösung (einem in die Jahre gekommenen qnap-NAS). Dazu mounte ich das ZFS-Backup-Verzeichnis via NFS in den zu sichernden Server. rsnapshot schreibt dann auf das NFS-Filesystem. - Der PC hat 64GB RAM - also eigentlich genug und ist auch ausreichend schnell. - ZFS belegt davon 50MB RAM - Das Netzwerk dümpelt die meiste Zeit so mit ein einstelligen Mbit/s 'rum (bis zu 1000 ganz zu Beginn, wenn die VMware-Images "herumgeschaufelt" werden) - Ich nutzte openSUSE 15.5, und nutze btrfs für / und /home. Anscheinend geht's nicht nur mir so, sondern auch anderen (via google-Suche). Irgendwie scheint es an ZFS zu liegen. Was kann ich denn nun machen? Bin für jede Hilfe dankbar. Bye Jürgen -- Dr.rer.nat. Jürgen Vollmer, Am Rennbuckel 21, D-76185 Karlsruhe Tel: +49(721) 92 04 87 1 Fax: +49(721) 92 04 87 2 Juergen.Vollmer@informatik-vollmer.de www.informatik-vollmer.de
Dr. Juergen Vollmer schrieb:
ich habe mir ein trueNAS -Server als Backupdevice aufgesetzt. Leider dauert das Backup via rsnapshot nun 4-5 mal solange (d.h. ca. 16 Stunden!) wie mit der vorigen Lösung (einem in die Jahre gekommenen qnap-NAS). Dazu mounte ich das ZFS-Backup-Verzeichnis via NFS in den zu sichernden Server. rsnapshot schreibt dann auf das NFS-Filesystem.
- Der PC hat 64GB RAM - also eigentlich genug und ist auch ausreichend schnell. - ZFS belegt davon 50MB RAM - Das Netzwerk dümpelt die meiste Zeit so mit ein einstelligen Mbit/s 'rum (bis zu 1000 ganz zu Beginn, wenn die VMware-Images "herumgeschaufelt" werden) - Ich nutzte openSUSE 15.5, und nutze btrfs für / und /home.
Anscheinend geht's nicht nur mir so, sondern auch anderen (via google-Suche).
Verstehe ich das recht, dass das ein File-Level-Backup ist? Dann liegt es an NFS. Öffnen und Schließen von Files sind bei NFS nun mal konzeptbedingt sehr "teure" Operationen, die einfach überproportional Zeit kosten. Und beim File-Level-Backup müssen nun mal Hunderttausende, wenn nicht Millionen Files geöffnet und geschlossen werden. Das multipliziert sich. Für diese These spricht auch, dass Image-Dateien ja schnell übertragen werden, denn das sind ja große Dateien, da "dominiert" im Zeitverbrauch die eigentliche Übertragung. Bei vielen kleinen Dateien verhält sich NFS wie von Dir geschildert, das Netzwerk ist einfach nicht ausgelastet und es geht trotzdem nicht voran. Versuch mal "spaßeshalber" einen großen Tarball auf einem NFS-Volume auszupacken (z.B. die Linux-Kernel-Sources), da hast Du das Problem auch. Das geht etwa hundertmal langsamer als auf einem lokalen Volume. Ich hatte auch mal lange mit NFS rumexperimentiert, sogar zwischen VMs auf demselben Host, weil ich mehreren VMs denselben Datenpool zur Verfügung stellen wollte, was aber von der Performance her nie wirklich funktioniert hat (trotz paravirtualisiertem Netzwerktreiber, der locker gemessene 10 bis 20 Gbit/s bringen konnte). Ich habe vieles ausprobiert, aber keine der empfohlenen Tuning-Maßnahmen hat nennenswert was gebracht. Ich habe es schließlich aufgegeben, weil Nutzen und Nachteile durch die schlechte Performance einfach nicht in einem gesunden Verhältnis standen. Es gab zwar viele Leute, die meinten, so schlecht könne doch NFS gar nicht sein und ich müsse da doch was falsch machen, aber die vielen Berichte aus dem Internet (die selten eine Erklärung finden und wenn dann nicht die richtige) sprechen da eine andere Sprache. Wenn das NAS es anbietet, könntest Du mal CIFS ausprobieren, das ist für Backups erfahrungsgemäß etwas schneller als NFS. Wenn auf dem NAS genug Platz ist und auf den Partitionen nicht zu viel Leerstand ist oder man vor der Netzwerk-Übertragung schon komprimiert, kann man es noch mit Image-Backups probieren. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Hallo Manfred Am Samstag, 21. Oktober 2023, 08:10:47 CEST schrieb Manfred Haertel, DB3HM:
Dr. Juergen Vollmer schrieb:
ich habe mir ein trueNAS -Server als Backupdevice aufgesetzt. Leider dauert das Backup via rsnapshot nun 4-5 mal solange (d.h. ca. 16 Stunden!) wie mit der vorigen Lösung (einem in die Jahre gekommenen qnap-NAS). Dazu mounte ich das ZFS-Backup-Verzeichnis via NFS in den zu sichernden Server. rsnapshot schreibt dann auf das NFS-Filesystem.
- Der PC hat 64GB RAM - also eigentlich genug und ist auch ausreichend schnell. - ZFS belegt davon 50MB RAM - Das Netzwerk dümpelt die meiste Zeit so mit ein einstelligen Mbit/s 'rum (bis zu 1000 ganz zu Beginn, wenn die VMware-Images "herumgeschaufelt" werden) - Ich nutzte openSUSE 15.5, und nutze btrfs für / und /home.
Anscheinend geht's nicht nur mir so, sondern auch anderen (via google-Suche).
Verstehe ich das recht, dass das ein File-Level-Backup ist?
ja, damit habe ich tageweise backup's und kann einzelne Dateien aus den vergangenen Backups "herausholen". rsnapshot basiert auf rsync.
Dann liegt es an NFS. Öffnen und Schließen von Files sind bei NFS nun mal konzeptbedingt sehr "teure" Operationen, die einfach überproportional Zeit kosten. Und beim File-Level-Backup müssen nun mal Hunderttausende, wenn nicht Millionen Files geöffnet und geschlossen werden. Das multipliziert sich.
schon, aber warum ging es mit dem einfachen QNAP-NAS (1GB RAM, und laaangsamer Prozessor) und ansonsten gleichen setup (NFS, rsnapshot) 4-5 mal schneller?
Für diese These spricht auch, dass Image-Dateien ja schnell übertragen werden, denn das sind ja große Dateien, da "dominiert" im Zeitverbrauch die eigentliche Übertragung.
Bei vielen kleinen Dateien verhält sich NFS wie von Dir geschildert, das Netzwerk ist einfach nicht ausgelastet und es geht trotzdem nicht voran.
Versuch mal "spaßeshalber" einen großen Tarball auf einem NFS-Volume auszupacken (z.B. die Linux-Kernel-Sources), da hast Du das Problem auch. Das geht etwa hundertmal langsamer als auf einem lokalen Volume.
Ich hatte auch mal lange mit NFS rumexperimentiert, sogar zwischen VMs auf demselben Host, weil ich mehreren VMs denselben Datenpool zur Verfügung stellen wollte, was aber von der Performance her nie wirklich funktioniert hat (trotz paravirtualisiertem Netzwerktreiber, der locker gemessene 10 bis 20 Gbit/s bringen konnte). Ich habe vieles ausprobiert, aber keine der empfohlenen Tuning-Maßnahmen hat nennenswert was gebracht. Ich habe es schließlich aufgegeben, weil Nutzen und Nachteile durch die schlechte Performance einfach nicht in einem gesunden Verhältnis standen.
Es gab zwar viele Leute, die meinten, so schlecht könne doch NFS gar nicht sein und ich müsse da doch was falsch machen, aber die vielen Berichte aus dem Internet (die selten eine Erklärung finden und wenn dann nicht die richtige) sprechen da eine andere Sprache.
Wenn das NAS es anbietet, könntest Du mal CIFS ausprobieren, das ist für Backups erfahrungsgemäß etwas schneller als NFS.
was ich so finde (z.B. -> ihttps://aws.amazon.com/de/compare/the-difference-between-nfs-and-cifs) ist cifs langsamer...
Wenn auf dem NAS genug Platz ist und auf den Partitionen nicht zu viel Leerstand ist oder man vor der Netzwerk-Übertragung schon komprimiert, kann man es noch mit Image-Backups probieren.
Bye Jürgen -- Dr.rer.nat. Jürgen Vollmer, Am Rennbuckel 21, D-76185 Karlsruhe Tel: +49(721) 92 04 87 1 Fax: +49(721) 92 04 87 2 Juergen.Vollmer@informatik-vollmer.de www.informatik-vollmer.de ------------------------------------------------------------------------------- Diese EMail ist elektronisch mittels GPG / PGP signiert. Diese elektronische Unterschrift ist in einem EMail-Anhang enthalten. Leider kann die Signatur ohne die Installation entsprechender Programme weder geprüft noch angezeigt werden. Mehr dazu unter: http://www.gnupg.org oder auch http://www.pgpi.org -------------------------------------------------------------------------------
Dr. Juergen Vollmer schrieb:
Dann liegt es an NFS. Öffnen und Schließen von Files sind bei NFS nun mal konzeptbedingt sehr "teure" Operationen, die einfach überproportional Zeit kosten. Und beim File-Level-Backup müssen nun mal Hunderttausende, wenn nicht Millionen Files geöffnet und geschlossen werden. Das multipliziert sich.
schon, aber warum ging es mit dem einfachen QNAP-NAS (1GB RAM, und laaangsamer Prozessor) und ansonsten gleichen setup (NFS, rsnapshot) 4-5 mal schneller?
Möglicherweise gibt es noch einen Effekt. Kann es sein, dass das alte NAS auf Festplatte(n) basiert und das neue auf SSD(s) und beim Backup einfach die Cache-Größe der SSD überschritten wurde? Dann sind viele SSDs nämlich sogar langsamer als Festplatten. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Hallo Manfred Am Samstag, 21. Oktober 2023, 13:28:03 CEST schrieb Manfred Haertel, DB3HM:
Dr. Juergen Vollmer schrieb:
Dann liegt es an NFS. Öffnen und Schließen von Files sind bei NFS nun mal konzeptbedingt sehr "teure" Operationen, die einfach überproportional Zeit kosten. Und beim File-Level-Backup müssen nun mal Hunderttausende, wenn nicht Millionen Files geöffnet und geschlossen werden. Das multipliziert sich.
schon, aber warum ging es mit dem einfachen QNAP-NAS (1GB RAM, und laaangsamer Prozessor) und ansonsten gleichen setup (NFS, rsnapshot) 4-5 mal schneller?
Möglicherweise gibt es noch einen Effekt. Kann es sein, dass das alte NAS auf Festplatte(n) basiert und das neue auf SSD(s) und beim Backup einfach die Cache-Größe der SSD überschritten wurde? Dann sind viele SSDs nämlich sogar langsamer als Festplatten.
ich habe die beiden 14TB Festplatten aus dem alten NAS in das neue eingebaut und noch danach noch eine SSD als zusätzlichen Cache. Die SSD hat aber am Zeitverhalten nichts geändert. Bye Jürgen -- Dr.rer.nat. Jürgen Vollmer, Am Rennbuckel 21, D-76185 Karlsruhe Tel: +49(721) 92 04 87 1 Fax: +49(721) 92 04 87 2 Juergen.Vollmer@informatik-vollmer.de www.informatik-vollmer.de ------------------------------------------------------------------------------- Diese EMail ist elektronisch mittels GPG / PGP signiert. Diese elektronische Unterschrift ist in einem EMail-Anhang enthalten. Leider kann die Signatur ohne die Installation entsprechender Programme weder geprüft noch angezeigt werden. Mehr dazu unter: http://www.gnupg.org oder auch http://www.pgpi.org -------------------------------------------------------------------------------
Am Freitag, 20. Oktober 2023, 16:21:03 CEST schrieb Dr. Juergen Vollmer:
Hallo allerseits,
ich habe mir ein trueNAS -Server als Backupdevice aufgesetzt. Leider dauert das Backup via rsnapshot nun 4-5 mal solange (d.h. ca. 16 Stunden!) wie mit der vorigen Lösung (einem in die Jahre gekommenen qnap-NAS). Dazu mounte ich das ZFS-Backup-Verzeichnis via NFS in den zu sichernden Server. rsnapshot schreibt dann auf das NFS-Filesystem. [...]
Und das hast du abgesehen von ZFS auf dem NAS vorher ganz genauso gemacht? Ich kenne mich konkret mit trueNAS zwar nicht aus aber das was du da machst klingt nach einer eher schlechten Idee. Warum? Manfred schrieb ja schon, dass bei NFS Öffnen und Schließen "teure" Operationen sind. Und rsnapshot benutzt im Hintergrund rsync um die geänderten Dateien zu kopieren und die restlichen zu verlinken. Wie stellt rsync denn eigentlich fest, welche Dateien sich geändert haben? rsync macht sich das Leben zwar einfach und vergleicht per Default nur Zeitstempel und Größe aber mit Manfreds Erklärung im Hinterkopf ist das aber immer noch mühsam: Es werden alle, also sehr viele, Dateien übers Netzwerk gescannt und sehr viele Hardlinks angelegt aber kaum Daten übertragen, was dem von dir beobachteten Verhalten entspricht. Deswegen möchte ich rsync so nicht benutzen. Viel geschickter finde ich es, auf dem NAS beispielsweise per SSH ein zweites rsync zu starten (-e "ssh") was dort dieses Scannen übernehmen kann. So laufen beide rsync lokal und können mit der maximalen Geschwindigkeit arbeiten. Tatsächlich übertragen werden dann nur die Dateilisten und die geänderten oder neuen Daten. Hier ein Beispiel von einem rsync Lauf auf's NAS bei dem keine Änderungen anstehen: jan@karl:~> rsync_jan_wichtige_dokumente.sh sending incremental file list sent 240,606 bytes received 772 bytes 11,774.54 bytes/sec total size is 2,355,483,377 speedup is 9,758.48 (DRY RUN) Und rsnapshot benutze ich schon lange nicht mehr sondern bin auf storeBackup umgestiegen das hier auf einem ext4 arbeitet, das in einem LUKS- verschlüsselten liegt. In einem iSCSI-LUN auf dem NAS. Über WLAN. Das ist trotzdem ziemlich schnell. Mit einem echten Netzwerkprotokoll wie NFS sollte es nicht langsamer sein. Die deutsche storeBackup Dokumentation hat einen Abschnitt über Performance bei NFS, eben wegen der oben beschriebenen prinzipiellen Problem. Vielleicht ist da was für dich dabei. Sonst bleibt wirklich nur noch ZFS als Ursache übrig... Viele Grüße Jan -- Problems are only Opportunities in Disguise.
Hallo, Am 21.10.2023 um 16:29 schrieb Jan Ritzerfeld:
Am Freitag, 20. Oktober 2023, 16:21:03 CEST schrieb Dr. Juergen Vollmer:
Hallo allerseits,
[...]
Und rsnapshot benutze ich schon lange nicht mehr sondern bin auf storeBackup umgestiegen das hier auf einem ext4 arbeitet, das in einem LUKS- verschlüsselten liegt. In einem iSCSI-LUN auf dem NAS. Über WLAN. Das ist trotzdem ziemlich schnell. Mit einem echten Netzwerkprotokoll wie NFS sollte es nicht langsamer sein. Die deutsche storeBackup Dokumentation hat einen Abschnitt über Performance bei NFS, eben wegen der oben beschriebenen prinzipiellen Problem. Vielleicht ist da was für dich dabei. Sonst bleibt wirklich nur noch ZFS als Ursache übrig...
Viele Grüße Jan
Ich kann zu diesem Thema leider nicht viel Erhellendes beitragen. Vor vielen Jahren hatte ich auch rsnapshot zum Backup über Netzwerk verwendet, hatte ich hier auch schon mal berichtet. Das wurde mir aber dann viel zu lahm und ich habe nun eine eigene Backuplösung mit ZFS als Filesystem, eigenes Skript (rsynapshot angenähert) und die einzelnen Backups gehen in Snapshots. Der eigentliche Transfer wird von rsync erledigt. Ein Backup löschen -> Snapshot loschen -> ruckzuck weg. Keine Millionen von Hardlinks müssen entfernt werden. Das ist bis heute sehr performant. rsnapshot mit seinen Millionen von Hardlinks ist in meinen Augen völliger Müll Manfred
Am Sa., 21. Okt. 2023 um 17:32 Uhr schrieb Manfred Kreisl
Vor vielen Jahren hatte ich auch rsnapshot zum Backup über Netzwerk verwendet, hatte ich hier auch schon mal berichtet.
Das wurde mir aber dann viel zu lahm und ich habe nun eine eigene Backuplösung mit ZFS als Filesystem, eigenes Skript (rsynapshot
Hier läuft seit Jahrzehnten rsnapshot, allerdings im Pull-Modus über rsync/ssh. Gruß Martin
Hallo Manfred, Am Samstag, 21. Oktober 2023, 17:32:33 CEST schrieb Manfred Kreisl:
Das wurde mir aber dann viel zu lahm und ich habe nun eine eigene Backuplösung mit ZFS als Filesystem, eigenes Skript (rsynapshot angenähert) und die einzelnen Backups gehen in Snapshots. Der eigentliche Transfer wird von rsync erledigt. Ein Backup löschen -> Snapshot loschen -> ruckzuck weg. Keine Millionen von Hardlinks müssen entfernt werden. Das ist bis heute sehr performant.
kannst Du mir mal das Script schicken?
rsnapshot mit seinen Millionen von Hardlinks ist in meinen Augen völliger Müll
klar, aber war einfach auf dem alten NAS eine einfache Lösung, und ich hatte daily-Backups in denen ich nachschauen konnte, ohne groß was auspacken zu müssen. Und Platzsparend wegen der lardlinks. Klar war nicht immer super performant, aber ausreichend schnell. Jetzt aber mit ZFS, .., Ich hab' auch folgendes überlegt: a) ZFS-snapshots als Grundlage benutzen (anstatt der hardlinks) und dann mit rsync die geänderten Dateien drüber'er schreiben b) rsync <-> rsync (Quellsystem <-> NAS), damit habe ich aber noch keine Erfahrung . Bye Jürgen -- Dr.rer.nat. Jürgen Vollmer, Am Rennbuckel 21, D-76185 Karlsruhe Tel: +49(721) 92 04 87 1 Fax: +49(721) 92 04 87 2 Juergen.Vollmer@informatik-vollmer.de www.informatik-vollmer.de ------------------------------------------------------------------------------- Diese EMail ist elektronisch mittels GPG / PGP signiert. Diese elektronische Unterschrift ist in einem EMail-Anhang enthalten. Leider kann die Signatur ohne die Installation entsprechender Programme weder geprüft noch angezeigt werden. Mehr dazu unter: http://www.gnupg.org oder auch http://www.pgpi.org -------------------------------------------------------------------------------
Am 22.10.2023 um 15:14 schrieb Dr. Juergen Vollmer:
Hallo Manfred,
Am Samstag, 21. Oktober 2023, 17:32:33 CEST schrieb Manfred Kreisl:
Das wurde mir aber dann viel zu lahm und ich habe nun eine eigene Backuplösung mit ZFS als Filesystem, eigenes Skript (rsynapshot angenähert) und die einzelnen Backups gehen in Snapshots. Der eigentliche Transfer wird von rsync erledigt. Ein Backup löschen -> Snapshot loschen -> ruckzuck weg. Keine Millionen von Hardlinks müssen entfernt werden. Das ist bis heute sehr performant.
kannst Du mir mal das Script schicken?
Kann ich gerne mal tun, Dienstag wenn der Backup wieder läuft und ich es nicht vergesse ;)
rsnapshot mit seinen Millionen von Hardlinks ist in meinen Augen völliger Müll
klar, aber war einfach auf dem alten NAS eine einfache Lösung, und ich hatte daily-Backups in denen ich nachschauen konnte, ohne groß was auspacken zu müssen.
Und Platzsparend wegen der lardlinks.
Klar war nicht immer super performant, aber ausreichend schnell. Jetzt aber mit ZFS, ..,
Ich hab' auch folgendes überlegt: a) ZFS-snapshots als Grundlage benutzen (anstatt der hardlinks) und dann mit rsync die geänderten Dateien drüber'er schreiben b) rsync <-> rsync (Quellsystem <-> NAS), damit habe ich aber noch keine Erfahrung .
So in etwa macht das ja mein Skript Manfred
Hallo Jan. Am Samstag, 21. Oktober 2023, 16:29:04 CEST schrieb Jan Ritzerfeld:
Am Freitag, 20. Oktober 2023, 16:21:03 CEST schrieb Dr. Juergen Vollmer:
Hallo allerseits,
ich habe mir ein trueNAS -Server als Backupdevice aufgesetzt. Leider dauert das Backup via rsnapshot nun 4-5 mal solange (d.h. ca. 16 Stunden!) wie mit der vorigen Lösung (einem in die Jahre gekommenen qnap-NAS). Dazu mounte ich das ZFS-Backup-Verzeichnis via NFS in den zu sichernden Server. rsnapshot schreibt dann auf das NFS-Filesystem. [...]
Und das hast du abgesehen von ZFS auf dem NAS vorher ganz genauso gemacht?
ja absolut identisch....
Ich kenne mich konkret mit trueNAS zwar nicht aus aber das was du da machst klingt nach einer eher schlechten Idee.
Warum? Manfred schrieb ja schon, dass bei NFS Öffnen und Schließen "teure" Operationen sind. Und rsnapshot benutzt im Hintergrund rsync um die geänderten Dateien zu kopieren und die restlichen zu verlinken. Wie stellt rsync denn eigentlich fest, welche Dateien sich geändert haben? rsync macht sich das Leben zwar einfach und vergleicht per Default nur Zeitstempel und Größe aber mit Manfreds Erklärung im Hinterkopf ist das aber immer noch mühsam: Es werden alle, also sehr viele, Dateien übers Netzwerk gescannt und sehr viele Hardlinks angelegt aber kaum Daten übertragen, was dem von dir beobachteten Verhalten entspricht.
Deswegen möchte ich rsync so nicht benutzen. Viel geschickter finde ich es, auf dem NAS beispielsweise per SSH ein zweites rsync zu starten (-e "ssh") was dort dieses Scannen übernehmen kann. So laufen beide rsync lokal und können mit der maximalen Geschwindigkeit arbeiten. Tatsächlich übertragen werden dann nur die Dateilisten und die geänderten oder neuen Daten. Hier ein Beispiel von einem rsync Lauf auf's NAS bei dem keine Änderungen anstehen: jan@karl:~> rsync_jan_wichtige_dokumente.sh sending incremental file list sent 240,606 bytes received 772 bytes 11,774.54 bytes/sec total size is 2,355,483,377 speedup is 9,758.48 (DRY RUN)
ja das muss ich nochmal genauer anschauen. Aber wie gesagt, bisher wad NFS nicht so das Problem.... Aber vermutlich könnte man das ganze damit noch beschleunigen. Kann rsnapshot das?
Und rsnapshot benutze ich schon lange nicht mehr sondern bin auf storeBackup umgestiegen das hier auf einem ext4 arbeitet, das in einem LUKS- verschlüsselten liegt. In einem iSCSI-LUN auf dem NAS. Über WLAN. Das ist trotzdem ziemlich schnell. Mit einem echten Netzwerkprotokoll wie NFS sollte es nicht langsamer sein. Die deutsche storeBackup Dokumentation hat einen Abschnitt über Performance bei NFS, eben wegen der oben beschriebenen prinzipiellen Problem. Vielleicht ist da was für dich dabei. Sonst bleibt wirklich nur noch ZFS als Ursache übrig...
werd's storebackup mal genauer anschauen. Merci für die Hinweise Bye Jürgen
Viele Grüße Jan
-- Dr.rer.nat. Jürgen Vollmer, Am Rennbuckel 21, D-76185 Karlsruhe Tel: +49(721) 92 04 87 1 Fax: +49(721) 92 04 87 2 Juergen.Vollmer@informatik-vollmer.de www.informatik-vollmer.de ------------------------------------------------------------------------------- Diese EMail ist elektronisch mittels GPG / PGP signiert. Diese elektronische Unterschrift ist in einem EMail-Anhang enthalten. Leider kann die Signatur ohne die Installation entsprechender Programme weder geprüft noch angezeigt werden. Mehr dazu unter: http://www.gnupg.org oder auch http://www.pgpi.org -------------------------------------------------------------------------------
Am Sonntag, 22. Oktober 2023, 15:26:09 CEST schrieb Dr. Juergen Vollmer:
Hallo Jan.
Hallo Jürgen!
Am Samstag, 21. Oktober 2023, 16:29:04 CEST schrieb Jan Ritzerfeld: (...).
Und das hast du abgesehen von ZFS auf dem NAS vorher ganz genauso gemacht?
ja absolut identisch....
Okay. Neben ZFS könnte es ja auch noch an vielen anderen Dingen im neuen NAS liegen. Nur wie bekommt man eine vergleichbare Umgebung auf beiden NAS hin?
(...). ja das muss ich nochmal genauer anschauen. Aber wie gesagt, bisher wad NFS nicht so das Problem.... Aber vermutlich könnte man das ganze damit noch beschleunigen. Kann rsnapshot das?
Jein. Ich hatte gestern mal schnell gesucht aber die vorgeschlagenen Lösungen nicht ganz verstanden. Denn rsnapshot scheint dort laufen zu müssen wo das Backup hingesichert werden soll, also auf dem Ziel: https://www.synology-wiki.de/index.php/Generationsbackup_mit_rsync_und_rsnap...
(...). werd's storebackup mal genauer anschauen.
Ich hatte den Link vergessen: https://www.nongnu.org/storebackup/de/node67.html#configuringNFS
Merci für die Hinweise
Viel Erfolg! Jan -- A liberal is someone too poor to be conservative, and too rich to be a communist.
Am 20.10.23 um 16:21 schrieb Dr. Juergen Vollmer: (...)
- Der PC hat 64GB RAM - also eigentlich genug und ist auch ausreichend schnell. - ZFS belegt davon 50MB RAM (...)
Habe ich nicht irgendwo gelesen das ZFS jede Menge Speicher benötigt? Hat das ZFS ausreichend Speicher den es auch benutzen darf? Bernd
participants (6)
-
bnacht -
Dr. Juergen Vollmer -
Jan Ritzerfeld -
Manfred Haertel, DB3HM -
Manfred Kreisl -
Martin Schröder