Trimming file failed. Image backup may use too much storage

1

I am seeing this error after an incremental image backup. What can I do to fix this this please?

WARNING: Trimming file failed. Image backup may use too much storage.

My UrBackup Server is running on Debian 10 with a mirrored vdev ZFS pool dedicated solely to UrBackups.

In /var/log/urbackup.log I am seeing these entries related to this warning above.

2020-06-12 01:20:49: Basing image backup on last incremental or full image backup
2020-06-12 01:20:49: Creating writable snapshot of previous image backup…
2020-06-12 01:29:33: WARNING: fallocate failed (setting unused image range) with errno 22
2020-06-12 01:29:33: WARNING: Trimming syscall failed. Stopping trimming.
2020-06-12 01:29:33: WARNING: Trimming file failed. Image backup may use too much storage.
2020-06-12 01:29:34: Transferred 2.74271 GB - Average speed: 44.9153 MBit/s
2020-06-12 01:29:34: Time taken for backing up client M92p: 8m 52s
2020-06-12 01:29:34: Backup succeeded

Any help will be appreciated :slight_smile:

2

I am experiencing the same issue during a incremental windows client backup to using raw. Backing up to a btrfs file-system. Any troubleshooting tips?

Following is the last few messages on the server

2021-01-19 12:19:42: WARNING: fallocate failed (setting unused image range) with errno 22
2021-01-19 12:19:42: WARNING: Trimming syscall failed. Stopping trimming.
2021-01-19 12:19:42: WARNING: Trimming file failed. Image backup may use too much storage.

3

I’ve had a similar issue since near day 1 with my deployment. Server is Debian, backup drive is BTRFS. Never found any ideas or help with it. Willing to try again though.

Client log:

2021-01-25 09:40:13(info): Starting scheduled incremental image backup of volume "C:"...
2021-01-25 10:24:55(info): Basing image backup on last incremental or full image backup
2021-01-25 10:24:55(info): Creating writable snapshot of previous image backup...
2021-01-25 12:01:39(warning): Trimming file failed. Image backup may use too much storage.
2021-01-25 12:01:57(info): Transferred 15.7669 GB - Average speed: 23.4141 MBit/s
2021-01-25 12:01:57(info): (Before compression: 27.7833 GB ratio: 1.76213)
2021-01-25 12:01:57(info): Time taken for backing up client REDACTED: 2h 21m 43s
2021-01-25 12:01:57(info): Backup succeeded

Server log:

2021-01-25 12:01:39: WARNING: fallocate failed (setting unused image range) with errno 22
2021-01-25 12:01:39: WARNING: Trimming syscall failed. Stopping trimming.
2021-01-25 12:01:39: WARNING: Trimming file failed. Image backup may use too much storage.
4

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

image
image1456×659 73.9 KB

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)

5

I think it calls trim with a zero length right at the end. So yeah, that needs to be patched so it doesn’t have this warning but it doesn’t even cause what it logs about (Image backup may use too much storage).

The statistics not being accurate is a separate issue. Please look at total file system usage/btrfs quota and create a separate thread if you still see issues.