I would suggest a look at rdiff-backup (http://rdiff-backup.nongnu.org) for a similar rdiff-like solution but which will also efficiently maintain a number of previous backup snapshots as well. It's easy to script and automate, and has worked well for me for a while. I run it nightly to an internal disk (automated, only mounting that disk when needed so I couldn't accidentally delete the files on it), and weekly to one I take off-site. That way if I make a mistake such as yours I'd have an backup close to hand.
To prevent accidentally backing up without the drive mounted a poor-mans way is to make sure the backup is to a directory under the root of the mount-point (eg /storage/ext/backup), rather than to the mount point root itself (/storage/ext). That way the backup should immediately fail since the target directory isn't there (ie /storage/ext/backup won't exist unless the drive is already mounted). Alternatively, wrap the backup with a short script that checks that directory is there, is present in /proc/mounts, or something similar. The obvious answer to avoiding this kind of error is not to run as root - make your media owned by a group (eg "media") and put yourself in that group. Of course you'll still be able to quickly delete everything available to that group, but the consequences wouldn't be as bad if you accidentally ran it on the root directory, for example. Other alternatives are to make 'rm' prompt for your approval (alias "rm" to "rm -i", which you can add to a login script) - according to the man page it'll then prompt if there are more than three files or a recursive rm is being performed, which would have saved you in this situation if you'd read the prompt. Also, some other shells (eg fish or zsh) can be better at catching classic errors such as this - I can't remember for sure but I recall one or both of these having some special protection. There are as many ways of backing up as there are people who reply to threads such as this, so you'll be unlikely to hear of a 'best' way...! My only other advice is to also encrypt your backups as an external drive is easy to lose or have stolen - Linux makes that easy with dm-crypt/LUKS (and it's easily scriptable). Stuart On 03/08/2009 10:16 AM, socistep wrote: > > Hi All, > > Thought I'd share with the board my big error over the weekend and also > to highlight the importance of backup! > > I recently bought a 1tb external HDD to mirror my /storage folder on my > server (running vortexbox), its got about 450gb worth of music, photos > etc, I set this backup to run using rsync and it ran daily. Over the > weekend I travlled to my to parents house and brought the server with > me, on Sat I couldn't get Squeezecenter to run, I worked out this was a > space issue and from that noticed that the previous nights rsync job had > run without the External HDD plugged in and had filled the 20gb root > partition on the server. > > I navigated to /media/externalHdd to delete the storage folder there > which had incorrectly been created with the backup job, however I made a > fatal mistake and instead of > > rm -rf storage/* > > I did > > rm -rf /storage/* > > This then deleted the entire 450gb worth of music etc. ....it was too > late to change it once I realised. > > Thankfully when I return home on weds my External HD will be there with > the server backed up from thurs (I hope nothing has happened to it!) > however I have been kicking myself ever since for the error ! > > Does anyone with Linux experience know of a smarter way of doing the > backup, I'm presuming something like a shell script which checks for the > external HDD being mounted before running the backup ? > > Secondly is there a way of protecting the /storage part of the server > to stop running commands like the above, I log in as root when ever I'm > doing work on the server > > Thanks > Ian > >
_______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/discuss
