22
Große Dateien mit minimalen Änderungen optimiert zwischen zwei Windows Servern replizieren
Hallo,
Ich habe hier ein Verzeichnis auf einem Windows 2022 Server was zu einem 2. Windows 2022 Server repliziert werden soll.
Nennen wir es mal d:\Daten1.
Dort sind ca. 400 Dateien mit zusammen 20 TB gespeichert.
Dies sind alles Datenbank-Snapshots mit minimalen Änderungen pro Tag.
Datei d:\daten1\db224.snap, 750 GB, Änderungen ca. 2 MB pro Tag.
Bei vielen Dateien ändert sich auf der Inhalt gar nicht. Es ändert sich aber täglich das Schreibdatum.
Auch kann ich nicht sagen welche Datei sich geändert hat und welche nicht.
Mittels robocopy werden nun jeden Tag 20 TB über die arme Leitung zu einer SMB-Freigabe gejuckelt, obwohl es eigentlich nur 1 GB wäre.
Rsync sollte die Dateien doch in Blöcke zerlegen und viel weniger übertragen können.
Aber Rsync mit Windows ist nicht so out of the Box.
Würde es mit Rsync unter Windows funktionieren?
Kennt Jemand eine Alternative zu Rsync?
Danke
Stefan
Ich habe hier ein Verzeichnis auf einem Windows 2022 Server was zu einem 2. Windows 2022 Server repliziert werden soll.
Nennen wir es mal d:\Daten1.
Dort sind ca. 400 Dateien mit zusammen 20 TB gespeichert.
Dies sind alles Datenbank-Snapshots mit minimalen Änderungen pro Tag.
Datei d:\daten1\db224.snap, 750 GB, Änderungen ca. 2 MB pro Tag.
Bei vielen Dateien ändert sich auf der Inhalt gar nicht. Es ändert sich aber täglich das Schreibdatum.
Auch kann ich nicht sagen welche Datei sich geändert hat und welche nicht.
Mittels robocopy werden nun jeden Tag 20 TB über die arme Leitung zu einer SMB-Freigabe gejuckelt, obwohl es eigentlich nur 1 GB wäre.
Rsync sollte die Dateien doch in Blöcke zerlegen und viel weniger übertragen können.
Aber Rsync mit Windows ist nicht so out of the Box.
Würde es mit Rsync unter Windows funktionieren?
Kennt Jemand eine Alternative zu Rsync?
Danke
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: 7377190622
Url: https://administrator.de/contentid/7377190622
Ausgedruckt am: 17.11.2024 um 19:11 Uhr
22 Kommentare
Neuester Kommentar
Moin,
Für sowas würde ich schon rsync nehmen. z.B. wie es hier für das kopieren über einen sshtunnel zwischen zwei Windowskisten beschrieben ist.
Mit cygwin hatte ich bisher immer gute Erfahrungen und es auch immer benutzt, als noch kein WSL zur Verfügung stand.
lks
Für sowas würde ich schon rsync nehmen. z.B. wie es hier für das kopieren über einen sshtunnel zwischen zwei Windowskisten beschrieben ist.
Mit cygwin hatte ich bisher immer gute Erfahrungen und es auch immer benutzt, als noch kein WSL zur Verfügung stand.
lks
Cygwin sollte dafür recht gut gehen - alternativ wenn Windows bereits ssh unterstützt (hier bin ich nicht sicher da ich kein Win mehr nutze) ggf. gehts ja auch dann direkt.
Allerdings muss dir auch klar sein - wenn es sich um eine einzelne Datei mit 750 GB handelt (was mich zwar wundern würde - aber... eigentlich auch nich mehr wenn ich seh was so für Software heute als "Marktreif" aufm Markt geworfen wird...) das allein das bilden der Checksums schon einiges an Zeit kosten wird.
Wenn es sich um eine DB handelt - ggf. lässt sich ja da bei der DB direkt was finden das die sich repliziert? Sozusagen "Master-Slave" Betrieb?
Allerdings muss dir auch klar sein - wenn es sich um eine einzelne Datei mit 750 GB handelt (was mich zwar wundern würde - aber... eigentlich auch nich mehr wenn ich seh was so für Software heute als "Marktreif" aufm Markt geworfen wird...) das allein das bilden der Checksums schon einiges an Zeit kosten wird.
Wenn es sich um eine DB handelt - ggf. lässt sich ja da bei der DB direkt was finden das die sich repliziert? Sozusagen "Master-Slave" Betrieb?
Hi
einfache Backups gehen nicht, wenn du diese mit den Ola Halengreen Tools erstellst werden ja auch parallel die Wiederherstellungsscripte erstellt. Wir sichern in 30min Takt die Logs und dann Nachts Dif. Backup und am WE Voll, so können wir recht granular wiederherstellen und das Volumen hält sich auch in Grenzen.
Alternativ kannst auch eine AOG erstellen und den Sekundären Node "näher" an den Replizierenden Server stellen und darüber dann die Backups ziehen, dass würde dann nicht einmal den Primärnode belasten da man bei einer AOG einstellen kann, das er nur vom sekundären Node ziehen soll, der ist dann, sofern nur Backups gezogen werden, nicht Lizenzpflichtig (siehe auf: https://download.microsoft.com/download/6/6/0/66078040-86d8-4f6e-b0c5-e9 ... Seite 28). Damit kannst evtl. das Bandbreitenproblem lösen. Fürs AOG muss der lediglich die gleiche Festplattenkonfiguration haben.
Gruß
@clSchak
einfache Backups gehen nicht, wenn du diese mit den Ola Halengreen Tools erstellst werden ja auch parallel die Wiederherstellungsscripte erstellt. Wir sichern in 30min Takt die Logs und dann Nachts Dif. Backup und am WE Voll, so können wir recht granular wiederherstellen und das Volumen hält sich auch in Grenzen.
Alternativ kannst auch eine AOG erstellen und den Sekundären Node "näher" an den Replizierenden Server stellen und darüber dann die Backups ziehen, dass würde dann nicht einmal den Primärnode belasten da man bei einer AOG einstellen kann, das er nur vom sekundären Node ziehen soll, der ist dann, sofern nur Backups gezogen werden, nicht Lizenzpflichtig (siehe auf: https://download.microsoft.com/download/6/6/0/66078040-86d8-4f6e-b0c5-e9 ... Seite 28). Damit kannst evtl. das Bandbreitenproblem lösen. Fürs AOG muss der lediglich die gleiche Festplattenkonfiguration haben.
Gruß
@clSchak
Hi,
ev. Storage Replication von Microsoft? Hab nur selbst keine Erfahrung damit. Wollten es mal nutzen, aber die Server hatten unterschiedliche HDDs und irgendwie wollte es nicht laufen. Auch mt gleicher Blocksize, gab es dann Fehler. War aber keine Zeit um das zu vertiefen.
Sg Dirm
ev. Storage Replication von Microsoft? Hab nur selbst keine Erfahrung damit. Wollten es mal nutzen, aber die Server hatten unterschiedliche HDDs und irgendwie wollte es nicht laufen. Auch mt gleicher Blocksize, gab es dann Fehler. War aber keine Zeit um das zu vertiefen.
Sg Dirm
Zitat von @maretz:
Wenn es sich um eine DB handelt - ggf. lässt sich ja da bei der DB direkt was finden das die sich repliziert? Sozusagen "Master-Slave" Betrieb?
Leider nicht. Es handelt sich um ein Warenwirtschaftssystem mit eigener DB was diese Dumps erstellt.Wenn es sich um eine DB handelt - ggf. lässt sich ja da bei der DB direkt was finden das die sich repliziert? Sozusagen "Master-Slave" Betrieb?
MS-SQL oder andere DB? Du kannst ja ein AOG erstellen, man muss dann ja nicht über den Listener die Verbindung herstellen (damit haben manchen Applikationen wohl ein Problem). Ich würde eh die Backup-Methode über Boardmitteln jeden anderen Tool vorziehen, das macht bei Restore die geringsten Probleme.
Moin,
wenn das Datenbank-System dazu nichts mitbringt, benötigst du im Prinzip etwas, was nur geänderte Blöcke repliziert.
Storage Snapshots > hier wären die Daten inkonsistent !
Falls virtualisiert, ChangeBlockTracking > z.B. mit Veeam Replikaten und über die Tools das Konsistentsetzen triggern ?
ReFS > BlockCloning ?
Wie oft soll das denn erfolgen?
Es geht wahrscheinlich um DR Fälle bzw Verfügbarkeit der DB...
Gruß
wenn das Datenbank-System dazu nichts mitbringt, benötigst du im Prinzip etwas, was nur geänderte Blöcke repliziert.
Storage Snapshots > hier wären die Daten inkonsistent !
Falls virtualisiert, ChangeBlockTracking > z.B. mit Veeam Replikaten und über die Tools das Konsistentsetzen triggern ?
ReFS > BlockCloning ?
Wie oft soll das denn erfolgen?
Es geht wahrscheinlich um DR Fälle bzw Verfügbarkeit der DB...
Gruß
Moin,
Bevor jeder hier meint, die Datenbank selbst sichern zu müssen:
So wie ich Stefan verstanden habe, will er nur die "Dumps" der Datenbank sichern. Da muß man nichts kompliziertes machen, Da reicht ein simples rsync.
lks
Bevor jeder hier meint, die Datenbank selbst sichern zu müssen:
So wie ich Stefan verstanden habe, will er nur die "Dumps" der Datenbank sichern. Da muß man nichts kompliziertes machen, Da reicht ein simples rsync.
lks
Zitat von @Lochkartenstanzer:
So wie ich Stefan verstanden habe, will er nur die "Dumps" der Datenbank sichern. Da muß man nichts kompliziertes machen, Da reicht ein simples rsync.
Korrekt.So wie ich Stefan verstanden habe, will er nur die "Dumps" der Datenbank sichern. Da muß man nichts kompliziertes machen, Da reicht ein simples rsync.
Die Software des Herstellers erstellt diese Dumps. Da habe ich keinen Einfluss drauf.
Auch keinen direkten Zugriff auf der Hauseigene-Datenbank.
Deren Software (Aufgabenplanung) schreibt diese Dumps in dieses Verzeichnis.
Das dauert ca. 4 Stunden. Danach habe ich 20 Stunden zeit diese Dumps woanders hinzukopieren.
Stefan
Moin,
was ist denn der Zweck des Kopierens bzw was soll damit abgefangen werden?
Abhängig davon könnte man noch ne DedupeAppliance ins Spiel bringen...
Also Dumps auf ne Quantum vDXI oder Dell vDataDomain (direkt oder als Kopie) und über die interne Blockreplizierung auf ne Ziel Appliance.
Nachteil: das lesen von dem Ziel ist extrem langsam.
Daher die Frage, was am Ziel damit passieren soll?
Gruß
was ist denn der Zweck des Kopierens bzw was soll damit abgefangen werden?
Abhängig davon könnte man noch ne DedupeAppliance ins Spiel bringen...
Also Dumps auf ne Quantum vDXI oder Dell vDataDomain (direkt oder als Kopie) und über die interne Blockreplizierung auf ne Ziel Appliance.
Nachteil: das lesen von dem Ziel ist extrem langsam.
Daher die Frage, was am Ziel damit passieren soll?
Gruß
Auf dem Server wo die Software läuft werden diese Dump lokal abgelegt.
Nun sollen Sie zu einem anderen Server in einem anderen Brandabschnitt repliziert werden.
Aufgrund der Größe werden diese nicht gesichert.
KMU Kunde. 2 einfache Server und 2 QNAP-NAS. Kein Storage oder ähnliches.
Stefan
Nun sollen Sie zu einem anderen Server in einem anderen Brandabschnitt repliziert werden.
Aufgrund der Größe werden diese nicht gesichert.
KMU Kunde. 2 einfache Server und 2 QNAP-NAS. Kein Storage oder ähnliches.
Stefan
zu groß gibt es nicht, es gibt nur zu wenig Bandbreite 
, wobei die 750GB via 1Gbit auch in 2-3h kopiert sein sollten (so lange man nicht Copy&Paste über Windows Boardmittel nutzt).
Wobei dir das auch nicht hilft, auch rsync wird alles kopieren, da das "last write" Datum der Dateien anders ist und somit auch der Hash-Wert der Datei sich ändert. Wenn du wirklich nur die Änderungen kopieren willst musst du auf die Blockebene runter und wäre in deinem Fall Veeam dein Freund. Das ist ja bis 10 Server / Clients kostenlos, das kommt auch gut mit "schlechter Bandbreite" zurecht.
Eine neue 10G Verbindung zwischen den RZ wird nur was bringen, wenn die Server und NAS auch bereits alle mit 10G angebunden sind, ansonsten bringt das nicht allzuviel.
, wobei die 750GB via 1Gbit auch in 2-3h kopiert sein sollten (so lange man nicht Copy&Paste über Windows Boardmittel nutzt).Wobei dir das auch nicht hilft, auch rsync wird alles kopieren, da das "last write" Datum der Dateien anders ist und somit auch der Hash-Wert der Datei sich ändert. Wenn du wirklich nur die Änderungen kopieren willst musst du auf die Blockebene runter und wäre in deinem Fall Veeam dein Freund. Das ist ja bis 10 Server / Clients kostenlos, das kommt auch gut mit "schlechter Bandbreite" zurecht.
Eine neue 10G Verbindung zwischen den RZ wird nur was bringen, wenn die Server und NAS auch bereits alle mit 10G angebunden sind, ansonsten bringt das nicht allzuviel.
Das ist ja mit einer der Fragen.
Rsync kann eigentlich Blockweise Daten kopieren. Zumindest im Prinzip.
Ob das Windows-Rsync das auch kann?
Rsync kann eigentlich Blockweise Daten kopieren. Zumindest im Prinzip.
Ob das Windows-Rsync das auch kann?
warum sollte rsync das tun - sofern man die flags richtig setzt? da kopiert der nicht alles neu...
kann ich dir so nicht sagen, wenn es keinen VSS Provider mitliefert oder auf anderen Wege auf VSS Snapshots zugreift, denke ich eher nicht.
Sind die Server virtuell oder physik? Wenn die physik sind, würde ich evtl. überlegen die auf VM umzustellen, erleichtert einen in vielen Situationen das Backup & Recovery (sofern der Kunde das mitmacht).
Sind die Server virtuell oder physik? Wenn die physik sind, würde ich evtl. überlegen die auf VM umzustellen, erleichtert einen in vielen Situationen das Backup & Recovery (sofern der Kunde das mitmacht).
Zitat von @clSchak:
zu groß gibt es nicht, es gibt nur zu wenig Bandbreite, wobei die 750GB via 1Gbit auch in 2-3h kopiert sein sollten (so lange man nicht Copy&Paste über Windows Boardmittel nutzt).
zu groß gibt es nicht, es gibt nur zu wenig Bandbreite
, wobei die 750GB via 1Gbit auch in 2-3h kopiert sein sollten (so lange man nicht Copy&Paste über Windows Boardmittel nutzt).Naja, kommt drauf an, ob man die 2-3 Stunden Zeit hat oder nicht.
Wobei dir das auch nicht hilft, auch rsync wird alles kopieren, da das "last write" Datum der Dateien anders ist und somit auch der Hash-Wert der Datei sich ändert.
Das stimmt so nicht. Denn wenn rsync das macht, dann benutzt du es falsch. Um die Fähigkeiten von rsync voll auszuschöpfen, brauchst Du jeweils einen rsync-Prozess auf dem Ziel und an der Quelle, d.h. Man muß rsync entweder per ssh oder rsync-server nutzen, damit die Fähigkeiten von rsync wirklich zum tragen kommen sollen. Solange man rsync wi ein normales cp,copy , xcopy oder robocopy nutzt bringt es kaum Geschwindigkeitsvorteile.
Wichtig ist natürlich auch, daß das lokale Speichermedium deutlich schneller als die Netzwerkverbindung sein sollte. rsync bringt z.B. kaum Vorteile wenn man über Netzwerk von SD-Karte zu SD-Karte synchronisiert, weil das lesen und berechnen der prüfsummen von den SD-Karten länger dauert, als einfach die Dateien zu übertragen.
Merke: Man muß nicht nur das richtige Werkzeug nehmen, sondern das Werkzeug auch richtig nutzen.
lks
1Zitat von @StefanKittel:
Das ist ja mit einer der Fragen.
Rsync kann eigentlich Blockweise Daten kopieren. Zumindest im Prinzip.
Ob das Windows-Rsync das auch kann?
Das ist ja mit einer der Fragen.
Rsync kann eigentlich Blockweise Daten kopieren. Zumindest im Prinzip.
Ob das Windows-Rsync das auch kann?
Siehe auch meinen Kommentar Große Dateien mit minimalen Änderungen optimiert zwischen zwei Windows Servern replizieren
Egal ob per cygwin oder wsl: wenn man das per rsync-protokoll ode per ssh nutzt kommt die blockweise übertragung zur geltung. Wenn man es allerdings wie ein simples copy (cp , copy , xcopy, robocopy, etc.) nutzt wirkt das nicht.
lks
wir nutzen kein rsync in der Form, darum war es eher eine Vermutung
Aber ich tippe mal, das rsync auch bessere Übertragungsraten wie M$ hinbekommt, zumindest sind das die Erfahrung die ich gemacht habe: die meisten M$ Produkte sind Netzwerktechnisch oftmals die "Bremser", vor allem das so simple Dinge wie "Filecopy" geht.
Aber gut zu wissen, dass rsync das kann. Thx @lks
Physik lässt sich aber nicht überlisten, bei rund 100-120MB/s geht das nicht schneller, auch durch wollen nicht (bei 110MB/s wären es 1,89h - Konstant) - selbst mit FC bekomme ich nicht "konstant 100%" der Leitungskapazität, wobei wir hier z.T. mit 2-3GB/s sichern - da ist dann der Backupserver und dessen Controller das Nadelör.
Aber ich tippe mal, das rsync auch bessere Übertragungsraten wie M$ hinbekommt, zumindest sind das die Erfahrung die ich gemacht habe: die meisten M$ Produkte sind Netzwerktechnisch oftmals die "Bremser", vor allem das so simple Dinge wie "Filecopy" geht.
Aber gut zu wissen, dass rsync das kann. Thx @lks
Zitat von @Lochkartenstanzer:
Naja, kommt drauf an, ob man die 2-3 Stunden Zeit hat oder nicht.
Zitat von @clSchak:
zu groß gibt es nicht, es gibt nur zu wenig Bandbreite, wobei die 750GB via 1Gbit auch in 2-3h kopiert sein sollten (so lange man nicht Copy&Paste über Windows Boardmittel nutzt).
zu groß gibt es nicht, es gibt nur zu wenig Bandbreite
, wobei die 750GB via 1Gbit auch in 2-3h kopiert sein sollten (so lange man nicht Copy&Paste über Windows Boardmittel nutzt).Naja, kommt drauf an, ob man die 2-3 Stunden Zeit hat oder nicht.
Physik lässt sich aber nicht überlisten
, bei rund 100-120MB/s geht das nicht schneller, auch durch wollen nicht (bei 110MB/s wären es 1,89h - Konstant) - selbst mit FC bekomme ich nicht "konstant 100%" der Leitungskapazität, wobei wir hier z.T. mit 2-3GB/s sichern - da ist dann der Backupserver und dessen Controller das Nadelör.Zitat von @clSchak:
Naja, kommt drauf an, ob man die 2-3 Stunden Zeit hat oder nicht.
Physik lässt sich aber nicht überlisten, bei rund 100-120MB/s geht das nicht schneller, auch durch wollen nicht (bei 110MB/s wären es 1,89h - Konstant) - selbst mit FC bekomme ich nicht "konstant 100%" der Leitungskapazität, wobei wir hier z.T. mit 2-3GB/s sichern - da ist dann der Backupserver und dessen Controller das Nadelör.
Zitat von @clSchak:
zu groß gibt es nicht, es gibt nur zu wenig Bandbreite, wobei die 750GB via 1Gbit auch in 2-3h kopiert sein sollten (so lange man nicht Copy&Paste über Windows Boardmittel nutzt).
zu groß gibt es nicht, es gibt nur zu wenig Bandbreite
, wobei die 750GB via 1Gbit auch in 2-3h kopiert sein sollten (so lange man nicht Copy&Paste über Windows Boardmittel nutzt).Naja, kommt drauf an, ob man die 2-3 Stunden Zeit hat oder nicht.
Physik lässt sich aber nicht überlisten
, bei rund 100-120MB/s geht das nicht schneller, auch durch wollen nicht (bei 110MB/s wären es 1,89h - Konstant) - selbst mit FC bekomme ich nicht "konstant 100%" der Leitungskapazität, wobei wir hier z.T. mit 2-3GB/s sichern - da ist dann der Backupserver und dessen Controller das Nadelör.Du hast mich vermutlich mißverstanden. Ich meinte, wenn das kopieren z.B. 4h dauert, aber man durch äußere Umstande dafür nur 3h hat, nützt das einem nichts.
Mir ist mal eine Installation untergekommen, die so eingerichtet war, daß das backup um Miternacht loslegte und i.d.R. 1h bis 2h erledigt war. Wenn die leute morgens um 6.00 anfingen zu Arbeiten, war alles schon "abgehakt". Aber ancheinend war im laufe der Zeit nachts mehr Last auf dem Server und auch die Datnmengen steigerten sich um das vielfache und plötzlich dauerte das Backup mehr als 6h und wenn die Leute anfingen zu arbeiten hat das noch mehr verzögert. d.h. irgendwann hatte man nicht mehr genug "Zeit für Backup". o.K. ich habe das dann umgestellt (war ursprünglich nicht mein Werk, ich habe es nur repariert). und schon waren die Backups deutlich schneller. (ohne Bandbreitenerweiterung).
lks
@Lochkartenstanzer da gebe ich dir recht, aber das sollte eigentlich auffallen, dafür bieten die meisten Systeme ja Statusmeldungen, Info-Mails usw. wenn man merkt das es langsam aber sicher immer länger dauert kann man gegensteuern, wenn es plötzlich passiert sollte man das auch mitbekommen und prüfen ob nicht ein Defekt vorliegt.
Zitat von @clSchak:
@Lochkartenstanzer da gebe ich dir recht, aber das sollte eigentlich auffallen, dafür bieten die meisten Systeme ja Statusmeldungen, Info-Mails usw. wenn man merkt das es langsam aber sicher immer länger dauert kann man gegensteuern, wenn es plötzlich passiert sollte man das auch mitbekommen und prüfen ob nicht ein Defekt vorliegt.
@Lochkartenstanzer da gebe ich dir recht, aber das sollte eigentlich auffallen, dafür bieten die meisten Systeme ja Statusmeldungen, Info-Mails usw. wenn man merkt das es langsam aber sicher immer länger dauert kann man gegensteuern, wenn es plötzlich passiert sollte man das auch mitbekommen und prüfen ob nicht ein Defekt vorliegt.
Genau das ist das Problem. Wenn der (Neu-)Kunde einen erst ruft, wenn irgendetwas nicht mehr geht. kann man da nichts mehr "rechtzeitig" ändern, sondern kann nur noch Feuerwehr spielen.
lks
Hallo Stefan,
dann will ich mal mit der Alternative kommen, die m.E. zu viel zu wenig bekannt ist: bvckup2.
Reines Windows-Programm, sehr kompakt, sehr schnell, macht blockbasierte Differenzsicherung, arbeitet effizient und als Windows-Service. Wird auf der Quelle installiert und kopiert dann per SMB zum Ziel.
Die blockbasierte Differenzsicherung funktioniert anders als rsync (das auf Quelle+Ziel laufen muss) ausschließlich auf der Quellseite. Dazu werden lokal entsprechende Informationen vorgehalten, die daher auf der Quelle Speicherplatz belegen, allerdings ziemlich wenig.
Habe ich mehrfach im Einsatz, läuft seit Jahren absolut wartungsarm und bisher auch störungsfrei. Setze ich gerade dann ein, wenn bei reiner Windows-Quelle über schmalbandige Leitungen zu einem remote Ziel gesichert werden soll.
Das Feature, das Du brauchst, ist Delta Copying, hier im Detail erklärt: bvckup2.com/kb/delta-copying.
Download ist eine 2-Wochen-Trial, einfach einmal ausprobieren.
Viele Grüße
DivideByZero
