I’m setting up a file server that will be booted only intermittently: it will be in a powered-on state only at junctures when I want to back up to it some file or directory from another computer on my network. So it will be powered off probably more than 90% of the time. I hope to implement wake-on-lan on this machine so that I can power it on remotely–but that’s an issue for another day. What I’d like to ask about in this thread is my plan to do automated back-ups of certain folders on this machine each time it will be powered off.
First, an explanation of drives/folders on the machine. The file server contains 3 independent hard drives and one RAID array. One hard drive runs the OS (Void)–I don’t care about backing up any files/folders involved with the OS running on that drive. The RAID array contains one of the back-up folders, while a larger SATA drive houses another such folder. Both the RAID and the SATA get mounted whenever the server is powered on, say, under /mnt/folder1 and /mnt/folder2. The remaining, even larger SATA drive, is to remain unmounted except when the process of shuting down the server is initiated. At shutdown, I want the system to mount that remaining drive and to back up to it the contents of /mnt/folder1 and /mnt/folder2–rsync is likley to be used for that task, since I aim to use something that will back up only changes made within /mnt/folder1 and /mnt/folder2.
Some reading of various documents and internet forums leads me to believe that, on Void, the way to trigger the mounting and rsync’ing as part of the power-down procedure is likely to be by editing the file /etc/rc.shutdown: is that correct? So, I would cobble together a simple bash script (not that my bash abilities allow me to do anything more advanced) that would do those things, then put the path to the script in the file /etc/rc.shutdown? Some experiments I’ve done do indicate to me that this should work.
In its simplest form I suppose the script could look something like the following:
mount /dev/sdX# /mnt/back-up
rsync -a --delete /mnt/folder1 /mnt/back-up &&
rsync -a --delete /mnt/folder2 /mnt/back-up
A couple of considerations I have are as follows. First, the rsync commands could, especially on a first run, take a really long time; there are currently tens of gigabytes of data on each of the two drives under discussion. So, can I trust that the system will not power off before those rsync commands complete? I’m just not sure how rc.shutdown works and fits into the shutdown scheme. Can anyone offer clarification on that?
As far as the script itself goes, would it be of any benefit to make a “for” loop out of the rsync commands? And maybe add some explicit exit sequence? Perhaps some feedback sent to a terminal as to the script’s success/failure?
And for extra points, someone has recommended to me doing something like hashing the source and destination directories to confirm that they are, indeed, exact copies of one another. I do see some sense in that plan. But the bit of research I’ve done indicates that hashing directories with sub-directories is not a simple affair. For example, I do not want much in the way of meta-data checking in such a routine, since checking of access times or file ownership is not really important to verifying file integrity in this case. Some sources, on the other hand, seem to indicate that getting a diff of the two could serve better. Does anyone have any input on such a possible data-integrity enhancement to my back-up plan?
And just as importantly, what, exactly, would a hash do? Ok, it could tell me whether the source and destination are accurate copies of one another. But let’s say it does happen that the hashes turn out to be different: what can be done then? The two folders under discussion contain somewhere between 80GB and 200GB of data. Certainly the mismatching hashes cannot tell me anything about where the mismatch–the error–between the two directories is, can it? If not, then what good would the hashing do? A diff, on the other hand, seems like it could be more informative as to the location where a problem might lie, wouldn’t it?