Seite 1 von 1

Robocopy vs. SyncToy Performance

Verfasst: 19. Okt 2011, 07:22
von JoachimL
Hallo,
ich habe in den letzten Wochen SyncToy für mein Backup der Nutzdaten verwendet, beobachte dabei aber zwei Probleme:
  • offene Dateien (z.B. bei einem laufenden Clientbackup) führen zu Fehlern
  • SyncToy verwechselt anscheinend meine Backupplatten obwohl sie verschiedene Namen haben - ob das mehr als nur doppelte Arbeit für SyncToy bedeutet ist mir unklar
Ich überlege jetzt auf Robocopy zurückzugehen, und dabei auch gleich mit Schattenkopien für die Quellen nach http://www.malch.com/nikon/roboshadow.txt zu arbeiten.
  • Hat jemand diese Technik schon probiert und (positive oder negative) Erfahrungen gesammelt?
  • Braucht Robocopy (deutlich) länger als SyncToy für den Abgleich was zu kopiern ist? (Meine Backupplatten laufen auch am internen SATA, werden wöchentlich gewechselt)
Danke & Gruß Joachim

Re: Robocopy vs. SyncToy Performance

Verfasst: 19. Okt 2011, 08:06
von Vialli
...basiert SyncToy nicht auch auf Robocopy?

Re: Robocopy vs. SyncToy Performance

Verfasst: 19. Okt 2011, 16:38
von Zoppo
Hallo Joachm,

Ich verwende robocopy (allerdings WHS v1), um Daten vom WHS auf einen 2. WHS zu sichern (Shares > 2 GB).

Der WHS und der backup-server werden per lightsout geweckt und robocopy per taskplaner gestartet.
Nach dem backup gehen beide wieder schlafen (alles außerhalb der Clientsicherungszeit).

Es gibt auch ein Addin für robocopy. Allerdings hat es den kleinen Fahler, dass es ab und zu den Speicherort des Programms "robocopy" vergißt.

Über die Performance im Vergleich zu synctoy kann ich nicht viel sagen. Ich glaube aber nicht, dass robocopy länger braucht - eher im Gegenteil.
Synctoy hat mir vom handling auch nicht wirklich gefallen.

Grüße

Re: Robocopy vs. SyncToy Performance

Verfasst: 22. Okt 2011, 13:39
von JoachimL
Hab jetzt selbst Zeit investiert.
Vialli hat geschrieben:...basiert SyncToy nicht auch auf Robocopy?
SyncToy vertraut auf seine eigenen Datenstrukturen um Änderungen zu erkennen, Robocopy nutzt nur die normale Verzeichnisinformationen. D.h. beim Ermitteln der Deltas verhalten sie sich sehr unterschiedlich. Ich kann nicht ausschließen daß SyncToy beim Kopieren dann Robocopy verwendet, glaube es aber eher nicht.
Zoppo hat geschrieben:Über die Performance im Vergleich zu synctoy kann ich nicht viel sagen. Ich glaube aber nicht, dass robocopy länger braucht - eher im Gegenteil.
zumindest mit lokalen Platten hat sich Robocopy als deutlich schneller beim Ermitteln der Änderungen erwiesen, mindestens Faktor 10. Über eine langsame Netzwerkverbindung kann das natürlich ganz anders aussehen. Beim Kopieren hab ich keinen so deutlichen Effekt beobachtet, aber auch nicht gemessen - die meisten Nächte ändert sich bei mir fast nichts. Nur wenn das Clientbackup reorganisiert wurde, wird es halt in der nächsten Nacht vollständig kopiert, und das dann ggfs. nochmal beim Plattentausch - ich verwende zwei Backupplatten im Wechsel.
Zoppo hat geschrieben:Ich verwende robocopy (allerdings WHS v1), um Daten vom WHS auf einen 2. WHS zu sichern (Shares > 2 GB).
...
Es gibt auch ein Addin für robocopy. Allerdings hat es den kleinen Fahler, dass es ab und zu den Speicherort des Programms "robocopy" vergißt.
den Luxus eines 2. WHS hab ich nicht, und wenn stünde er woanders um diese Idee fortzusetzen - immer noch niemand interessiert? Addin ist nicht so wichtig, Aufgabenplanung reicht - oder das Addin müßte das halt mitadressieren..

Ich hab jetzt das folgende im Einsatz, konstruktive Kritik erwünscht: In der Aufgabenplanung ist eine Aufgabe eingerichtet die Copyall.bat ruft, als Administrator und mit vollen Rechten. Copyall.bat erstellt erstmal auf der Zielplatte eine neue Schattenkopie, dann wird diskshadow gerufen.

Code: Alles auswählen

: http://technet.microsoft.com/en-us/library/cc788055(WS.10).aspx
vssadmin create shadow /for=g: /autoretry=15
: http://technet.microsoft.com/en-us/library/cc772172(WS.10).aspx
diskshadow -s copyshadow.txt >>.\logs\diskshadow-%date%.log
Die Skriptdatei copyshadow.txt erstellt vorübergehend Schattenkopien der Originalplatten und ruft dann copytree.cmd für jedes zu sichernde Share:

Code: Alles auswählen

# http://technet.microsoft.com/en-us/library/cc772172(WS.10).aspx

#DiskShadow script file
set context persistent nowriters
set metadata d:\backuptool\example.cab
set verbose on
begin backup
add volume d: alias vol1
add volume e: alias vol2
create

expose %vol1% p:
expose %vol2% q:

exec  copytree.cmd p:\serverfolders\Benutzer g:\serverfoldersbackup\Benutzer
exec  copytree.cmd p:\serverfolders\Clientcomputersicherungen g:\serverfoldersbackup\Clientcomputersicherungen
exec  copytree.cmd p:\serverfolders\Dokumente g:\serverfoldersbackup\Dokumente
exec  copytree.cmd p:\serverfolders\Software g:\serverfoldersbackup\Software

exec  copytree.cmd q:\serverfolders\Bilder  g:\serverfoldersbackup\Bilder
exec  copytree.cmd q:\serverfolders\Musik g:\serverfoldersbackup\Musik
exec  copytree.cmd q:\serverfolders\Projekte  g:\serverfoldersbackup\Projekte
exec  copytree.cmd q:\serverfolders\Videos  g:\serverfoldersbackup\Videos

unexpose p:
unexpose q:

end backup
#End of script
Copytree.cmd ruft dann endlich robocopy mit geeigneten Argumenten:

Code: Alles auswählen

robocopy %1 %2 /e /mt:4 /mir /log+:.\logs\robocopy-%date%.log /ndl 
exit 0
: http://ss64.com/nt/robocopy-exit.html
: http://technet.microsoft.com/en-us/library/cc733145(WS.10).aspx
Über eine bessere Fehlerbearbeitung muß ich mir noch Gedanken machen, im Moment reicht es mir aber das Protokoll zu kontrollieren.
In Lightsout sind diskshadow und Robocopy als zu überwachende Prozesse eingetragen, damit der WHS nicht während des Backups schlafen geht.

Mein Originalziel von der instabilen Plattenerkennung von SyncToy loszukommen und einen konsistenten Zustand zuverlässig zu kopieren hab ich jedenfalls erreicht - glaube ich jedenfalls. Was meint Ihr dazu?

Gruß Joachim