Question: Checksum error on backup drive, single file corrupted, good file still exists on primary drive
- Dominant language
- Perl
- Stars
- 2.1k
- Forks
- 139
- PR merge metrics
- No merged PRs in 30d
Description
Hello! Thank you for your work in creating btrbk. It has been instrumental for my team!
I have a question about a scenario I recently ran into:
A routine `btrfs scrub` revealed a singe uncorrectable checksum error on my send-receive target drive. Investigating further, I found the affected file and verified that it is indeed corrupt by attempting to `cat $file > /dev/null`, which fails with "Input/output error".
The original version of the file still exists, intact and unmodified, on my primary filesystem. The snapshots on my primary filesystem which contain the file are also unaffected. Presumably due to incremental backups, the file remains corrupt even in the latest backups that contain it on the send-receive target.
Would it be possible for btrbk to recognize this scenario and use the good copy to repair/replace the corrupted one automatically? From my understanding, this is what `btrfs scrub` would do to repair the file if it knew there was a good copy available.
If I run a single non-incremental backup, that should force the good copy to be transferred to the target, correct? I assume that would fix the file going forward, but the older backups would still contain the corrupt copy of the file.
I finally want to say that the file in question is not vital to me in any way, but I would like to figure this out in case it happens to an important file in the future.
My `btrbk.conf`:
```
snapshot_preserve_min 1d
snapshot_preserve 10d
target_preserve_min latest
target_preserve 24h 30d 10w 1m
timestamp_format long-iso
volume /mnt/btrfs-pool
snapshot_dir @snapshots
target send-receive /mnt/backup-01
subvolume @
snapshot_name @
subvolume @home
snapshot_name @home
# ... more subvolumes
```
Thank you!
Contributor guide
No contributing guide indexed for this repository
Research direction
Review the supplied btrbk.conf and the btrfs scrub and send-receive behavior described in the report. Reproduce the scenario with a corrupt target file and an intact primary copy, then determine whether a non-incremental backup repairs the current target and what, if anything, can repair older backups.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux
- Domain
- devops, operating-systems
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100