Cautionary backup story

[Gaer Boy]

Having made multiple changes to my disk configurations, I needed to rewrite all my LuckyBackup tasks. Basically, my external backup disk /sdc has 3 partitions - General, Pictures and WinFiles (ntfs). I backup all the folders in my /home partition to one or other of these.

So I set up 'Copy the source directory' for /home/phil/Pictures to /mnt/sdc/ and ran the backup. Checked the backup drive and all seemed OK - I could view all the files.

Then it struck me that the process had completed rather quickly, so I looked at the log which said that only 9 files had been copied of about 9000 files I could see there.

You're probably ahead of me, but I'm a 'one step at a time' operator, so I deleted from the source one file that I didn't need. Sure enough, it was deleted from the backup.

Memo to self (which may help others): If you symlink your data to /home, don't use /home/phil/Pictures as the source, use /mnt/sda7. Lucky Backup will then copy the files, and not just the symlinks!

Phil

[Jerry3904]

Yeah, I have screwed up as well when symlinks were involved in backup scenarios. Managed one time to clear my entire Desktop that way, where I kept a lot of temporary but important stuff. Luckily, I also use Amazon S3 for a daily backup, so could recover.

[Distro-Don]

I use LuckyBackup to backup /home/don to /archives/Backup and also to /media/disk. /archives/Backup/don goes well. /media/disk/don has about 330 errors. /archives/Backup/don is owned by don:users and /media/disk/don is owned by don:root. I don't know if that is the problem or not. I tried changing the owner but it was'nt allowed.

[GoManutd]

symlinks are a great asset and can solve a lot of problems, but it's often better to find out why something isn't working and fix it, then use symlinks to solve the problem because the unseen consequences, like this, can bite you when you least expect it.

[richb]

I have been using Wuala for online backup. Automatically syncs folders you choose. As far as security:

All files are directly encrypted on your desktop. Your password never leaves your computer. Not even we as the provider can access your files or your password.

Also available for Android and iPhone, so I have access to my desktop files from my phone via wifi or cell.

http://www.wuala.com/

[Gaer Boy]

I have been using Wuala for online backup. Automatically syncs folders you choose. As far as security:

All files are directly encrypted on your desktop. Your password never leaves your computer. Not even we as the provider can access your files or your password.

I also use Wuala, but the free storage is only enough for key files. The other 95GB has to be local backup.

Phil

[joany]

symlinks are a great asset and can solve a lot of problems, but it's often better to find out why something isn't working and fix it, then use symlinks to solve the problem because the unseen consequences, like this, can bite you when you least expect it.

I don't think the lesson from this cautionary tale is to avoid using symlinks. The lesson here is to make sure you know what you're backing up (and what you aren't). Obviously, backing up a symlink won't back up the data it points to.

I'm a huge fan of symlinks, but I don't use them "to fix things that aren't working." In fact, I doubt you could use symlinks to fix anything that isn't working. Their main purpose is to avoid having to maintain multiple copies of the same data when different applications need to utilize the same files, such as library files. Symlinks can also free up space in /home. For example, instead of keeping 15GB virtual machine files in my /home partition, I keep those files in a separate partition and create symbolic links in /home instead.

[Gaer Boy]

I don't think the lesson from this cautionary tale is to avoid using symlinks. The lesson here is to make sure you know what you're backing up (and what you aren't). Obviously, backing up a symlink won't back up the data it points to.

Definitely, joany. The problem was not with my use of symlinks, but with the use of my ageing brain!

Phil

[GoManutd]

not saying don't use them, the lesson about symlinks is to understand that there may be unforeseen issues. too often people use them because it provides a quick fix for certain types of problems, e.g. software that was packaged for a different platform, placing data in a different location, etc.

i used symlinks in prior versions of myth because it was far easier that trying to get myth configured to put data where i wanted it (this issue is not an issue in current versions).

symlinks are cool, useful, but the average linux user isn't likely to under that there are potential issues to using them.

[JimC]

I use Lucky Backup for some things. For example, when I upgraded my wife's laptop from Mepis 8.5 to Mepis 11, I used it to make copies of her home directory, then restored what she needed after performing a clean install (folders and docs, hidden .mozilla folder so that she'd have all of her firefox related stuff).

But, I also make backups of her entire home partition from time to time.

The most reliable way I've found to do that is using ddrescue after booting into a Mepis Live CD, since it performs a sector by sector copy of either individual partitions or entire disks, and since it's a sector by sector copy (ignoring the file system entirely), you get an exact replica of the original drive or partition.

For example, this command would copy /dev/sda1, and write it to an image file named 20120724_sda1.img, located on /mnt/sdb1 (a mounted partition on an external drive). Note that the third parameter (log file named /mnt/sdb1/20120724.log in the below example) is optional:

su
ddrescue /dev/sda1 /mnt/sdb1/20120724_sda1.img /mnt/sdb1/20120724.log

That way, I have an *exact* sector by sector copy of the partition (/dev/sda1 in that example) that I can restore to another drive, simply by reversing the process like this:

su
ddrescue /mnt/sdb1/20120724_sda1.img /dev/sda1

When you make an image file of a partition (20120724_sda1.img in that example, since I usually use the backup date as a file name), you can also mount it as a loop device (so that you can read and write to it, just like you can do with a physical drive). That lets you easily copy and paste needed folders and files from it if you don't need to restore an entire partition.

You can do the same thing using dd (only the syntax is different). Since ddrescue is already installed in Mepis, I prefer it since I can boot into a Live CD and run it, and it handles errors better than dd if you have a failing drive you're trying to backup (since it will make multiple passes if needed due to errors by default, only copying what it didn't copy OK with previous passes,which is the purpose of the optional log file (third parameter in the above example).

I also use clonezilla live to do the same type of thing (including making full disk image backups, not just partition backups), and it has some default compression options built in to save disk space. But, like dd, it won't handle hard errors like ddrescue will, and if you want to do things like mount partitions as a loop device, making a full sector by sector copy without using any compression is a better bet. Basically, there are pros and cons to any backup solution (including disk space requirements on the backup device).