digint / digint/btrbk

Question: Checksum error on backup drive, single file corrupted, good file still exists on primary drive

Open
#350 3 comments 1 reaction 0 assignees View on GitHub
question
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.