My dashboard shows low efficiency/deduplication rates, even though I haven’t created many new files. Why is so much storage being used?
A: BmuS uses file-based deduplication (via hardlinks). This means: A file is only linked to save space if it is 100% identical to the version from the previous day. As soon as even a single bit changes, BmuS must copy the entire file again.
Here are the most common reasons for a low rate:
1. Large, Changing Files (VMs & Containers) This is the “arch-enemy” of hardlinks.
- Example: You have a 50 GB Virtual Machine image (or a VeraCrypt container).
- Problem: You start the VM and change only a small text file inside it. To the file system, the “timestamp” and checksum of the massive 50 GB file have changed.
- Result: BmuS must copy the full 50 GB again. No deduplication takes place.
2. Database Dumps (SQL) BmuS automatically creates SQL dumps (.sql).
- Problem: Almost every SQL dump contains the current date and time of creation in the header (e.g., — Dump completed on 2025-11-30 14:00:00).
- Result: Even if not a single record in the database has changed, the text file is technically a “new file” due to the new timestamp in the header. It is saved anew every day.
3. Metadata Changes (Photos & Music) Did you re-tag your MP3 collection or edit photos in management software (like Lightroom)?
- Problem: Even if the image looks visually the same – as soon as a keyword (tag) or rating is written into the file, the file content changes.
- Result: All affected files are detected as “new” and fully copied.
4. Moving or Renaming Folders Did you move a large folder “Vacation 2023” from /Photos/New to /Photos/Archive?
- Problem: rsync (the engine behind BmuS) often does not recognize “moves” as such. It sees: “Oh, files in /Photos/New were deleted” and “Hey, lots of new files in /Photos/Archive”.
- Result: The files are created anew at the new location (consuming storage space) instead of just being linked.
5. Encryption (Indirect Effect) If you use encryption (BACKUP_ENCRYPTION=1), this applies even more strictly.
- Problem: Since filenames and contents are encrypted, BmuS cannot “look inside” the file to compare it with previous plain versions.
- Result: If deduplication doesn’t work well in plaintext (see points 1-4), it definitely won’t work in an encrypted state. (Note: BmuS technically prevents enabling both simultaneously to avoid this inefficiency).
💡 Optimization Tip: If you have huge files that change minimally every day (e.g., VM images), consider excluding them via BACKUP_EXCLUDE or accept the higher storage requirement. For databases and normal documents, this behavior is normal and usually uncritical, as these files are often small.