Home / server / Questions / 149209
Accepted
dasko
Asked: 2010-06-09 04:53:09 +0800 CST

is ROBOCOPY a good form of backup as a tool?

  • 772

seeing how it does not do a write verify unless scripted (or is it needed?) is it a decent option to dump a few folders to another server? i am just worried about whether the data, after being copied, might be corrupted but you would not be aware of it being buggy?

i have used it in the past without issue but am seeking feedback in case i missed something obvious.

backup replication robocopy

4 Answers

  1. Best Answer

    Robocopy is an excellent tool to copy the data. You may want to do a diff afterwards, maybe with Beyond Compare.

    Other options to move the data include imaging, Windows Replication, and others. But usually I use robocopy, because it makes a very good log.

    • 3

  2. robocopy is an excellent file-copying tool, but by itself only the most basic of backup tools. The verification you mention is a good example. robocopy has the facilities to be part of a decent backup solution, but you should be prepared to spend some time wiggling out the best parameters, and probably a wrapper script or two.

    I use it a lot - including my ad-hoc backups at home - and love it, but it isn't a "backup" solution. More of a "eehhh, I'd better make a copy of this before I screw it up" solution.

    My .02

    • 0

  3. I'm afraid I have to disagree with the previous answer: robocopy (alone) isn't a good tool to copy data because it doesn't have any mechanism to backup open files safely and therefore it can have unpredictable results.

    I'm not talking theoretically here: last year, a customer of mine had a total data disaster (as in: he had nothing left) because he used robocopy to synchronize his data folder with a remote server daily. Since the files in questions where, for a large part, used by a desktop database program, the file that where copied successfully where random depending on what process had them still locked.

    When an employee deleted all his "live" data (don't ask why), he asked for help restoring the data. We couldn't do anything since the "backup" solution was robocopy.

    Rules of backups:

    1. Always consider WHAT you are backing up.
    2. Always test them when you deploy them.
    3. Test them regularly afterward.
    4. "Testing" means actually restoring data to a different location and checking the data integrity, not verifying that you have the backup file/tape somewhere.
    5. Make sure you have a meaningful log every time you run it and make sure someone checks all these logs.

    Unfortunately, while it's a really great tool, robocopy isn't a program that allows you to do the above properly.

    • 0

  4. Depends entirely on what the content is that you're backing up and whether RoboCopy is likely to be blocked from accessing open files etc.

    Any backup strategy is only as good as the test restore process you put in place to verify that your backups are working, complete & can be restored from to the extend that you were anticipating.

    I've worked in plenty of places that have been running backup jobs reporting success & verify every day for ages only to find when they needed to do a restore that whilst the job had worked it didn't actually pick up all the data needed to recover the failed system.

    • 0