Last week I wrote about rsync and how it can be used for a wide variety of tasks. One of the main uses, of course, is for backups -- and not just poor-man's backups. In many cases, using a hard-link rsync backup scheme from one storage array to another can be extremely useful. It can even be better than "standard" backup schemes.
There's a downside to the relative ease of this type of backup, however, and that's data spread. Take, for instance, a situation where you need to move lots of data off one NAS for one reason or another. This might not be a rolling backup, but more of a spot backup because you need to do something relatively worrying on the source NAS, while making sure you can quickly restore the data or run off the target system for a time, in case it goes pear-shaped.
[ Also on InfoWorld: 6 wishes for SysAdmin Appreciation Day | Get expert networking how-to advice from InfoWorld's Networking Deep Dive PDF special report. | For quick, smart takes on the news you'll be talking about, check out InfoWorld TechBrief -- subscribe today. ]
This is a very common situation. A spot backup might even be a requirement when you need to change certain core functions of the source array, such as to enable dedupe on a volume. In that instance, you'll need to move all the data off the volume, wipe it, enable dedupe, then move all the data back in order to take advantage of the deduplication.
You fire up rsync and let it run, confident you have a solid backup of the data. You go through all the steps necessary, and you sync the data back -- done and done. However, you should always treat any significant modification to core services with some skepticism and operate them in a probationary period to make sure no gotchas pop up in the following days or weeks.