[SOLVED] Backing up passthrough disk

[OhFarts]

Merry christmas everyone

I'm trying to setup my PVE backup with PBS (currently, I'm just doing a weekly snapshot and also daily rsnapshot backup for OMV). I don't like this way to do, so I installed PBS and it's running quite well for the CT/VM, even if the datastore is a CIFS mount hosted in Hetzner datacenter in Germany.

But unfortunately, I'm having an issue for which I can't find a way to fix it.

I'm running a Debian VM with OpenMediaVault. It has one disk for OS (100G, maybe 10 used) and another one for data (2T, about 250G used) which is mounted "directly" (using /dev/disk/by-id).

So, I started the backup job but it look its also backing up the empty space :
INFO: 0% (412.0 MiB of 1.9 TiB) in 3s, read: 137.3 MiB/s, write: 97.3 MiB/s
INFO: 1% (19.6 GiB of 1.9 TiB) in 1h 31m 45s, read: 3.6 MiB/s, write: 3.3 MiB/s

According to a few answers found on Google, it looks I need to convert this disk to lvm-thin, is that right ?

 

[aaron]

The backup does not know which part of the disk is in use by the guests file system. So it has to scan the whole disk. On the next backup run, PVE will know which areas were changed on the disk and thus the next Backup will be a lot faster. This works as long as the VM is not completely shut down. If the VM has been shutdown the ext backup will take longer as the whole disks needs to be scanned again. Then on the subsequent backups it will be fast again because PVE will keep track of the areas on which data has changed since the last backup.

According to a few answers found on Google, it looks I need to convert this disk to lvm-thin, is that right ?

No, the backup does not care about the underlying file system or anything as it is using the Qemu virtualization layer to access the guests disks and to keep track where the guest changed data in between backups.

 

[OhFarts]

Thank you Aaron

Does it mean PBS will use 1.9 TiB of the backup server or this scan won't store anything ?

 

[aaron]

Does it mean PBS will use 1.9 TiB of the backup server or this scan won't store anything ?

Nope. I am not sure how a block of zeros will be stored (compressed or not) but the deduplication will make sure that a block (currently 4M IIRC) which is similar to other blocks (on empty disks usually the case) will only be stored once and referenced multiple times.

Because the backup job scans the disk without knowing about the file system on it or what is actually used or files that were deleted at some point, you should enable discard/trim inside the guest. This will zero out any parts where old stuff like deleted files is still present.

 

[OhFarts]

Nope. I am not sure how a block of zeros will be stored (compressed or not) but the deduplication will make sure that a block (currently 4M IIRC) which is similar to other blocks (on empty disks usually the case) will only be stored once and referenced multiple times.

Because the backup job scans the disk without knowing about the file system on it or what is actually used or files that were deleted at some point, you should enable discard/trim inside the guest. This will zero out any parts where old stuff like deleted files is still present.

Thank you again Aaron

I've enabled "discard" on both disks and ran fstrim inside the Debian VM :

root@nas:~# fstrim --verbose --all
/srv/dev-disk-by-label-Data: 1,2 TiB (1364236902400 bytes) trimmed on /dev/sdb1
/: 93,4 GiB (100326211584 bytes) trimmed on /dev/sda1

But If i use this command once again after restarting the VM, the same result is displayed. I know this is not PVE/PBS related, I just wanted to mention it.

I think I'm going to rent a new remote server to host PBS instead of just hosting the datastore remotely through SMB.

 

[jhollowe]

If you look at the man page for fstrim, you can see this is due to how the verbose flag works:

-v, --verbose
Verbose execution. With this option fstrim will output
the number of bytes passed from the filesystem down the
block stack to the device for potential discard. This
number is a maximum discard amount from the storage
device's perspective, because FITRIM ioctl called repeated
will keep sending the same sectors for discard repeatedly.

fstrim will report the same potential discard bytes each
time, but only sectors which had been written to between
the discards would actually be discarded by the storage
device. Further, the kernel block layer reserves the
right to adjust the discard ranges to fit raid stripe
geometry, non-trim capable devices in a LVM setup, etc.
These reductions would not be reflected in
fstrim_range.len (the --length option).

 

[OhFarts]

Hello guys and happy new year

I finally finished this backup yesterday, unfortunately PBS has backed up the empty space on both disks even if I used fstrim.
This is the only VM I'm backing up, the CT's backup only contain used data

Any idea ?

I'm using a hardware RAID controller, is it possible it prevent the use of fstrim ?

Let's say this post never existed