D&C GLug - Home Page

[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]

Re: [LUG] Backup in Linux

 
On Sun, 27 Apr 2014, Julian Hall wrote:


Hi All,
I've been trying different GUI based programs for backup and had most luck with 'luckyBackup', however it's not /that/ lucky because no matter what Exclusions I give it, it keeps trying to add the content of drives that are currently mounted when I've told it to exclude them. I had a go with dd tonight but got this error after a few minutes: 

sudo dd if=/dev/sda8 of=/media/julian/ARTEMIS/systembackup.img
dd: reading ‘/dev/sda8’: Input/output error
17130448+0 records in
17130448+0 records out
8770789376 bytes (8.8 GB) copied, 257.292 s, 34.1 MB/s

/dev/sda8 is the root of my Mint installation, ARTEMIS is a USB external HD.

Should I try 'luckyBackup' again but with other drives unmounted?


IMO, You should try some good old-fashioned command-line stuff.
But firstly - dd - it's trying to do a block copy of every single block on the /dev/sda8 partition - whether they're part of a file or not - not always the best way to 'backup' something - and in this case it's reporting an error - that means you have a bad block on your disk. The trouble is, right now you don't know if that block is inside a file, or unallocated... 

So you really do need to make a backup. Now.

What I would suggest is learning about rsync.

So for now, what you can do:

Assuming /media/julian/ARTEMIS/ is formatted, then try this:

  cd /
  sudo rsync -ax . /media/julian/ARTEMIS/backup.root/
That should create the directory: /media/julian/ARTEMIS/backup.root and store a copy of all the files under root into it. The -x flag tells rsync to not traverse mount points. (and -a is archive mode)
If rsync fails with an IO error, then you've lost a file, but if it works OK, what to do next depends on how much you value the disk and data, but a *temporary* solution might be something like: 

  cd /
  sudo dd if=/dev/zero of=fillfile

then when the disk is full,

  sudo rm fillfile

then:

  badblocks -sc 256 /dev/sda8
What the above few commands are doing is to fill (most of) the unused parts of the disk with zeros, then run the badblocks command to check the whole disk. If it passes OK, then the disk is fine - today. Tomorrow you need to replace it as it has bad sectors and it will only get worse.
Often writing a block will clear any error that block might have when reading it. However it may do this by reallocating sectors, who knows. 

Use the smart tools if you can to check it - e.g.

  sudo smartctl -a /dev/sda
Look for something that looks like: Reallocated_Sector_Ct and hopefully it will be zero. 

Good luck...

Gordon
-- 
The Mailing List for the Devon & Cornwall LUG
http://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/listfaq