Synctoy voor het copieren van backup data naar externe disk

[ReTechNL]

Beste,

Ik heb nu al 2 weken een synctoy job draaien welke backups van Disk D naar een externe disk echo't. dit werkt perfect alleen nu heb ik de disk gewisseld en nu klopt de echo niet meer. hij doet alleen de wijzigingen welke nog niet op die oude disk zijn aangemaakt door voeren naar de nieuwe disk. hij kijkt dus niet naar de rechter locatie alleen houd hij zelf een db bij met wat al gedaan is en daar kijkt hij gewoon niet meer naar ook al hang je er een nieuwe disk aan.

Is hier een oplossing voor dat als je de echo functie gebruikt dat je gewoon de disk kan wisselen en deze dan ook juist gesyngroniseerd wordt? zonder dat je eerst de job moet weg gooien en opnieuw moet aanmaken? want dat is wat er geadviseerd wordt op internet alleen gaat de disk weekelijks gewisseld worden en ik ga niet weekelijks een nieuwe job aanmaken. Is dit te realiseren met Synctoy of moet hier een ander programma voor gebruikt worden?

~ReTechNL

[F_J_K]

Er zijn ook wel alternatieve sync tools (robocopy? Of zie Wikipedia: Comparison of file synchronization software en oudere topics op GoT) maar dit kan prima met Synctoy.

Je wilt alleen niet steeds een nieuwe job maken, je wilt twee jobs hebben die om de week wel/niet draaien.

[DukeBox]

^ Kijk dan meteen naar OS onafhankelijke tools zoals rsync (deltacopy voor windows).

[SmiGueL]

Ik heb zelf jaren Synctoy x64 gebruikt i.v.m. de simpele interface, maar liep ook tegen bovenstaand probleem aan. Elke keer kon ik weer 100+ GB opnieuw syncen en daar werd ik een beetje flauw van.

Momenteel gebruik ik gewoon de standaard in Windows zittende robocopy met een script die simpelweg enkele mappen zoals D:/MijnDocumenten naar W: kopieert. Zet er het /PURGE commando achter en ongeacht wat er op W: staat, na een sync. is alles 1:1 gelijk aan de bron. Ideaal.

Sowieso zou ik aanraden om, indien je meerdere externe schijven gebruikt, deze te koppelen aan driveletters.
De Western Digital noem ik dus W voor het gemak.

Als je Synctoy echt wilt behouden, en 2 schijven hebt dan zou je toch gewoon 1 schijf de letter W geven, en de andere de letter X. Vervolgens maak je eenmalig 2 Synctoy jobs.
Als schijf W er aan hangt dan voer je BackupW uit, en als je schijf X er aan hangt start je BackupX.

Uit praktisch oogpunt zou ik alsnog voor een robocopy script gaan omdat deze zonder installatie van software (en in dit geval missende database) zo verder kan draaien op een nieuw systeem.

[DukeBox]

Ik zou juist NOOIT met drive letters werken (zeker i.c.m. /purge) voor externe locaties altijd UNC en lokaal altijd volumeID (zoals \\?\Volume{e3c9f31f-44e7-12e0-28f2-806e6f6e6963}\ )
Even een check of de locatie beschikbaar is in je script en de kans dat je iets verkloot kan bijna niet meer.

synctoy en robocopy (of xcopy) zijn leuke tools maar ik zou echt aanraden naar rsync te kijken. Hiermee hoef je nooit iets opnieuw te doen en bij een block copy stuur je alleen maar de wijzigingen in een file over i.p.v. de hele file.

[SmiGueL]

DukeBox schreef op donderdag 05 september 2013 @ 13:14:
Ik zou juist NOOIT met drive letters werken (zeker i.c.m. /purge)

Ik geef je groot gelijk indien je geen driveletters toekent. Maar het is bij mij nog NOOIT fout gegaan, gezien ik alleen de toegekende schijfletters (redelijk aan het eind van het alfabet) gebruik.
Hierdoor kan het in theorie nooit fout gaan TENZIJ je gelijktijdig 20 USB stick aansluit oid.... geloof mij, not gonna happen.

Een check of de locatie beschikbaar is doet ie zelf natuurlijk al.. als dit niet het geval is valt er weinig te verkloten.

[ Voor 12% gewijzigd door SmiGueL op 05-09-2013 13:37 ]

[ReTechNL]

DukeBox schreef op donderdag 05 september 2013 @ 13:14:
Ik zou juist NOOIT met drive letters werken (zeker i.c.m. /purge) voor externe locaties altijd UNC en lokaal altijd volumeID (zoals \\?\Volume{e3c9f31f-44e7-12e0-28f2-806e6f6e6963}\ )
Even een check of de locatie beschikbaar is in je script en de kans dat je iets verkloot kan bijna niet meer.

synctoy en robocopy (of xcopy) zijn leuke tools maar ik zou echt aanraden naar rsync te kijken. Hiermee hoef je nooit iets opnieuw te doen en bij een block copy stuur je alleen maar de wijzigingen in een file over i.p.v. de hele file.

Maar wat als er links wat verwijderd wordt? wordt dit dan rechts ook verwijderd?
Edit: robocopy /mir of /e /purge heb het al
Ik ga eens kijken of ik met robocopy kan doen wat ik wil en of dit allemaal werkt.

[ Voor 8% gewijzigd door ReTechNL op 05-09-2013 14:20 ]

[Jester-NL]

RichCopy... gratis GUI rond RoboCopy, die je alles laat instellen wat je maar wilt. Filesize compare, datumcheck... the works

[DukeBox]

ReTechNL schreef op donderdag 05 september 2013 @ 13:39:
Maar wat als er links wat verwijderd wordt? wordt dit dan rechts ook verwijderd?

Dat is juist het principe van een sync app. Het mooie van rsync is dat je ook kan aangeven dat de file niet direct verwijderd wordt, maar bijv. pas na x aantal uren/dagen/maanden enz..
Je kan ook meerdere versies bijhouden als je middels source & destination werkt.

SmiGueL schreef op donderdag 05 september 2013 @ 13:34:
Een check of de locatie beschikbaar is doet ie zelf natuurlijk al.. als dit niet het geval is valt er weinig te verkloten.

Ja, maar zoals je zelf ook al aangeeft is een driveletter niet uniek. Zie voorbeeld:
PC1 naar PC2 met E: gemount naar \\PCB\F$\backup
script is robocopy D:\data X:\data /mir staat op E:\script.bat

Stel je zit nu achter PC2, deze heeft ook een E:\data en je start per ongeluk het script op die pc (F:\script.bat) is in een klap je E:\data leeg.

Gebuik je UNC (evt. lokaal) en/of volume uid's dan kan dat nooit gebeuren en bij UNC werkt het op dezelfde manier maar vanaf een andere locatie.

[ Voor 17% gewijzigd door DukeBox op 05-09-2013 15:03 ]

[SmiGueL]

ReTechNL schreef op donderdag 05 september 2013 @ 13:39:
[...]

Maar wat als er links wat verwijderd wordt? wordt dit dan rechts ook verwijderd?
Edit: robocopy /mir of /e /purge heb het al
Ik ga eens kijken of ik met robocopy kan doen wat ik wil en of dit allemaal werkt.

Indien /PURGE aan staat wel, dan krijg je een 1:1 kopie. (Alleen de veranderingen gewijzigde files worden uiteraard overgezet, waardoor het in mijn geval minutenwerk is i.p.v. uren voor de hele backup)
Indien je dit er niet achter zet worden ook alleen de nieuwe en gewijzigde bestanden over gekopieerd, maar er wordt niets verwijderd.

Voor de veiligheid maak ik dus met robocopy 2 backups.
een in /backup/1on1 en een in /backup/nopurge

Beetje zinloos misschien, helemaal omdat het meer dan 2x zoveel ruimte inneemt. Maar ik heb toch TB's zat over dus dat boeit me vrij weinig.

[DukeBox]

SmiGueL schreef op donderdag 05 september 2013 @ 15:31:
(Alleen de veranderingen worden uiteraard overgezet, waardoor het in mijn geval minutenwerk is i.p.v. uren voor de hele backup)

Zover ik weet kan robocopy dat niet, als er ook maar 1 bit wijzigt aan een file, dan wordt de gehele file gekopiërd.

[SmiGueL]

DukeBox schreef op donderdag 05 september 2013 @ 15:38:
[...]

Zover ik weet kan robocopy dat niet, als er ook maar 1 bit wijzigt aan een file, dan wordt de gehele file gekopiërd.

Aangepast , Met 'veranderingen' bedoelde ik uiteraard dat als er aangepaste bestanden zijn, worden alleen deze gekopieerd, en niet de ongewijzigde bestanden.

[ Voor 3% gewijzigd door SmiGueL op 05-09-2013 16:26 ]

[ReTechNL]

Zit nu met het volgende probleem en dat is dat server 2012 robocopy niet herkent als uitvoerbaar commando vanuit een .bat script
Maar als ik hem uitvoer onder windows 7 wordt hij wel herkent en als ik hem handmatig uitvoer in cmd in server 2012 dan werkt hij ook gewoon.
Maar bij het uitvoeren via .bat niet.

Mijn commando:

robocopy "D:\Veeam\Backups_VMs" "G:\Backups_VMs" "*.*" /np /fp /e /purge /tee /log:"D:\BEHEER\BackupScript\RoboCopy\mail\logfile.log"

En vervolgens wordt de logfile met blat geemaild naar de [e-mail]

[ Voor 29% gewijzigd door ReTechNL op 05-09-2013 17:06 ]

[DukeBox]

Moet robocopy wel via je path te vinden zijn. Ander moet je deze in de 'run in' plaatsen of het volledige path voor de executable plaatsen.

[SmiGueL]

Idd of gewoon robocopy.exe in hetzelfde mapje plaatsen als de .bat files.

Tegenwoordig werkt het multithread commando ook, bijvoorbeeld --> MT:8 of MT:16
Maar dit werkt niet altijd sneller.
Het backuppen zelf gaat in mijn geval misschien 2x sneller, maar voordat hij hieraan begint is hij eerst een minuut of wat aan het indexeren.. Schiet er niets mee op eigenlijk.

[ Voor 68% gewijzigd door SmiGueL op 05-09-2013 21:39 ]

[ReTechNL]

DukeBox schreef op donderdag 05 september 2013 @ 17:15:
Moet robocopy wel via je path te vinden zijn. Ander moet je deze in de 'run in' plaatsen of het volledige path voor de executable plaatsen.

Thanks, het volledige pad van robocopy.exe ervoor dat heeft het probleem verholpen.
C:\Windows\System32\Robocopy.exe