Hi, John Pettitt wrote on 04.05.2007 at 20:23:49 [Re: [BackupPC-users] hard drive replacement]: > David Relson wrote: > > The drive with my BackupPC files on it is generating "I/O error" > > messages and reiserfsck's recommendation is, once a drive is reporting > > errors, it's nearing the end of its life and ought to be replaced. > > > > As I'd like to preserve my old backups, I'm looking for the best way > > to copy files from an old drive to a new one. > > [...] > > If you can do it using DD to copy the raw partition (and growing the fs > as appropriate afterwards) will be way quicker.
most definitely. Resizing the file system is no problem with reiserfs. Just make sure your destination drive/partition is at least as big as the source (preferably bigger). As your source drive is already producing I/O errors, you want to have a look at dd_rescue (in Debian the package is named "ddrescue"). dd won't copy past a read error. Also, if your source is on an LVM LV, you might try to pvmove it onto the new disk. I'm not sure how smart LVM is about handling I/O errors though. In any case, the contents of sectors that cannot be correctly read from the source disk are obviously lost or at least in some way damaged. If you're lucky, that concerns unused space on the file system (not likely if you had I/O errors, I guess). Next preference would be file contents, because then probably only few files would be damaged. If file system meta data is lost, that may concern many more files. A while back, I started writing a Perl script that can traverse the pool and check if every file computes to the hash it should compute to. For compressed files, an on-disk error will most probably trigger a decompression error, which would also be noticed. I had intended to add checking of rsync checksums for files containing cached checksums but have not gotten around to doing it. It is slightly (but not extensively) tested and should do nothing destructive in any case :). If you're interested, you're most welcome to test it. It should be noted though, that there is really no way of discovering *every damaged pool file*. While it is possible to spot obviously damaged files, that does *not* mean that all other files are necessarily ok. Again, I believe it to be likely that at least a damaged *compressed* file will be spotted by not decompressing correctly, or if, at least not to the correct length (which influences the hash). Files under 256 KB (uncompressed size) are completely covered by the hash, so it would be extremely unlikely for corruption to remain undetected for those. Checking the whole pool will need all of the pool files to be completely read, decompressed and hashed, which will take *long*. There is support for partial checks (subset of the pool, as defined by BackupPC_nightly). > If you can do that I strongly recommend s-tar as it seems to cope with > millions of hard links without barfing or using all of your memory. That is strange, because it is not really implementation deficiencies of tar/cp/rsync which cause these problems, but rather the nature of the task at hand. While a specialized tool for copying BackupPC pool type file trees might be able to do some magic using temporary files, I doubt general purpose tools will be optimized to deal efficiently with large numbers of hard links, because that's not the common case they are designed for. Regards, Holger ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ BackupPC-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
