Just posting here to report, that I am in fact running into the same issue.
This seems to happen on both my Fedora 27 install (as a service) as well as with the Docker-Image on Debian 10 (Kernel 5.10/ OMV install).
Disk usage therefore spikes like crazy whenever I do even just a small incremental backup.
| 20.07.21 00:41 | DEBUG | Backing up SYSVOL… |
|---|---|---|
| 20.07.21 00:42 | DEBUG | Backing up SYSVOL done. |
| 20.07.21 00:42 | DEBUG | Backing up EFI System Partition… |
| 20.07.21 00:42 | DEBUG | Backing up EFI System Partition done. |
| 20.07.21 00:42 | INFO | Basing image backup on last incremental or full image backup |
| 20.07.21 00:42 | INFO | Creating writable snapshot of previous image backup… |
| 20.07.21 00:42 | INFO | Change block tracking active. Max 1.9292 GB have changed. |
| 20.07.21 00:43 | DEBUG | Starting trimming image file (if possible) |
| 20.07.21 00:43 | WARNING | Trimming file failed. Image backup may use too much storage. |
| 20.07.21 00:43 | INFO | Transferred 1.53699 GB - Average speed: 156.64 MBit/s |
| 20.07.21 00:43 | DEBUG | Script does not exist urbackup/post_incr_imagebackup |
| 20.07.21 00:43 | INFO | Time taken for backing up client SUTEKI-2IN1: 1m 57s |
| 20.07.21 00:43 | INFO | Backup succeeded |
Unfortunately, with this issue, raw format backups on BTRFS seem pretty much unusable. (The spike at the end is caused by two small incremental backups)