49
Robocopy beschleunigen oder Alternative
Moin,
ein KMU-Kunden möchte ein Datenverzeichnis regelmäßig über eine VPN Verbindung zu einem anderen Standort replizieren. Dort soll man lesend auf die Version von gestern zugreifen können.
Es geht um ca. 2 TB mit sehr vielen kleinen Office-Dokumenten. Auf beiden Seiten stehen Windows-Server 2016 mit eigenem AD. Die Leitung hat ca. 200 MBit. Die Latenz liegt bei ca. 30ms.
Der Haustechniker hat dafür eine Batch-Datei mit Robocopy erstellt.
Nun wundert er sich, dass der Vorgang nach 8 Stunden nicht abgeschlossen ist und, dass der reine Abgleich so langsam ist 
Das mit den AD-Informationen ist eine längere Geschichte.
Warum es so langsam ist, weiß ich.
Ist die Frage wie man es auf die einfache Art beschleunigen kann.
Oder ob eine der tausenden Sync-Programme das besser hinbekommt.
Wenn man die Dateiliste an SMB vorbei überträgt und die geänderten Datein komprimiert überträgt sollte es schneller sein.
Unter Linux würde ich RSync verwenden.
Anforderung
- Skripte für Windows Server 2016
oder
- Software für Windows Server 2016
- Übertragen von 2TB kleinen Office Dokumenten one way
- Übertragen nur der geänderten Dateien
- Übertragen der Berechtigungen
Stefan
ein KMU-Kunden möchte ein Datenverzeichnis regelmäßig über eine VPN Verbindung zu einem anderen Standort replizieren. Dort soll man lesend auf die Version von gestern zugreifen können.
Es geht um ca. 2 TB mit sehr vielen kleinen Office-Dokumenten. Auf beiden Seiten stehen Windows-Server 2016 mit eigenem AD. Die Leitung hat ca. 200 MBit. Die Latenz liegt bei ca. 30ms.
Der Haustechniker hat dafür eine Batch-Datei mit Robocopy erstellt.
robocopy /MIR /B /R:1 /W:1 /COPYALL quelle zielDas mit den AD-Informationen ist eine längere Geschichte.
Warum es so langsam ist, weiß ich.
Ist die Frage wie man es auf die einfache Art beschleunigen kann.
Oder ob eine der tausenden Sync-Programme das besser hinbekommt.
Wenn man die Dateiliste an SMB vorbei überträgt und die geänderten Datein komprimiert überträgt sollte es schneller sein.
Unter Linux würde ich RSync verwenden.
Anforderung
- Skripte für Windows Server 2016
oder
- Software für Windows Server 2016
- Übertragen von 2TB kleinen Office Dokumenten one way
- Übertragen nur der geänderten Dateien
- Übertragen der Berechtigungen
Stefan
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 91188512706
Url: https://administrator.de/contentid/91188512706
Ausgedruckt am: 18.12.2024 um 01:12 Uhr
49 Kommentare
Neuester Kommentar
Moin,
Hast du Mal versucht, die Threads hoch zu setzen? Kommandozeilenoption /MT:32
Gruß,
Avoton
Hast du Mal versucht, die Threads hoch zu setzen? Kommandozeilenoption /MT:32
Gruß,
Avoton
Moin @StefanKittel,
da fehlt ja auch ein "/j", denn damit flutscht es schon um einiges schneller.
Sprich ...
Und wenn du auf den Servern noch das folgende ausführst ...
(PowerShell als Administrator)
... dann flutschen die SMB Zugriffe über die entsprechenden Server generell etwas besser. 😉
Gruss Alex
Der Haustechniker hat dafür eine Batch-Datei mit Robocopy erstellt.
Nun wundert er sich, dass der Vorgang nach 8 Stunden nicht abgeschlossen ist und, dass der reine Abgleich so langsam ist
robocopy /MIR /B /R:1 /W:1 /COPYALL quelle zielda fehlt ja auch ein "/j", denn damit flutscht es schon um einiges schneller.
Sprich ...
robocopy /MIR /B /R:1 /W:1 /j /COPYALL quelle zielUnd wenn du auf den Servern noch das folgende ausführst ...
(PowerShell als Administrator)
Set-SmbServerConfiguration -TreatHostAsStableStorage $true -AsynchronousCredits 2048Gruss Alex
da fehlt ja auch ein "/j", denn damit flutscht es schon um einiges schneller.
Der Parameter bringt aber nur bei großen Dateien etwas.Hier geht es um sehr viele kleine Office Dateien.
Gruss Penny.
Moin @Penny.Cilin,
der bringt meiner Erfahrung nach, auch eine ganze menge bei kleineren Dateien.
Einfach mal ausprobieren, dann sieht man den Unterschied ja sofort.
Gruss Alex
Der Parameter bringt aber nur bei großen Dateien etwas.
Hier geht es um sehr viele kleine Office Dateien.
Hier geht es um sehr viele kleine Office Dateien.
der bringt meiner Erfahrung nach, auch eine ganze menge bei kleineren Dateien.
Einfach mal ausprobieren, dann sieht man den Unterschied ja sofort.
Gruss Alex
Probier doch mal freefilesync. Damit kopiere ich täglich vom Server auf ein NAS.
Hi
Da du ja über WAN kopierst wie sieht es bzgl MTU aus ? Ist die durchgängig 1500 oder wird fragmentiert ?
Probier mal mit dem Schalter /ipg: die Größe zu beeinflussen auf die eurer WAN Verbindung inkl. Abzug overhead gestellt ist.
Werden den die 200 Mbit auch ausgelastet?
Wie schnell ist den die Gegenseite bzgl lese / Schreibrate?
Und das AD auf der Gegenseite ist eine replication des ADs oder ist es ein eigenes ?
Wenn eigenes AD mit eigenen NTFS Berechtigungen dann ist Copyall vermutlich die Bremse ? Begrenz das mal auf /copy:DAT und auch für Ordner /dcopy:DAT
Weil woher soll die Gegenseite die SIDs kennen und durch die Vererbung wird das ja wieder überschrieben und er muss jede Datei beim erneuten kopieren erneut anfassen.
Mit freundlichen Grüßen Nemesis
Da du ja über WAN kopierst wie sieht es bzgl MTU aus ? Ist die durchgängig 1500 oder wird fragmentiert ?
Probier mal mit dem Schalter /ipg: die Größe zu beeinflussen auf die eurer WAN Verbindung inkl. Abzug overhead gestellt ist.
Werden den die 200 Mbit auch ausgelastet?
Wie schnell ist den die Gegenseite bzgl lese / Schreibrate?
Und das AD auf der Gegenseite ist eine replication des ADs oder ist es ein eigenes ?
Wenn eigenes AD mit eigenen NTFS Berechtigungen dann ist Copyall vermutlich die Bremse ? Begrenz das mal auf /copy:DAT und auch für Ordner /dcopy:DAT
Weil woher soll die Gegenseite die SIDs kennen und durch die Vererbung wird das ja wieder überschrieben und er muss jede Datei beim erneuten kopieren erneut anfassen.
Mit freundlichen Grüßen Nemesis
Würde da wie @Looser27 sagte auf Sync Software gehen.
Alternativ PS Script, das vorher Hashsummen generiert. Nur geänderte Dateien in einen tar oder ZIP Ball packt.
Unzip ist PS native. Hashummen zum Verifizieren, dass alles angekommen ist. Neue Dateien sieht man ja auf dem Quellserver anhand des LastWriteDates - Tagesdatum.
Liste mit PS erstellen ist also recht simpel. Kleine Dateien sind immer schon ein Show-Stopper gewesen.
Gelöschte Dateien sind oben nicht mit berücksichtigt. Man könnte einfach eine Dateien Liste mitgeben und dann alles löschen was nicht mit drin steht.
2 TB ist natürlich ein Brett. Wegen den ganzen Kleinkram. Erstellen der ZIP und Content Listen dauert eine Zeit. Da würde ich ggf. erst einmal freefilesync den Vorzug geben.
mfg Crusher
Alternativ PS Script, das vorher Hashsummen generiert. Nur geänderte Dateien in einen tar oder ZIP Ball packt.
Unzip ist PS native. Hashummen zum Verifizieren, dass alles angekommen ist. Neue Dateien sieht man ja auf dem Quellserver anhand des LastWriteDates - Tagesdatum.
Liste mit PS erstellen ist also recht simpel. Kleine Dateien sind immer schon ein Show-Stopper gewesen.
Gelöschte Dateien sind oben nicht mit berücksichtigt. Man könnte einfach eine Dateien Liste mitgeben und dann alles löschen was nicht mit drin steht.
2 TB ist natürlich ein Brett. Wegen den ganzen Kleinkram. Erstellen der ZIP und Content Listen dauert eine Zeit. Da würde ich ggf. erst einmal freefilesync den Vorzug geben.
mfg Crusher
Ist die Frage wie man es auf die einfache Art beschleunigen kann.
DFSR
Auf beiden Seiten stehen Windows-Server 2016 mit eigenem AD
Hab ich gerade noch gesehen. Jeweils ein eigenes AD? Mit oder ohne Vertrauensstellung? Ob da DFSR funktioniert weiß ich ad hoc nicht.
Manuel
https://superuser.com/questions/1660962/windows-10-fastest-way-to-move-m ...
Das ist aber alles so ähnlich wie deine Version. Mir fiel hier nur eines auf:
Multithreading sorgt halt für parallel Kopie der kleinen Dateien.
Ich hatte es nur mal übertrieben und damit meinen PC abgeschossne. Schon arg lang her. Denke aber mit 10 - 20 parallelen Vorgängen sollte es gehen.
Du kannst dich ja heran tasten.
Das ist aber alles so ähnlich wie deine Version. Mir fiel hier nur eines auf:
/MT:10Multithreading sorgt halt für parallel Kopie der kleinen Dateien.
Ich hatte es nur mal übertrieben und damit meinen PC abgeschossne. Schon arg lang her. Denke aber mit 10 - 20 parallelen Vorgängen sollte es gehen.
Du kannst dich ja heran tasten.
robocopy /E quelle ziel /MIR /B /R:1 /W:1 /COPYALL /MT::10
Wenn sich eh nur eine Seite ändert würde sich auch das Archiv-Attribut und der Parameter /m anbieten, dann entfiele das aufwendige Enumerieren der Remote-Seite was bei SMB und der Latenz doch einige Zeit kostet. Aber das Erhöhen der Threads sollte auf jeden Fall für den Kopiervorgang einiges bringen wenn es viele kleine Dateien sind die sich ändern.
SyncBackPro z.B. lässt sich diesbezüglich auch sehr fein einstellen wie gesynct wird und hat auch einen Quick-Mode ohne die Remote-Seite scannen zu müssen wenn sich nur eine Seite ändert.
SyncBackPro z.B. lässt sich diesbezüglich auch sehr fein einstellen wie gesynct wird und hat auch einen Quick-Mode ohne die Remote-Seite scannen zu müssen wenn sich nur eine Seite ändert.
Multithreading sorgt halt für parallel Kopie der kleinen Dateien.
Deswegen habe ich das ja auch oben vorgeschlagen ;)
1
Moin Stefan,
ich bringe dann mal noch bvckup2 ins Spiel, das nutze ich bevorzugt für Remote-Verbindungen, wenn Source=Windows. Macht Deltacopy, multi-threading, ist sehr schnell (der Entwickler bemüht sich sehr, sozusagen auch noch das kleinste Quentchen Geschwindigkeit herauszuquetschen), und kann in der Regel den Abgleich dadurch massiv beschleunigen, dass lokal an der Quelle ein Cache mit dem Inhalt des Ziels vorgehalten wird (Metadaten). Da ja vermutlich der Abgleich das Problem ist, und weniger die Menge der geänderten Daten, würde ich das einfach mal in der Testversion für 2 Wochen laufen lassen.
Habe das im Einsatz bei hunderttausenden Dateien an der Quelle, mit wirklich guter Performance, bisher keine schnellere Lösung gefunden.
Gruß
DivideByZero
ich bringe dann mal noch bvckup2 ins Spiel, das nutze ich bevorzugt für Remote-Verbindungen, wenn Source=Windows. Macht Deltacopy, multi-threading, ist sehr schnell (der Entwickler bemüht sich sehr, sozusagen auch noch das kleinste Quentchen Geschwindigkeit herauszuquetschen), und kann in der Regel den Abgleich dadurch massiv beschleunigen, dass lokal an der Quelle ein Cache mit dem Inhalt des Ziels vorgehalten wird (Metadaten). Da ja vermutlich der Abgleich das Problem ist, und weniger die Menge der geänderten Daten, würde ich das einfach mal in der Testversion für 2 Wochen laufen lassen.
Habe das im Einsatz bei hunderttausenden Dateien an der Quelle, mit wirklich guter Performance, bisher keine schnellere Lösung gefunden.
Gruß
DivideByZero
Unter Windows auch. Entweder per WSL oder direkt nativ.
lks
3Zitat von @Avoton:
Multithreading sorgt halt für parallel Kopie der kleinen Dateien.
Deswegen habe ich das ja auch oben vorgeschlagen ;)ups. 1. Antwort verschluckt
32 geht glaub ich auch noch. Ich hab mir mal mit 100 oder so Rechner abgeschossen. Netzwerk war tot. War noch zu Windows 7 Zeiten.
Gabs da eig. Empfehlungen zum max?
Gabs da eig. Empfehlungen zum max?
Empfehlungen sind mir keine bekannt, das Maximum ist 128...
Hallo,
das mit "/j" hat quasi nichts gebracht.
128 Threads haben die Geschwindigkeit mehr als verdoppel.
bvckup2 schaue ich mir noch an.
Das mit dem AD versuche ich noch zu verstehen was die sich gedacht haben.
Danke schon mal
Stefan
das mit "/j" hat quasi nichts gebracht.
128 Threads haben die Geschwindigkeit mehr als verdoppel.
bvckup2 schaue ich mir noch an.
Das mit dem AD versuche ich noch zu verstehen was die sich gedacht haben.
Danke schon mal
Stefan
Moin @StefanKittel,
wenn der Parameter /j nicht viel gebracht hat und du mit 128 Threads, was dem 16fachen des Standardwerts entspricht nur die doppelte Performance hinbekommst, dann hängt meiner Ansicht nach eher etwas auf der Storageseite.
Wie viele Kerne haben den die entsprechenden Server?
Gruss Alex
das mit "/j" hat quasi nichts gebracht.
128 Threads haben die Geschwindigkeit mehr als verdoppel.
128 Threads haben die Geschwindigkeit mehr als verdoppel.
wenn der Parameter /j nicht viel gebracht hat und du mit 128 Threads, was dem 16fachen des Standardwerts entspricht nur die doppelte Performance hinbekommst, dann hängt meiner Ansicht nach eher etwas auf der Storageseite.
Wie viele Kerne haben den die entsprechenden Server?
Gruss Alex
Moin @Lochkartenstanzer,
Unter Windows auch. Entweder per WSL oder direkt nativ.
👍👍👍
RSync könnte sogar um einiges schneller flutschen wie Robocopy, da es bei veränderten Dateien nur die Änderung überträgt.
Gruss Alex
Unter Linux würde ich RSync verwenden.
Unter Windows auch. Entweder per WSL oder direkt nativ.
👍👍👍
RSync könnte sogar um einiges schneller flutschen wie Robocopy, da es bei veränderten Dateien nur die Änderung überträgt.
Gruss Alex
Teile doch bitte einmal Deine Datenmenge durch deine Übertragungsgeschwindigkeit. Da kommen bei mir 22 Stunden raus, selbst ohne Latenzen.
1
Wieso kopierst du eigentlich alle Dateieigenschaften (COPYALL), wenn die User anschließend nur lesend darauf zugreifen dürfen?
COPYALL kopiert auch alle Berechtigungseinstellungen der Dateien.
Noch eine Frage: Von welcher Seite aus wird denn robocopy angestoßen, von der Quelle oder vom Ziel?
COPYALL kopiert auch alle Berechtigungseinstellungen der Dateien.
Noch eine Frage: Von welcher Seite aus wird denn robocopy angestoßen, von der Quelle oder vom Ziel?
Moin,
die Gegenstelle ist ein Datengrab mit einem SATA RAID5 aber genug CPU Kernen.
Mit weniger Threads war es schneller.
Die Gegenstelle ist scheinbar ein AD-Server der offline gestellt wurde aber die damaligen Berechtigungen noch hat.
Deshalb vermutlich die Rechte.
Rsync ist mir für Windows ein bisschen zu weit weg von meiner Wohlfühlzone als dass ich es vorschlagen möchte.
Das was halt lange dauert ist der Abgleich. Alleine über SMB (oder FTP) ein Listing der Gegenseite mit 10tausenden Verzeichnissen zu erstellen dauert lange. Multithreading beschleunig dies. Bvckup2 würde diesen Zeitfaktor ganz eleminieren, Ich werde das mal testen.
Stefan
die Gegenstelle ist ein Datengrab mit einem SATA RAID5 aber genug CPU Kernen.
Mit weniger Threads war es schneller.
Die Gegenstelle ist scheinbar ein AD-Server der offline gestellt wurde aber die damaligen Berechtigungen noch hat.
Deshalb vermutlich die Rechte.
Rsync ist mir für Windows ein bisschen zu weit weg von meiner Wohlfühlzone als dass ich es vorschlagen möchte.
Das was halt lange dauert ist der Abgleich. Alleine über SMB (oder FTP) ein Listing der Gegenseite mit 10tausenden Verzeichnissen zu erstellen dauert lange. Multithreading beschleunig dies. Bvckup2 würde diesen Zeitfaktor ganz eleminieren, Ich werde das mal testen.
Stefan
Moin @StefanKittel
für deinen Datenabgleich per Internetleitung gäbe es wohl mehrere Möglichkeiten, die auch genannt wurden:
Schließlich würde ich wegen der schieren Masse an Daten mehr darüber nachdenken, ob nicht große Teile des Datenabgleichs umgangen werden können, weil es eben unveränderliche Datenbereiche sind. Diese gilt es halt zu separieren und vom Abgleich auszuschließen. Auf diese weise liesse ich wohl die meiste Zeit sparen.
Eine schnellere Leitungsverbindung würde vermutlich kaum etwas bringen, da wie gesagt sehr viele kleine Dateien dem entgegenstehen.
Hier und da empfehle ich inzwischen, unveränderliche Datenbereiche in „Archiv“-Bereiche zu unterteilen/abzutrennen und als ISO-Dateien read only zusammenzuführen.
für deinen Datenabgleich per Internetleitung gäbe es wohl mehrere Möglichkeiten, die auch genannt wurden:
- DFS-Replikation (bedingt, dass alle Server im selben AD sind, ist aber auch wegen der großen Anzahl der Dateien auch mal überfordert)
- robocopy (dauert sehr lange weil es eben sehr viele Daten sind)
- rsync (der Klassiker für solche aufgaben, dauert aber eben auch lange, weil es sehr viele Daten sind)
Schließlich würde ich wegen der schieren Masse an Daten mehr darüber nachdenken, ob nicht große Teile des Datenabgleichs umgangen werden können, weil es eben unveränderliche Datenbereiche sind. Diese gilt es halt zu separieren und vom Abgleich auszuschließen. Auf diese weise liesse ich wohl die meiste Zeit sparen.
Eine schnellere Leitungsverbindung würde vermutlich kaum etwas bringen, da wie gesagt sehr viele kleine Dateien dem entgegenstehen.
Hier und da empfehle ich inzwischen, unveränderliche Datenbereiche in „Archiv“-Bereiche zu unterteilen/abzutrennen und als ISO-Dateien read only zusammenzuführen.
Moin @StefanKittel,
Ist das ein HDD RAID, wenn ja welches ist es und wie viele Platten hat dieses ?
Ist es ein Software- oder Hardware-RAID?
Wenn Hardware-RAID, ist auf dem Controller/LUN eventuell "Read Ahead" aktiviert?
Wenn ja, dann schalte das mal aus, das ist in deinem Fall glaube ich nicht wirklich hilfreich.
Gruss Alex
die Gegenstelle ist ein Datengrab mit einem SATA RAID5 aber genug CPU Kernen.
Ist das ein HDD RAID, wenn ja welches ist es und wie viele Platten hat dieses ?
Ist es ein Software- oder Hardware-RAID?
Wenn Hardware-RAID, ist auf dem Controller/LUN eventuell "Read Ahead" aktiviert?
Wenn ja, dann schalte das mal aus, das ist in deinem Fall glaube ich nicht wirklich hilfreich.
Gruss Alex
Moin,
Kurz nochmal zu dem Protokoll über das synchronisiert wird.
Solange man über shares synchronisiert. d.h smb cifs oder sonstwas, hat man das Problem, daß die sync-Programm die daten über die leitung ziehen müssen, um zu vergleichen, sofern man nicht nur über Medtadaten (Filegröße oder Datum) die Kriterien festlegt.
Daher sollten man z.B. auch rsync nicht direkt über die Shares synchronisieren lassen, sondern eher direkt über rsync-Protokoll oder einen sshtunnel, so daß auf beiden seiten die passenden Sync-prozesse laufen und die Daten erstmal nur lokal gelesen werden können statt über die Leitung. Das hllft die menge an daten minimal zu halten und die lokalen rsync-prozesse können die lokalen Filesystem auch deutlich schneller druchlaufen als über ein netzwerk-Filing-Protokoll wie cifs, AFP NFS & Co.
Ich würde da einen ssh oder rsync-Server auf dem Ziel aufsetzen und damit alles syncronisieren..
lks
Kurz nochmal zu dem Protokoll über das synchronisiert wird.
Solange man über shares synchronisiert. d.h smb cifs oder sonstwas, hat man das Problem, daß die sync-Programm die daten über die leitung ziehen müssen, um zu vergleichen, sofern man nicht nur über Medtadaten (Filegröße oder Datum) die Kriterien festlegt.
Daher sollten man z.B. auch rsync nicht direkt über die Shares synchronisieren lassen, sondern eher direkt über rsync-Protokoll oder einen sshtunnel, so daß auf beiden seiten die passenden Sync-prozesse laufen und die Daten erstmal nur lokal gelesen werden können statt über die Leitung. Das hllft die menge an daten minimal zu halten und die lokalen rsync-prozesse können die lokalen Filesystem auch deutlich schneller druchlaufen als über ein netzwerk-Filing-Protokoll wie cifs, AFP NFS & Co.
Ich würde da einen ssh oder rsync-Server auf dem Ziel aufsetzen und damit alles syncronisieren..
lks
Goodsync kann deine Anforderungen erfüllen.
Moin,
kurzer Nachtrag nochmal zum Parameter /MT für die Anzahl der Threads.
Der funktioniert super, ist aber ein bisschen Tricki.
Ich habe in verschiedenen mal mit dem Parameter experimentiert.
Er erhöht die z.B. durchschnittliche Geschwindigkeit bei einem JOB von SATA-HDD-NAS auf SATA-HDD-Cloud-Server bei einer 300MBit Leitung.
Ohne MT schwankt der zwischen 60 und 260 MBit.
Mit MT 8 schwankt der zwischen 240 und 260 MBit.
Mit MT 128 liegt er nur noch bei 40 MBit (Zu viele parallele Zugriffe für die 7200er SATA HDDs im RAID5 mit je 8 HDDs)
Bei sehr vielen kleinen Dateien ist der Zeitaufwand um den Unterschied festzustellen ein massiver Zeitfaktor.
Teilweise 4 Stunden nur um einen Abgleich zu erstellen. Da helfen solche Tools wie bvckup2 die das nur lokal ausführen. Mit dem Risiko, dass es schiefgeht.
Man bräuchte eine aktive Software auf Client- und Serverseite die das beschleunigt und sicher abgleichen kann.
Ich schreibe das auf meine Projekte-Liste. So auf Platz 37 oder so.
Viele Grüße
Stefan
kurzer Nachtrag nochmal zum Parameter /MT für die Anzahl der Threads.
Der funktioniert super, ist aber ein bisschen Tricki.
Ich habe in verschiedenen mal mit dem Parameter experimentiert.
Er erhöht die z.B. durchschnittliche Geschwindigkeit bei einem JOB von SATA-HDD-NAS auf SATA-HDD-Cloud-Server bei einer 300MBit Leitung.
Ohne MT schwankt der zwischen 60 und 260 MBit.
Mit MT 8 schwankt der zwischen 240 und 260 MBit.
Mit MT 128 liegt er nur noch bei 40 MBit (Zu viele parallele Zugriffe für die 7200er SATA HDDs im RAID5 mit je 8 HDDs)
Bei sehr vielen kleinen Dateien ist der Zeitaufwand um den Unterschied festzustellen ein massiver Zeitfaktor.
Teilweise 4 Stunden nur um einen Abgleich zu erstellen. Da helfen solche Tools wie bvckup2 die das nur lokal ausführen. Mit dem Risiko, dass es schiefgeht.
Man bräuchte eine aktive Software auf Client- und Serverseite die das beschleunigt und sicher abgleichen kann.
Ich schreibe das auf meine Projekte-Liste. So auf Platz 37 oder so.
Viele Grüße
Stefan
Zitat von @StefanKittel:
Man bräuchte eine aktive Software auf Client- und Serverseite die das beschleunigt und sicher abgleichen kann.
Man bräuchte eine aktive Software auf Client- und Serverseite die das beschleunigt und sicher abgleichen kann.
Du meinst rsync/rsyncd!
lks
Zitat von @Lochkartenstanzer:
lks
Zitat von @StefanKittel:
Man bräuchte eine aktive Software auf Client- und Serverseite die das beschleunigt und sicher abgleichen kann.
Du meinst rsync/rsyncd!Man bräuchte eine aktive Software auf Client- und Serverseite die das beschleunigt und sicher abgleichen kann.
lks
ähh, ja.
Mir fehlt hier eine native Windows-Anbindung. Nicht eine Portierung von Jemanden irgendwo im Web.
Und der Umweg über das Linux-Dings ist auch nicht so mein Fall.
Also sollte Jemand eine native Windows-Portierung erstellen und als eigenständiges Produkt vermarkten.
Stefan
@StefanKittel
das nennt sich DeltaCopy.
https://www.heise.de/download/product/deltacopy-62565
Kann direkt in Verbindung mit den Linux-Versionen oder mit SYNOLOGY oder QNap oder...... Verbindung aufnehmen.
Kreuzberger
Zitat von @StefanKittel:
Mir fehlt hier eine native Windows-Anbindung. Nicht eine Portierung von Jemanden irgendwo im Web.
Und der Umweg über das Linux-Dings ist auch nicht so mein Fall.
Also sollte Jemand eine native Windows-Portierung erstellen und als eigenständiges Produkt vermarkten.
Stefan
Und der Umweg über das Linux-Dings ist auch nicht so mein Fall.
Also sollte Jemand eine native Windows-Portierung erstellen und als eigenständiges Produkt vermarkten.
Stefan
das nennt sich DeltaCopy.
https://www.heise.de/download/product/deltacopy-62565
Kann direkt in Verbindung mit den Linux-Versionen oder mit SYNOLOGY oder QNap oder...... Verbindung aufnehmen.
Kreuzberger
Zitat von @kreuzberger:
das nennt sich DeltaCopy.
https://www.heise.de/download/product/deltacopy-62565
Klingt fast super.das nennt sich DeltaCopy.
https://www.heise.de/download/product/deltacopy-62565
Bis auf "available only on Microsoft platforms (XP, 2000, 2003, Vista, Windows 7 & 2008).
Eine aktuelle Version gibt es nicht oder?
Hi
https://web.synametrics.com/syncrifyvsdeltacopy.htm
Vielleicht das hier?
Mit freundlichen Grüßen Nemesis
https://web.synametrics.com/syncrifyvsdeltacopy.htm
Vielleicht das hier?
Mit freundlichen Grüßen Nemesis
@StefanKittel
ich hatte es mal auf Server 2012R2 und Server 2016 installiert, es funktionierte darauf.
Kreuzberger
ich hatte es mal auf Server 2012R2 und Server 2016 installiert, es funktionierte darauf.
Kreuzberger
Zitat von @StefanKittel:
Bei sehr vielen kleinen Dateien ist der Zeitaufwand um den Unterschied festzustellen ein massiver Zeitfaktor.
Teilweise 4 Stunden nur um einen Abgleich zu erstellen. Da helfen solche Tools wie bvckup2 die das nur lokal ausführen. Mit dem Risiko, dass es schiefgeht.
Bei sehr vielen kleinen Dateien ist der Zeitaufwand um den Unterschied festzustellen ein massiver Zeitfaktor.
Teilweise 4 Stunden nur um einen Abgleich zu erstellen. Da helfen solche Tools wie bvckup2 die das nur lokal ausführen. Mit dem Risiko, dass es schiefgeht.
Hast Du denn bvckup2 einmal im Vergleich laufen lassen? Zum einen interessiert es mich, zum anderen kann ich das Risiko, von dem Du sprichts, nicht nachvollziehen. bvckup2 arbeitet, wie ich schon sagte, in verschiedenen Installationen seit Jahren fehlerfrei.
Gruß
DivideByZero
Moin
bis jetzt nicht.
Jede Form von Delta-Kopie bringt das prinzipbedingte Risiko mit sich, dass das Original und die Kopie mit der Zeit auseinanderlaufen. Irgendein Bit was irgendwo mal, aus welchem Grund auch immer, verloren geht. Oder eine Datei die aus unbekannten Grund auf der Serverseite gelöscht wird.
Ich bin noch am überlegen wie man hier 4 Fliegen mit einer Klappe schlagen kann
Stefan
Zitat von @DivideByZero:
Hast Du denn bvckup2 einmal im Vergleich laufen lassen? Zum einen interessiert es mich, zum anderen kann ich das Risiko, von dem Du sprichts, nicht nachvollziehen. bvckup2 arbeitet, wie ich schon sagte, in verschiedenen Installationen seit Jahren fehlerfrei.
Hast Du denn bvckup2 einmal im Vergleich laufen lassen? Zum einen interessiert es mich, zum anderen kann ich das Risiko, von dem Du sprichts, nicht nachvollziehen. bvckup2 arbeitet, wie ich schon sagte, in verschiedenen Installationen seit Jahren fehlerfrei.
bis jetzt nicht.
Jede Form von Delta-Kopie bringt das prinzipbedingte Risiko mit sich, dass das Original und die Kopie mit der Zeit auseinanderlaufen. Irgendein Bit was irgendwo mal, aus welchem Grund auch immer, verloren geht. Oder eine Datei die aus unbekannten Grund auf der Serverseite gelöscht wird.
Ich bin noch am überlegen wie man hier 4 Fliegen mit einer Klappe schlagen kann
Stefan
Syncrify scheint in der Tat die gewünschte Software zu sein.
"Syncrify uses the Rsync algorithms with a custom implementation. This eliminates the need for CYGWIN on Windows"
Es enthält eine Client- und eine Server-Komponente.
Damit bietet es neben der Kopierfunktion auch eine Verifizierungsfunktion ohne alles wieder runterzuladen.
Preislich finde ich es günstig.
Ich brauche nur wenige Lizenzen.
Ich werde das mal demnächst ausprobieren.
Stefan
Zitat von @StefanKittel:
Jede Form von Delta-Kopie bringt das prinzipbedingte Risiko mit sich, dass das Original und die Kopie mit der Zeit auseinanderlaufen. Irgendein Bit was irgendwo mal, aus welchem Grund auch immer, verloren geht. Oder eine Datei die aus unbekannten Grund auf der Serverseite gelöscht wird.
Jede Form von Delta-Kopie bringt das prinzipbedingte Risiko mit sich, dass das Original und die Kopie mit der Zeit auseinanderlaufen. Irgendein Bit was irgendwo mal, aus welchem Grund auch immer, verloren geht. Oder eine Datei die aus unbekannten Grund auf der Serverseite gelöscht wird.
Es könnte natürlich auch sein, dass verbaute SSDs sich plötzlich schneller drehen.
Kreuberger
Zitat von @StefanKittel:
bis jetzt nicht.
Jede Form von Delta-Kopie bringt das prinzipbedingte Risiko mit sich, dass das Original und die Kopie mit der Zeit auseinanderlaufen. Irgendein Bit was irgendwo mal, aus welchem Grund auch immer, verloren geht. Oder eine Datei die aus unbekannten Grund auf der Serverseite gelöscht wird.
bis jetzt nicht.
Jede Form von Delta-Kopie bringt das prinzipbedingte Risiko mit sich, dass das Original und die Kopie mit der Zeit auseinanderlaufen. Irgendein Bit was irgendwo mal, aus welchem Grund auch immer, verloren geht. Oder eine Datei die aus unbekannten Grund auf der Serverseite gelöscht wird.
Natürlich, aber solche Fälle, die im Übrigen auch bei normalen Backups Thema sind (z.B. Bit Rot), können in der Regel durch regelmäßiges Überprüfen und Hashen abgefangen werden. Bvckup2 macht im Rahmen von Delta Copy genau das: Erläuterung Delta Copying - andere Programme gehen da ähnlich vor, wenn sie das Thema berücksichtigen. Aber wenn solche Mechanismen zum Einsatz kommen, sehe ich das "prinzipbedingte" Risiko nicht, da es dafür eine Lösung gibt.
Und Dateien, die auf der Serverseite einfach so gelöscht werden, sind wohl gänzlich programmunabhängig ein Problem...
Gruß
DivideByZero
Zitat von @DivideByZero:
Natürlich, aber solche Fälle, die im Übrigen auch bei normalen Backups Thema sind (z.B. Bit Rot), können in der Regel durch regelmäßiges Überprüfen und Hashen abgefangen werden. Bvckup2 macht im Rahmen von Delta Copy genau das: Erläuterung Delta Copying - andere Programme gehen da ähnlich vor, wenn sie das Thema berücksichtigen. Aber wenn solche Mechanismen zum Einsatz kommen, sehe ich das "prinzipbedingte" Risiko nicht, da es dafür eine Lösung gibt.
Und Dateien, die auf der Serverseite einfach so gelöscht werden, sind wohl gänzlich programmunabhängig ein Problem...
Natürlich, aber solche Fälle, die im Übrigen auch bei normalen Backups Thema sind (z.B. Bit Rot), können in der Regel durch regelmäßiges Überprüfen und Hashen abgefangen werden. Bvckup2 macht im Rahmen von Delta Copy genau das: Erläuterung Delta Copying - andere Programme gehen da ähnlich vor, wenn sie das Thema berücksichtigen. Aber wenn solche Mechanismen zum Einsatz kommen, sehe ich das "prinzipbedingte" Risiko nicht, da es dafür eine Lösung gibt.
Und Dateien, die auf der Serverseite einfach so gelöscht werden, sind wohl gänzlich programmunabhängig ein Problem...
Ich habe bvckup2 noch nicht ausprobiert.
Aber so weit ich das gesehen habe, läuft es nur auf dem Client und nicht dem SMB-Ziel. Es hat keine Server-Komponente.
Also kann die Software den Hash-Wert von den Dateien auf dem Ziel nur überprüfen indem es sie runterlädt.
Oder gibt es doch eine Server-Komponente?
RSync empfängt vom Server nur den Hash-Wert einer Datei von der Server-Komponenten am Server live erstellt wird.
Deshalb muss man trotzdem die 3TB einmal Hashen, aber nicht über die 300MBit Leitung schicken. Nur um zu erfahren ob sich etwas geändert hat.
Stefan
Zitat von @kreuzberger:
Es könnte natürlich auch sein, dass verbaute SSDs sich plötzlich schneller drehen.
(Zunge rausstreck)Es könnte natürlich auch sein, dass verbaute SSDs sich plötzlich schneller drehen.
Ich hatte es schon zweimal mit meinen persönlichen Bilder, dass auf einmal ein 10 Jahre altes Bild, inmitten von tausenden, defekt war. Einmal auf einem QNAP NAS und einmal auf einem Windows-Server-OS. Da man da nicht regelmäßig raufschaut, konnte ich die Gründe dafür nie ermitteln. Also möchte ich gerne überall, bei mir und bei meinen Kunden, eine Verifikation der Daten.
Stefan
@StefanKittel
ggf. siehst du die die Optionen von rsync mal an und probierst es aus. Was du da erreichen magst ist faktisch das zentrale, eigentliche, wofür rsync gemacht wurde und auch allgemein anerkannt perfekt funktioniert.
https://wiki.ubuntuusers.de/rsync/
Siehe option -c
"aktiviert einen Dateivergleich, basierend auf Prüfsumme und nicht auf Größe und Zeitstempel. Die eigentliche Prüfsummenbildung dauert deutlich länger als der Vergleich Größe und Änderungs-Zeitstempel; andererseits werden überflüssige Kopiervorgänge (z.B. bei nur geänderter Änderungszeit) vermieden.“
Die Optionen/Parameter/Schalter werden soweit ich mich recht erinnere von allen Varianten (DeltaCopy, Linux, Unix, Apple etc) unterstützt, das rsync-Protokoll ebenfalls. Eben genau dieser Umstand ist es ja, der dich von Herstellern wie SYNOLOGY unabhängig macht und du alles mögliche mischen kannst.
Anleitungen und weitere Beschreibungen zu rsync findest du massenweise im Internet.
Kreuzberger
ggf. siehst du die die Optionen von rsync mal an und probierst es aus. Was du da erreichen magst ist faktisch das zentrale, eigentliche, wofür rsync gemacht wurde und auch allgemein anerkannt perfekt funktioniert.
https://wiki.ubuntuusers.de/rsync/
Siehe option -c
"aktiviert einen Dateivergleich, basierend auf Prüfsumme und nicht auf Größe und Zeitstempel. Die eigentliche Prüfsummenbildung dauert deutlich länger als der Vergleich Größe und Änderungs-Zeitstempel; andererseits werden überflüssige Kopiervorgänge (z.B. bei nur geänderter Änderungszeit) vermieden.“
Die Optionen/Parameter/Schalter werden soweit ich mich recht erinnere von allen Varianten (DeltaCopy, Linux, Unix, Apple etc) unterstützt, das rsync-Protokoll ebenfalls. Eben genau dieser Umstand ist es ja, der dich von Herstellern wie SYNOLOGY unabhängig macht und du alles mögliche mischen kannst.
Anleitungen und weitere Beschreibungen zu rsync findest du massenweise im Internet.
Kreuzberger
Hallo Kreuzberger,
ich habe nix gegen rsync und nutzte es selber viel im Linux-Bereich.
Im Windows-Bereich sind mir die Implentierungen nur nicht "stabil" genug.
Syncrify ist die bisher erste Implentierung die mir stabil genug und Systemkonform aussieht.
Stefan
ich habe nix gegen rsync und nutzte es selber viel im Linux-Bereich.
Im Windows-Bereich sind mir die Implentierungen nur nicht "stabil" genug.
Syncrify ist die bisher erste Implentierung die mir stabil genug und Systemkonform aussieht.
Stefan
Im Windows-Bereich sind mir die Implentierungen nur nicht "stabil" genug.
Aus genau dem Problem heraus habe ich mich damals für FreeFileSync entschieden. Das läuft über die Aufgabenplanung vom Server seither völlig unauffällig.
Moin,
Und solange es keine aktive Komponente am Server gibt bleibt das Problem des Abgleiches und der Verifikation.
Einen Abgleich von 3 Millionen Dateien über SMB (oder FTP, WebDac, CFS, etc) dauert halt. Über RSync geht das viel flotter.
Stefan
Zitat von @Looser27:
Aus genau dem Problem heraus habe ich mich damals für FreeFileSync entschieden. Das läuft über die Aufgabenplanung vom Server seither völlig unauffällig.
Aus genau dem Problem heraus habe ich mich damals für FreeFileSync entschieden. Das läuft über die Aufgabenplanung vom Server seither völlig unauffällig.
Und solange es keine aktive Komponente am Server gibt bleibt das Problem des Abgleiches und der Verifikation.
Einen Abgleich von 3 Millionen Dateien über SMB (oder FTP, WebDac, CFS, etc) dauert halt. Über RSync geht das viel flotter.
Stefan
dass auf einmal ein 10 Jahre altes Bild, inmitten von tausenden, defekt war.
Wenn dir das originale Bild kaputt geht, ist das Backup einen Tag später auch hin, wenn delta-copy-Algorithmen (statt Größe/Datum) genutzt werden. Geht aber die Kopie kaputt, ist diese einen Tag später (mit delta) wieder aktuell.
Alles hat Vor- und Nachteile.
Schließlich und endlich macht man ja auch mehrere Generationen von Backups, und nicht bloss eine Synchronkopie.
Kreuzberger
Kreuzberger
Ob "man" im vorliegenden Fall auch Generationen erstellt, weiß ich nicht. Und gerade bei dem erwähnten "Bild"-Beispiel kann man sich an einer Hand abzählen, wann und ob man das rechtzeitig bemerken würde
Zitat von @kreuzberger:
Schließlich und endlich macht man ja auch mehrere Generationen von Backups, und nicht bloss eine Synchronkopie.
Ja, mache ich auch.Schließlich und endlich macht man ja auch mehrere Generationen von Backups, und nicht bloss eine Synchronkopie.
Aber nicht über Jahre hinweg.
Und das stelle ich mir auch bei vielen Kunden als Problem vor.
Irgendjemand löscht eine Datei vom Jahresabschluss und 3 Jahre später braucht man die wieder.
Die Datensicherung geht aber nur 1 Jahr zurück (viele KMUs eher 90 Tage).
Stefan
Servus,
ich hatte dasselbe Problem mit robocopy und habe mir mit der Option "/MAXAGE:1" geholfen. Erfasse also nur Files des letzten Tages. Das ist bei den zu synchronisierenden 600 GB in wenigen Sekunden erledigt.
Am Wochenende wird dann der Job ohne MAXAGE und mit PURGE gestartet. Das dauert dann aber auch nicht allzu lange.
Außerdem läuft die Synchronisation während der Produktivzeit ständig mit den Monitoring-Optionen "/MON:10 /MOT:28".
Erstere schaut auf die Anzahl an Änderungen und startet den Sync erst nach 10. Die 2. ist die Zeit in Minuten, nach welcher frühestens wieder synchronisiert wird.
Grüße
ich hatte dasselbe Problem mit robocopy und habe mir mit der Option "/MAXAGE:1" geholfen. Erfasse also nur Files des letzten Tages. Das ist bei den zu synchronisierenden 600 GB in wenigen Sekunden erledigt.
Am Wochenende wird dann der Job ohne MAXAGE und mit PURGE gestartet. Das dauert dann aber auch nicht allzu lange.
Außerdem läuft die Synchronisation während der Produktivzeit ständig mit den Monitoring-Optionen "/MON:10 /MOT:28".
Erstere schaut auf die Anzahl an Änderungen und startet den Sync erst nach 10. Die 2. ist die Zeit in Minuten, nach welcher frühestens wieder synchronisiert wird.
Grüße
1
Danke viragomann
Das probiere ich gerne aus.
Das probiere ich gerne aus.
