none
robocopy: "Archiv-Bit" ausreichend? RRS feed

 > 

  • Allgemeine Diskussion

  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Windows-Profis,

    ich hoffe ihr könnt mir bei meinem kleinen Problem helfen.

    Kurz eine Beschreibung der Situation:

    Um die Fileserverdaten unserer deutschen Außenbüros zu sichern verwenden wir Robocopy. Als Platform sind Hyper-V-guests mit Windows 2008R2 im Einsatz. Das Zielsystem ist ein SAMBA-Server. Die Sicherungen laufen inkrementell unter der Woche jede Nacht und am Wochenende mit Löschen der EXTRA-Dateien.

    Nun haben wir zwei Fileserver mit einer sehr großen Datenmenge. Die Sicherung benötigt inzwischen so lang, dass sie bereits in den Morgen des nächsten Tages läuft (was nicht sein soll).

    Nun meine Frage. Wir möchten unter der Woche nur Dateien und Verzeichnisse sichern, welche das "Archiv-bit" gesetzt haben. Jetzt ist mir auf dem SAMBA-Server aufgefallen, dass ständig Dateien von der Robocopy-Sicherung angefaßt werden. Meine Idee wäre nun, dass ich zusätzlich noch die Parameter "/XN" und "/XC" mit angebe (also Ausschluss von neueren und geänderten Dateien). Tue ich mir damit einen gefallen? Oder laufe ich dabei Gefahr nicht alle gewollten Dateien und Verzeichnisse zu erwischen?
    Donnerstag, 3. Mai 2012 06:21
    |

Alle Antworten

  • Discussion
    Anmelden
    0
    Anmelden

    * JoernFFM (Thu, 3 May 2012 06:21:16 +0000)

    Um die Fileserverdaten unserer deutschen Außenbüros zu sichern verwenden wir Robocopy. Als Platform sind Hyper-V-guests mit Windows 2008R2 im Einsatz. Das Zielsystem ist ein SAMBA-Server. Die Sicherungen laufen inkrementell unter der Woche jede Nacht und am Wochenende mit Löschen der EXTRA-Dateien.

    Nun haben wir zwei Fileserver mit einer sehr großen Datenmenge. Die Sicherung benötigt inzwischen so lang, dass sie bereits in den Morgen des nächsten Tages läuft (was nicht sein soll).Nun meine Frage. Wir möchten unter der Woche nur Dateien und Verzeichnisse sichern, welche das "Archiv-bit" gesetzt haben. Jetzt ist mir auf dem SAMBA-Server aufgefallen, dass ständig Dateien von der Robocopy-Sicherung angefaßt werden. Meine Idee wäre nun, dass ich zusätzlich noch die Parameter "/XN" und "/XC" mit angebe (also Ausschluss von neueren und geänderten Dateien). Tue ich mir damit einen gefallen? Oder laufe ich dabei Gefahr nicht alle gewollten Dateien und Verzeichnisse zu erwischen?

    Nach welchem Kriterium sichert ihr und wo ist das Problem?

    Thorsten

    Donnerstag, 3. Mai 2012 09:49
    |
  • Discussion
    Anmelden
    0
    Anmelden
    Hallo Thorsten,


    Danke für die Antwort.

    Unser Sicherungskonzept für die Fileserver unserer Außenbüros sieht so aus, dass per Robocopy unter der Woche Abends nur Änderungen auf unseren zentralen SAMBA-Server geschoben werden sollen (per Archiv-Bit). Am Wochenende wird dann noch die Sicherungsprodzedur durch Suche nach gelöschten Dateien/Verzeichnissen auf der Quelle erweitert.

    Die Daten auf unserem SAMBA-Fileserver werden zudem noch jeden Abend auf Band gesichert und archiviert.

    Das Problem sieht bei uns so aus, dass bei zwei Servern die Sicherungsläufe unter der Woche zu lange dauern. Ich habe nun den Verdacht, dass er unter der Woche noch auf der SAMBA-Seite Dateien und Verzeichnisse checkt. Und dass soll er eigentlich nicht, weil das den benötigten Sicherungszeitraum in die Länge zieht. Die Robocopy-Sicherung soll unter der Woche nur die Fileserverdaten mit gesetztem Archiv-Bit auf den SAMBA-Server schieben und das Archiv-Bit auf dem Fileserver zurücksetzen.
    Donnerstag, 3. Mai 2012 13:26
    |
  • Discussion
    Anmelden
    0
    Anmelden

    * JoernFFM (Thu, 3 May 2012 13:26:33 +0000)

    Das Problem sieht bei uns so aus, dass bei zwei Servern die Sicherungsläufe unter der Woche zu lange dauern.

    Dauern sie denn länger als früher? Dann ist vielleicht die Datenmenge gewachsen.

    Ich habe nun den Verdacht, dass er unter der Woche noch auf der
    SAMBA-Seite Dateien und Verzeichnisse checkt. Und dass soll er
    eigentlich nicht, weil das den benötigten Sicherungszeitraum in die
    Länge zieht. Die Robocopy-Sicherung soll unter der Woche nur die
    Fileserverdaten mit gesetztem Archiv-Bit auf den SAMBA-Server schieben
    und das Archiv-Bit auf dem Fileserver zurücksetzen.

    Dann poste hier mal den Robocopy-Befehl.

    Thorsten

    Freitag, 4. Mai 2012 14:13
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Die Datenmenge ist sicherlich gewachsen. Der Grund warum die Jobs aber nun solange dauern ist einmal, dass wir von einem 32-bit W2k3-Server auf einen 64-bit W2k8-R2-Server gewechselt sind. Und bei einem der Fileserver (dem größten) haben die dortigen Kollegen eine Filesystemstruktur angelegt, welche die maximale Zeichenlänge überschreitet. Somit konnte die komplette Unterstruktur mit dem alten 32-bit-System nie gesichert werden. Nun funktioniert der Bereich... und der ist nicht gerade klein.

    Ich habe bereits einige Ausnahmen für Robocopy definiert (z.B. mp3, iso, wma etc.). Aber mehr geht leider nicht.

    Zudem drängt sich mir der Verdacht auf, dass das Thema "Hyper-V" noch mitspielt. Den neuen Fileserver haben wir mittels Hyper-V virtualisiert. Ich kann es zwar nicht beweisen, aber mir kommt es so vor, dass die Robocopy-Sicherungen nun länger benötigen (anhand von Vergleichen früherer Robocopy-Logs mit aktuellen von Fileservern unter Hyper-V).

    Hier sind die Paramater mit denen ich den Robocopy-Befehl aufrufe: "/JOB *.* /FP /NS /NDL /S /E /COPY:DATSU /NP /ETA /XO /XJ /M /R:10 /W:5 /XX /MT" (Quelle und Ziel habe ich herausgelassen)

    Montag, 7. Mai 2012 05:19
    |
  • Discussion
    Anmelden
    0
    Anmelden

    * JoernFFM (Mon, 7 May 2012 05:19:28 +0000)

    Hier sind die Paramater mit denen ich den Robocopy-Befehl aufrufe: "/JOB . /FP /NS /NDL /S /E /COPY:DATSU /NP /ETA /XO /XJ /M /R:10 /W:5 /XX /MT" (Quelle und Ziel habe ich herausgelassen)

    /S :: copy Subdirectories, but not empty ones
    /E :: copy subdirectories, including Empty ones

    ...zeugt nicht gerade von Sorgfalt. Abgesehen davon sieht es ordentlich aus, ich würde aber /xo und /xx herausnehmen.

    Deine Idee, "zusätzlich noch die Parameter "/XN" und "/XC" mit [anzugeben] (also Ausschluss von neueren und geänderten Dateien)" ist natürlich genial. Damit wirst du die Sicherungszeit radikal reduzieren.

    Abgesehen davon, guck' dir mal "/MON und /MOT" an.

    Thorsten

    Montag, 7. Mai 2012 10:28
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Die Datenmenge ist sicherlich gewachsen. Der Grund warum die Jobs aber nun solange dauern ist einmal, dass wir von einem 32-bit W2k3-Server auf einen 64-bit W2k8-R2-Server gewechselt sind. Und bei einem der Fileserver (dem größten) haben die dortigen Kollegen eine Filesystemstruktur angelegt, welche die maximale Zeichenlänge überschreitet. Somit konnte die komplette Unterstruktur mit dem alten 32-bit-System nie gesichert werden. Nun funktioniert der Bereich... und der ist nicht gerade klein.

    Ich habe bereits einige Ausnahmen für Robocopy definiert (z.B. mp3, iso, wma etc.). Aber mehr geht leider nicht.

    Zudem drängt sich mir der Verdacht auf, dass das Thema "Hyper-V" noch mitspielt. Den neuen Fileserver haben wir mittels Hyper-V virtualisiert. Ich kann es zwar nicht beweisen, aber mir kommt es so vor, dass die Robocopy-Sicherungen nun länger benötigen (anhand von Vergleichen früherer Robocopy-Logs mit aktuellen von Fileservern unter Hyper-V).

    Hier sind die Paramater mit denen ich den Robocopy-Befehl aufrufe: "/JOB *.* /FP /NS /NDL /S /E /COPY:DATSU /NP /ETA /XO /XJ /M /R:10 /W:5 /XX /MT" (Quelle und Ziel habe ich herausgelassen)

    Das mit /S und /E hat Dir Thorsten ja schon gepostet. Was ich noch anmerken möchte:

    Warum sicherst Du nicht im Backup-Modus (/B)? Und warum werden die Owner-Informationen nicht mit gesichert? (DATSOU statt DATSU)?

    Gruß

    -Axel-

    Niveau sieht nur von unten aus wie Arroganz

    Montag, 7. Mai 2012 10:34
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Ich habe nun mal beide Ratschläge beherzt und folgende Änderungen durchgeführt:

    • /xo und /xx herausgenommen
    • statt /DATSU /DATSOU eingetragen

    Warum Robocopy in seiner Log-Datei /S und /E schreibt weiß ich nicht. Angegeben in der Befehlsdatei habe ich nur /E (habe die angegebenen Paramter aus der letzten Sicherungslogdatei genommen).

    Die Paramter /MON und /MOT möchte ich eigentlich nicht verwenden. Soweit ich das verstehe würde robocopy dann im Hintergrund laufen und in regelmäßigen Abständen auf Änderungen überprüfen. Da wir keine sonderlich starke Verbindung in unseren Außenbüros haben, möchte ich sowenig Last während der Arbeitszeit erzeugen wie möglich.

    Montag, 7. Mai 2012 13:43
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Deine Idee, "zusätzlich noch die Parameter "/XN" und "/XC" mit [anzugeben] (also Ausschluss von neueren und geänderten Dateien)" ist natürlich genial. Damit wirst du die Sicherungszeit radikal reduzieren.

    Abgesehen davon, guck' dir mal "/MON und /MOT" an.

    Thorsten

    Ich bin auf die Idee gekommen, weil ich denke, dass durch den Parameter /M schon allein alle Objekte mit dem "Archive-Bit" gesichert werden... und so soll es meines Erachtens auch sein... also nur die geänderten Dateien. Da ich aber auf dem Zielsystem feststellen kann, dass dennoch andauernd Dateien auf dem Zielsystem während des Backupjobs geöffnet werden, dachte ich, dass hier immer noch Dateichecks auf dem Zielsystem durchgeführt werden. Und dadurch auch der Sicherungszeitraum unnötig in die Länge gezogen wird.

    Liege ich hier falsch??

    Montag, 7. Mai 2012 13:46
    |
  • Discussion
    Anmelden
    0
    Anmelden
     
    > Die Paramter /MON und /MOT möchte ich eigentlich nicht verwenden.
    > Soweit ich das verstehe würde robocopy dann im Hintergrund laufen und
    > in regelmäßigen Abständen auf Änderungen überprüfen. Da wir keine
    > sonderlich starke Verbindung in unseren Außenbüros haben, möchte ich
    > sowenig Last während der Arbeitszeit erzeugen wie möglich.
     
    Dem würde ich mich anschließen - /MON ist nur dann empfehlenswert, wenn
    das Quellverzeichnis lokal liegt ;-)
     
    mfg Martin
     
    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Dienstag, 8. Mai 2012 10:48
    |
  • Discussion
    Anmelden
    0
    Anmelden

    * JoernFFM (Mon, 7 May 2012 13:46:33 +0000)

    Deine Idee, "zusätzlich noch die Parameter "/XN" und "/XC" mit [anzugeben] (also Ausschluss von neueren und geänderten Dateien)" ist natürlich genial. Damit wirst du die Sicherungszeit radikal reduzieren.

    Ich bin auf die Idee gekommen, weil ich denke, dass durch den Parameter /M schon allein alle Objekte mit dem "Archive-Bit" gesichert werden... und so soll es meines Erachtens auch sein... also nur die geänderten Dateien.

    Nur Dateien mit Archivbit gesetzt - aber keine geänderten oder neueren Dateien: also meines Erachtens gar keine Dateien.

    Da ich aber auf dem Zielsystem feststellen kann, dass dennoch andauernd Dateien auf dem Zielsystem während des Backupjobs geöffnet werden, dachte ich, dass hier immer noch Dateichecks auf dem Zielsystem durchgeführt werden.

    Wie stellst du das fest? Bei /xn und /xc natürlich.

    Thorsten

    Dienstag, 8. Mai 2012 21:18
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Da ich aber auf dem Zielsystem feststellen kann, dass dennoch andauernd Dateien auf dem Zielsystem während des Backupjobs geöffnet werden, dachte ich, dass hier immer noch Dateichecks auf dem Zielsystem durchgeführt werden.

    Wie stellst du das fest? Bei /xn und /xc natürlich.

    Thorsten

    Wie ich bereits erwähnte, sichern wir auf einen UNIX-Samba-Server. Dort bin ich in der Lage durch SAMBA-Befehle mir anzeigen zu lassen, welche Dateien von welchem System mit welchem User sich momentan im Zugriff befinden.

    Und dort sehe ich während der Sicherung unserer beiden großen Fileserver, dass Robocopy andauernd auf Dateien zugreift. Und das soll Robocopy in meinen Augen nicht tun wenn ich nur möchte, dass rein die Archive-Bit-Objekte auf den SAMBA-Server geschoben werden sollen.

    In meinem Verständnis werden jegliche sicherungsrelevanten Änderungen auf unseren Fileservern bereits durch das Setzen des Archive-Bits auf den jeweiligen Objekten abgedeckt. Da soll Robocopy nicht auch noch Checken, ob es im Vergleich mit dem jeweiligen Objekt auf den SAMBA-Zielsystem Änderungen gibt.

    Übrigens... Du hast auch recht mit dem Angeben der Parameter "/xn" und "xc"... da wird dann gar nichts mehr gesichert. Also habe ich mir damit ein Eigentor geschossen. :)

    Mittwoch, 9. Mai 2012 05:21
    |
  • Discussion
    Anmelden
    0
    Anmelden

    * JoernFFM (Wed, 9 May 2012 05:21:37 +0000)

    Da ich aber auf dem Zielsystem feststellen kann, dass dennoch andauernd Dateien auf dem Zielsystem während des Backupjobs geöffnet werden, dachte ich, dass hier immer noch Dateichecks auf dem Zielsystem durchgeführt werden.

    Wie stellst du das fest? Bei /xn und /xc natürlich.

    Wie ich bereits erwähnte, sichern wir auf einen UNIX-Samba-Server. Dort bin ich in der Lage durch SAMBA-Befehle mir anzeigen zu lassen, welche Dateien von welchem System mit welchem User sich momentan im Zugriff befinden.

    Das war mir schon klar. Ich dachte, du wirst ein bißchen konkreter (welcher Befehl, welche Ausgabe, etc.)

    Und dort sehe ich während der Sicherung unserer beiden großen Fileserver, dass Robocopy andauernd auf Dateien zugreift. Und das soll Robocopy in meinen Augen nicht tun wenn ich nur möchte, dass rein die Archive-Bit-Objekte auf den SAMBA-Server geschoben werden sollen.

    In meinem Verständnis werden jegliche sicherungsrelevanten Änderungen auf unseren Fileservern bereits durch das Setzen des Archive-Bits auf den jeweiligen Objekten abgedeckt. Da soll Robocopy nicht auch noch Checken, ob es im Vergleich mit dem jeweiligen Objekt auf den SAMBA-Zielsystem Änderungen gibt.

    Sehe ich auch so. Nimm einfach Process Monitor und guck nach, was Robocopy macht.

    Thorsten

    Mittwoch, 9. Mai 2012 09:09
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Ich vermute inzwischen, dass ich auf der falschen Seite geschaut habe. Nachdem ich mich mal durch die Untiefen unserer Fileserver gewühlt habe, ist mir aufgefallen, dass verdächtig viele Dateien noch das Archive-Bit gesetzt haben, obwohl diese Objekte ein Änderungsdatum weit in der Vergangenheit haben. Kein Wunder also, dass die Robocopy-Jobs so lange dauern. Nun habe ich bereits im Netz in diversen Foren (auch hier im Forum) Hinweise darauf gefunden, dass mehrere Leute mit diesem Verhalten in der Robocopy-Version von Windows 2008R2 Probleme haben. Ich versuche nun ein paar Parameterkombinationen damit Robocopy endlich die Archive-Flags entfernt.

    Zur Not muss ich eben mal mittels "attrib"-Befehl zu einem bestimmten Zeitpunkt alle Archive-Flags zurücksetzen.

    Mittwoch, 9. Mai 2012 09:14
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo,

    wir warten auf Feedback von Dir, wie es mit dem Tests gelaufen ist.

    Gruss,
    Raul

    Raul Talmaciu, MICROSOFT 
    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Freitag, 11. Mai 2012 06:23
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo,

    tja... viel kann ich noch nicht berichten. Also verschiedene Parametervarianten haben keine Abhilfe verschafft.

    Was ich nun zudem versuche ist, dass ich das Laufzeitverhalten der Robocopy-Jobs verändere. Bisher war es so, dass jedes Backup aus einem Skript bestand, welches nacheinander zwei Robocopy-Jobs aufrief (also ein Robocopy-Job für die Homelaufwerke und einer für den Datenbereich des jeweiligen Fileservers). Nun habe ich die Umgebung derart abgewandelt, dass gleichzeit beide Robocopy-Jobs loslaufen. Ob das Abhilfe geschaffen hat kann ich erst nächste Woche feststellen.

    Was ich bisher zusammenfassend sagen kann ist, dass:

    • Robocopy in der Version von Windows 2008R2 ein anderes Verhalten an den Tag legt wie es bei der bisher eingesetzten Version "XP010" der Fall war
    • eventuell noch der Umstand mitspielt, dass wir nun in eine HyperV-Umgebung mit dem Fileserver gewechselt sind (vorher "bare metall")

    Ich bleibe am Ball und werde weiterhin meine Erkenntnisse hier mitteilen.

    Freitag, 11. Mai 2012 07:56
    |