Borax Man <boraxman@geidiprime.invalid> wrote:
On 2026-05-08, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
On Fri, 8 May 2026 12:38:44 -0000 (UTC), Borax Man wrote:
If you want a robust system which can repair without a backup, you
can always use parchive, which can store parity data allowing you to
check AND repair up to a certain amount of damage.
parchive is the sort of thing IrCOm thinking of. Because it doesnrCOt
matter how many redundant copies of a file you have, if an error
happens in the same block on all of them, yourCOre stuffed. Using the
PAR2 format (erasure code) gets around this.
However it doesn't work as well for large directory trees, and if
you do decide to 'parchive' a whole folder, and you need to delete
or update a file, you have to compute it all again.
Surely you donrCOt update your backup snapshots in-place, you create new >>> ones. Once a backup snapshot is made, you shouldnrCOt go around fiddling >>> with it. Either keep it or, if itrCOs been obsoleted by a newer one,
throw it away.
I use DAR for backups, and it has an option to run parchive over the
backup file. Backups are incremental.
I use parchive also for my home photo collection. One I fill a folder,
I run parchive and make it all read-only.
Which works very well for "bit rot" situations (the "silent data
corruption" events).
But does not help at all if the files that have been parchived and the parchives themselves all reside on one disk, and that disk itself fails
to the point it is inaccessible. If you can't read the disk you can't
read the files, even to recover with parchive.
You'll still want actual backups on separate "media" to cover for the
"whole disk failed" case.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 65 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 10:00:09 |
| Calls: | 862 |
| Files: | 1,311 |
| D/L today: |
3 files (7,546K bytes) |
| Messages: | 265,184 |