bup-damage(1)

💥 bup-damage — bestie's guide to breaking things on purpose 💥

okay so this is bup-damage(1), from the General Commands Manual, and babes... it does exactly what it says on the tin. it damages stuff. on purpose. for science. 🧪✨

---

✨ NAME ✨

bup-damage — randomly destroy blocks of a file 🫶

like. literally that. it's giving chaos gremlin with a mission.

---

🌸 SYNOPSIS 🌸

bup damage [-n count] [-s maxsize] [--percent pct] [-S seed] [--equal]
<filenames...>

---

💅 DESCRIPTION 💅

so here's the tea ☕ — you use bup damage to deliberately destroy blocks inside a .pack or .idx file (the ones living in .bup/objects/pack), and the whole point is to test the recovery features of bup-fsck(1) or whatever other program you're putting on trial.

⚠️ THIS PROGRAM IS EXTREMELY DANGEROUS AND WILL DESTROY YOUR DATA ⚠️

not even being dramatic. that's the manual's own words, and I am respecting them. 💀

bup damage is mostly useful for automated or manual tests of data recovery tools — the vibe is basically "let me ruin this on purpose so I can prove to myself that the fixer actually fixes it." that's the reassurance arc, bestie. 🌈

also important, heads up: the details of the current behavior may change (especially the details that aren't documented here). for example, right now the damage is strictly probabilistic, so it may or may not actually alter any given block. with a block size of 1, there should be a 1/256 chance that the block won't actually change. this behavior may change. so don't get attached. 🙈

---

🎀 OPTIONS 🎀

• -n, --num=numblocks — how many separate blocks to damage in each file (default 10). lowkey watch out though: it's possible for more than one damaged segment to fall in the same bup-fsck(1) recovery block, so you might not damage as many recovery blocks as you expect 😭. if that's a problem, use --equal.
• -s, --size=maxblocksize — the maximum size, in bytes, of each damaged block (default 1, unless --percent is specified). okay so here's the catch, because of the way bup-fsck(1) works, a multi-byte block could fall on the boundary between two recovery blocks, and thus damage two separate recovery blocks. and in small files, it's also possible for a damaged block to be larger than a recovery block 👀. if these issues might be a problem, you should use the default damage size of one byte. periodt.
• --percent=maxblockpercent — the maximum size, in percent of the original file, of each damaged block. if both --size and --percent are given, the maximum block size is the minimum of the two restrictions. you can use this to ensure that a given block will never damage more than one or two git-fsck(1) recovery blocks. protective queen behavior honestly 👑
• -S, --seed=randomseed — seed the random number generator with the given value. if you use this option, your tests will be repeatable, since the damaged block offsets, sizes, and contents will be the same every time 🔁. by default, the random numbers are different every time (so you can run tests in a loop and repeatedly test with different damage each time). chaos by default, reproducibility on demand. iconic.
• --equal — instead of choosing random offsets for each damaged block, space the blocks equally throughout the file, starting at offset 0 📏. if you also choose a correct maximum block size, this can guarantee that any given damage block never damages more than one git-fsck(1) recovery block. (this is also guaranteed if you use -s 1.)

---

🔥 EXAMPLES 🔥

# make a backup in case things go horribly wrong
cp -pPR ~/.bup/objects/pack ~/bup-packs.bak

# generate recovery blocks for all packs
bup fsck -g

# deliberately damage the packs
bup damage -n 10 -s 1 -S 0 ~/.bup/objects/pack/*.{pack,idx}

# recover from the damage
bup fsck -r

see how step one is the backup?? that's not a suggestion bestie, that's survival instinct. back it up BEFORE you break it. 🫶

---

👀 SEE ALSO 👀

bup-fsck(1), par2(1)

---

💜 BUP 💜

part of the bup(1) suite.

---

🌟 AUTHORS 🌟

Avery Pennarun apenwarr@gmail.com

---

that's the whole page, babe — go forth and destroy responsibly. and remember: you're running Bup 0.34 from 2026-09-01, so if anything breaks in a way you didn't plan, that's on you, not on me. mwah 💋✨