I use three USB disks, 1, 1.5 and 2.0 Tb connected to my laptop. They reside in adapter boxes that also can be used for disk duplication (Image attached at the end. Price ~$35). I have backup scripts creating a daily, weekly and monthly backup on them. There are some different approaches to this. My experience has shown, they may lose contact and be remounted as a different device, like "dev/sdc1" may end up being "/dev/sde1" if you're not careful about your handling or if you're unlucky.
The following contains some ideas that may be useful when approaching this scenario.
To counter that problem you may put a file, readable but not writebable (-r--r--r) for ANYBODY, in the disk's root (as high as you can go, still on the same disk). This file is called something meaningful like "label_sdc1" or "label_backupdisk:1". Before copying files to it, your script checks that this file exists.
There is a caveat. Let's say you mount it on /media as "/media/sdc1" or "/media/backupdisk_1". This needs the mountpoints "/media/sdc1" or "/media/backupdisk_1" to be created in the media directory.
One has to be really careful and check that the disk *is* mounted like that before you create the "label-" file. If the disk isn't mounted where you want it, you will write the "label-" file to the directory "/media/sdc1" or "/media/backupdisk_1" in "/media" on your local disk. Your script have no idea that the backup is placed on your local system disk, it will look the same. Then your backup will be written on the same disk you're trying to back up if the real target disk is off line. Eventually your disk space may run out and you'll get a write error, "No space on device".
So, with the labeled disk powered off, check that you *can't* find the "label_" file and that you *can* find it when it's powered on.
OK, how will I check that the disk I want to write on is really "/dev/sdc1" or whatever your preferred name would be?.
To find out the UUID:s of your disks, for each disk, power on *only* the disk you're interested and then run this (/dev/sda1 is normally your boot drive, I want to check /dev/sdb1 here.):
bash: /home/: blkid <ENTER>
the result will be like:
/dev/sda1: UUID="10b71446-98d2-4234-a177-4c287eae8c4a" TYPE="ext4" PARTUUID="731cd93f-01"
/dev/sdb1: UUID="28beab03-866c-4dbb-bc36-d6ff7ba51ed4" TYPE="ext3"
/dev/sdc1: UUID="f3be9443-74a9-43ee-8ba5-06bac24164f2" TYPE="ext3"
/dev/sdd1: UUID="2b181ab7-630d-4790-a0d8-774f96922b9b" TYPE="ext3" PARTUUID="9361c7bd-01"
Enter the following in /etc/fstab (if you have *my* three disks on *your* system :):
UUID=28beab03-866c-4dbb-bc36-d6ff7ba51ed4 /media/backup/ ext3 defaults 0 0
UUID=f3be9443-74a9-43ee-8ba5-06bac24164f2 /media/bu_weekly/ ext3 defaults 0 0
UUID=2b181ab7-630d-4790-a0d8-774f96922b9b /media/work/ ext3 defaults 0 0
Reboot with all USB disks powered off. The start will seem to hang in the middle, just standing there stupidly. Then, power on the first disk and wait until you see the light on the adapter box flicker, indicating *a data transfer*.
Then do the same with each of the other disks, waiting for the data transfer on each. Voilá, they are now mounted correctly. *Your* very long UUID-number and mount points will not be like the example above, they will reflect *your* hard disks and *your* mount points. I left them looking like this to illustrate, only.
My backup scripts are run by /etc/crontab.
If I do :
bash: # cat /etc/crontab <ENTER>
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# Run at system start!
@reboot root /home/xhosa/tools/scripts/myfw
# m h dom mon dow user command <= This line is useful to have if you forget the meaning of all the stars! You'll have to enter it yourself.
# and here are my backups running and logging into different logfiles (monthly is disabled temporarily):
26 1 * * * root /usr/bin/php /home/xhosa/tools/scripts/incrbu_ctrl.php >> /var/log/incrbu/incrbu.log 2>&1
26 23 * * * root /usr/bin/php /home/xhosa/tools/scripts/bu_ctrl_weekly2.php >> /var/log/incrbu/bu_weekly.log 2>&1
##26 6 * * * root /usr/bin/php /home/xhosa/tools/scripts/bu_ctrl_monthly.php >> /var/log/incrbu/bu_monthly.log 2>&1
Each backup script uses phpmailer.php to send reports to my mail. Getting these reports to say something short and meaningful is a process, in my experience. Good luck with that. If you're not proficient in using bash, use your preferred scripting language and call the bash commands when needed.
In phpmailer I use these settings (since I use Gmail):
//Set the hostname of the mail server
$mail->Host = 'smtp.gmail.com';
//Set the SMTP port number - 587 for authenticated TLS, a.k.a. RFC4409 SMTP submission
$mail->Port = 587;
//Set the encryption system to use - ssl (deprecated) or tls
$mail->SMTPSecure = 'tls';
I use a separate account in Gmail for reports from my backups.
NOTE: In my backup scripts I check if its time to run (weekly and monthly) by checking the latest log file in each case. I write a a "0" in a file (like: missed_weekly.log) before each backup. If the back up succeeds, I write a "1" in the file. Since all scripts are started each night, if it finds a "0" in this file the script will try to run again the next night. If you encounter a problem and perhaps take a day or two to fix it, you know for sure that the missed backup will be run the following night.
I also delete log files older than some date.
My diskstation, one of three:
To be continued...
