48748
28.05.2007, aktualisiert um 12:45:46 Uhr
7908
6
0
robocopy im netzwerk von ntfs nach ext3
Hallo,
Ich möchte mit robocopy meine Datensicherung im Netzwerk betreiben. Dabei werden nur W2000 und XP mit NTFS auf einen Linuxserver mit ext3 gesichert. Die Sicherungsplatte auf dem Server ist als Netzwerklaufwerk eingebunden.
Sichere ich testweise mit robocopy "c:\quelle c:\ziel /mir" funktioniert alles wunderbar wie es eben soll.
Ist das Ziel ein 2. Windowsrechner mit NTFS funktioniert es ebenso. Beim schreiben auf den Server ( Linux mit ext3 ) werden einige Dateien nochmals kopiert, obwohl sie schon da sind. Sie sind auch nicht aktueller! sondern tragen das gleiche Datum. Es sind keine veränderten daten sondern zum Beispiel eine frisch erstellte TXT-datei, die niemand geöffnet oder verändert hat. Trotzdem wird sie immer wieder neu gesichert. Beim sichern auf den Windowsrechner und intern wird korrekt nur einmmal kopiert und danach "skip". Die ausgabe von robocopy gibt an, dass die betreffenden DAteien kopiert worden sind, weil sie neuer bzw. älter waren . Da es aber nicht bei txts bleibt und ich die Datensicherung übers internet VPN mache mit begrenztem upload störe ich mich an jeder kleinen Datei. Das problem tritt auch mit xxcopy / xcopy auf.
Ich vermute dass es mit dem Filesystem zu tuen hat. Um die Atribute von ntfs erst garnicht zu kopieren rufe ich den befehl mit /nocopy auf. Dann wird aber garnichts mehr kopiert!
Ich habe nun schon die Linuxplatte mit ntfs installiert und mich mit nfts-g3 versucht, was ntfs unter Linux nun schreiben können soll aber bislang ohne erfolg.
Hoffe mir kann geholfen werden.
Danke vorab
Ich möchte mit robocopy meine Datensicherung im Netzwerk betreiben. Dabei werden nur W2000 und XP mit NTFS auf einen Linuxserver mit ext3 gesichert. Die Sicherungsplatte auf dem Server ist als Netzwerklaufwerk eingebunden.
Sichere ich testweise mit robocopy "c:\quelle c:\ziel /mir" funktioniert alles wunderbar wie es eben soll.
Ist das Ziel ein 2. Windowsrechner mit NTFS funktioniert es ebenso. Beim schreiben auf den Server ( Linux mit ext3 ) werden einige Dateien nochmals kopiert, obwohl sie schon da sind. Sie sind auch nicht aktueller! sondern tragen das gleiche Datum. Es sind keine veränderten daten sondern zum Beispiel eine frisch erstellte TXT-datei, die niemand geöffnet oder verändert hat. Trotzdem wird sie immer wieder neu gesichert. Beim sichern auf den Windowsrechner und intern wird korrekt nur einmmal kopiert und danach "skip". Die ausgabe von robocopy gibt an, dass die betreffenden DAteien kopiert worden sind, weil sie neuer bzw. älter waren . Da es aber nicht bei txts bleibt und ich die Datensicherung übers internet VPN mache mit begrenztem upload störe ich mich an jeder kleinen Datei. Das problem tritt auch mit xxcopy / xcopy auf.
Ich vermute dass es mit dem Filesystem zu tuen hat. Um die Atribute von ntfs erst garnicht zu kopieren rufe ich den befehl mit /nocopy auf. Dann wird aber garnichts mehr kopiert!
Ich habe nun schon die Linuxplatte mit ntfs installiert und mich mit nfts-g3 versucht, was ntfs unter Linux nun schreiben können soll aber bislang ohne erfolg.
Hoffe mir kann geholfen werden.
Danke vorab
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 59956
Url: https://administrator.de/forum/robocopy-im-netzwerk-von-ntfs-nach-ext3-59956.html
Ausgedruckt am: 22.04.2025 um 15:04 Uhr
6 Kommentare
Neuester Kommentar
Moin!
ich denke nicht, dass Du das mit dem robocopy hinbekommst, da das Zielshare kein NTFS hat, worauf das robocopy beim incrementellen Backup angewiesen ist.
Ich hätte einen anderen Vorschlag: NTBackup
Das ist bei Windows mit dabei und kann auch incrementelles Backup, wobei dort die Prüfung auf der Quellseite duchgeführt wird. Auf Deinem ext3-Share würde dann nur der Backup-Kontainer liegen.
Ralf
ich denke nicht, dass Du das mit dem robocopy hinbekommst, da das Zielshare kein NTFS hat, worauf das robocopy beim incrementellen Backup angewiesen ist.
Ich hätte einen anderen Vorschlag: NTBackup
Das ist bei Windows mit dabei und kann auch incrementelles Backup, wobei dort die Prüfung auf der Quellseite duchgeführt wird. Auf Deinem ext3-Share würde dann nur der Backup-Kontainer liegen.
Ralf
Hallo DerBert und willkommen im Forum!
Für eine inkrementelle Sicherung mittels (x)xcopy könntest Du auf das "Archiv"-Attribut der Quelldateien zurückgreifen, welches Du über die Option "/m" auswerten und rücksetzen kannst.
HTH
bastla
Für eine inkrementelle Sicherung mittels (x)xcopy könntest Du auf das "Archiv"-Attribut der Quelldateien zurückgreifen, welches Du über die Option "/m" auswerten und rücksetzen kannst.
HTH
bastla
morgen und danke für die schnellen Antworten. Also zu Robocopy habe ich folgenden Hinweis gefunden : " Source and destination volumes must both be NTFS to copy Security, Ownership or Auditing information." Das ist ja auch logisch und sollte ich eigentlich mit "/NOCOPY" abfangen, was aber nicht der fall ist.
Habe NTbackup kurz angetestet. Ich glaube das hilft mir nicht wirklich weiter und hole mal weiter aus.
Ich habe 2 Standorte mit VPN über DSL verbunden. Am Standort A ist der Linuxserver, der alle DAtensicherungen aufnimmt. Am Standort B wird ein Rechner täglich inkrementell mit Acronis True Image gesichert. Dabei sichere ich die Daten erst auf einer andreren Platte des dortigen Rechners, weil bei einem inkrementellen Backup der Abgleich QUelle/Ziel selbst bei Dateien im GB-Bereich recht lange dauert
. Danach wollte ich die Daten auf den Server schieben mit Robocopy oder irgendwie anders. Auf die NTFS-Flags lege ich natürlich keinen Wert die hab ich ja schon in dem Acronisfile eingespert und die NTbackuplösung hier anzusetzen wäre doppelt gemoppelt und führt mich meiner Meinung nach zum alten Problem.
Die Idee mit dem Archivattribut ist super und funktioniert so auch. Acronis setzt scheinbar auch automatisch das Attributbit. Was wenn ich einen normale Daten ohne Atributbit sichern möchte. Wenn eine Datei erstellt oder verändert wird setzt man ja nicht automatisch das Bit?
Und danke für den warmen Empfang hier bin begeistert von dem Forum. In den meisten Foren führt man ja Selbstgespräche und löst die Problem nach 12 Tagen selbst oder nie.
Habe NTbackup kurz angetestet. Ich glaube das hilft mir nicht wirklich weiter und hole mal weiter aus.
Ich habe 2 Standorte mit VPN über DSL verbunden. Am Standort A ist der Linuxserver, der alle DAtensicherungen aufnimmt. Am Standort B wird ein Rechner täglich inkrementell mit Acronis True Image gesichert. Dabei sichere ich die Daten erst auf einer andreren Platte des dortigen Rechners, weil bei einem inkrementellen Backup der Abgleich QUelle/Ziel selbst bei Dateien im GB-Bereich recht lange dauert
. Danach wollte ich die Daten auf den Server schieben mit Robocopy oder irgendwie anders. Auf die NTFS-Flags lege ich natürlich keinen Wert die hab ich ja schon in dem Acronisfile eingespert und die NTbackuplösung hier anzusetzen wäre doppelt gemoppelt und führt mich meiner Meinung nach zum alten Problem.Die Idee mit dem Archivattribut ist super und funktioniert so auch. Acronis setzt scheinbar auch automatisch das Attributbit. Was wenn ich einen normale Daten ohne Atributbit sichern möchte. Wenn eine Datei erstellt oder verändert wird setzt man ja nicht automatisch das Bit?
Und danke für den warmen Empfang hier bin begeistert von dem Forum. In den meisten Foren führt man ja Selbstgespräche und löst die Problem nach 12 Tagen selbst oder nie.
Hallo DerBert!
Vielleicht nochmals zur Klarstellung:
Archivbit gesetzt = seit dem letzten Rücksetzen dieses Bits wurde die Datei verändert bzw ist neu,
wobei das Rücksetzen durch das Backup-Programm erledigt wird, oder mit "attrib -a Filename" auch per Commandline/Batch erfolgen kann (siehe "attrib /?").
Grüße
bastla
Wenn eine Datei erstellt oder verändert wird setzt man ja nicht automatisch das Bit?
Doch, genau das ist die Idee dahinter: Dateien mit gesetztem Archivbit (Bedeutung eigentlich: "noch zu archivieren") wurden seit der letzten Sicherung verändert - daher bewirkt ein "xcopy /m", dass diese Datei kopiert, aber gleichzeitig (durch Rücksetzen des Archivbits) als "bereits archiviert" gekennzeichnet wird.Acronis setzt scheinbar auch automatisch das Attributbit.
... zurück, nehme ich an. In diesem Fall könnte vor dem Sichern mit Acronis mit "xcopy /a" bereits die alternative Sicherung erfolgen, da der Schalter "/a" zwar das Archivbit berücksichtigt, aber nicht ändert.Vielleicht nochmals zur Klarstellung:
Archivbit gesetzt = seit dem letzten Rücksetzen dieses Bits wurde die Datei verändert bzw ist neu,
wobei das Rücksetzen durch das Backup-Programm erledigt wird, oder mit "attrib -a Filename" auch per Commandline/Batch erfolgen kann (siehe "attrib /?").
Grüße
bastla
Vielleicht fährst du mir rsync besser, da es ja auch den Datenstrom komprimieren kann.
Da rsync bei fast jeder Linux Distri als Paket vorhanden ist, brauchst du noch das entsprechende Programm für Windows
Hier ein Link zu cwSync für Windows
http://www.itefix.no/phpws/index.php?module=pagemaster&PAGE_user_op ...
Die Konfiguration ist etwas komplizierter, aber schaffbar
Ich hoffe, das ich dir damit helfen konnte.
mfg
Schnitzelchen
Da rsync bei fast jeder Linux Distri als Paket vorhanden ist, brauchst du noch das entsprechende Programm für Windows
Hier ein Link zu cwSync für Windows
http://www.itefix.no/phpws/index.php?module=pagemaster&PAGE_user_op ...
Die Konfiguration ist etwas komplizierter, aber schaffbar
Ich hoffe, das ich dir damit helfen konnte.
mfg
Schnitzelchen
Danke bastla jetzt hab ich es verstanden. Wusste nicht dass jede Datei beim erstellen/verändern das Archivbit gesetzt bekommmt. Es funktioniert jetzt auch so wie ich mir das vorstelle. Ich verstehe leider immer noch nicht warum einige dateien mit dem alten Aufruf erneut kopiert wurden. Werde mich mit ntfs unter Linux weiter ausprobieren.
Vielen dank für die Hilfe.
Gruß
DerBert
Vielen dank für die Hilfe.
Gruß
DerBert
