On 09/08/14 11:35 AM, David Christensen wrote:
On 08/09/2014 08:11 AM, Gary Dale wrote:
To preserve your archive, I'd advise PAR2 redundancy files to fix any
problems that may crop up. So long as your HD copies are good, you don't
need to go to the PAR2 files, but should one develop a problem, you can
fix it with the PAR2 files. Having 5% to 10% redundancy is a lot cheaper
than RAID1.
You can automate the PAR2 creation by checking for new files and
creating PAR2s for them.
RTFM, it looks like par2 places the parity files in the same directory
as the source files. I'd prefer to have them in a parallel tree. For
example, if my source files are in /mnt/datadrive/stuff, I'd like the
par2 files to be in /mnt/datadrive/.par2/stuff. Is this possible?
David
Since your main objective is simply to repair bit-rot, it probably
doesn't matter where they go. However I can see you wanting them to be
out of the way. par2 actually puts them in the current directory unless
you tell it differently so you could for example do:
cd /mnt/datadrive/.par2/stuff
par2 c files.par2 ../../stuff/*
or just:
par2 c /mnt/datadrive/.par2/stuff/files.par2 /mnt/datadrive/stuff/*
or even:
cd /mnt/datadrive/stuff
par2 c ../.par2/stuff/files.par2 *
The other consideration is the level of bit rot you want to be able to
repair. While SMART monitoring will usually save you from catastrophic
disk failure, it can't guaranty it won't happen. Good backups and/or
RAID are needed for that. Btrfs is a good replacement for single-disk
RAID but two-disk RAID1 or three-disk RAID5 is still safer.
However using an external drive for daily backups along with par2 files
should get you the ability to fully recover from a catastrophic HD
failure and bit rot. The nice thing about par2 files is they can recover
the entire file so long as the corruption is less than the amount of
redundancy you have in the par2's.
Assuming you have both a backup copy and a live copy plus some par2
files, you should be safe with the 5% to 10% I suggested.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53e67581.5070...@torfree.net
