different size backup and real ct

S

simrsta

Member
Oct 25, 2022
44
2
13
I have lxc for docker. Why is the actual size and the backup result different?

backup in pbs
1764661733571.png

size in pve
1764661748527.jpeg
 
Hi, check the backup task log for more details. Most likely you have a mount point which is included in the backup. The mount point ist not part of the root filesystem and therefore also not show in the boot disk size.
 
  • Like
Reactions: bl1mp
1764664164814.png

I made a rule like that
but only the docker server is weird
apart from the docker server all disk sizes are normal and reduced
 
Share the config for that container: pct config 100080 --current
 
Chris said:
Share the config for that container: pct config 100080 --current
Click to expand...
arch: amd64
cores: 12
features: nesting=1
hostname: ServerDocker
memory: 20480
net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=BC:24:11:00:DF:F6,ip=dhcp,ip6=dhcp,type=veth
onboot: 1
ostype: ubuntu
rootfs: local-data:subvol-100080-disk-0,size=112G
swap: 0
unprivileged: 1


config 100080
and every i backup serverdocker, It took quite a long time, as if it wasn't incremental,
because it was like backing up from scratch
around 40 minutes
 
Last edited:
what kind of storage is local-data? ZFS for example can store a lot of logical data in 112G of physical quota..
 
Then you most likely have one or more sparse files which lead to the size increase, see
O

Thread 'Huge size of LXC backup using Proxmox Backup'

Environment:
Bash: 
$ pveversion
pve-manager/6.4-13/9f411e79 (running kernel: 5.4.143-1-pve)

# proxmox-backup-manager versions
proxmox-backup-server 2.1.2-1 running version: 2.1.2

Replication process (from one pve node to another):
The size is about 1.29G and the time ~20 seconds.
Code: 
2022-01-04 11:53:35 shutdown CT 502
2022-01-04 11:53:37 starting migration of CT 502 to node 'app3' (10.110.1.23)
2022-01-04 11:53:38 found local volume 'lxc-disks:subvol-502-disk-0' (in current VM config)
2022-01-04 11:53:39 full send of...

Regarding the incremental backup: even if the backup of the LXC is incremental, the source contents have to be re-read, you can use change-detection-mode see to metadata to avoid that, see https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_ct_change_detection_mode
 
yeah, so then you have a big file that is actually empty, which ZFS can store efficiently without hitting the quota ("size") for the guest volume. for PBS this looks like a big (probably very compressible ;)) backup.
 
fabian said:
yeah, so then you have a big file that is actually empty, which ZFS can store efficiently without hitting the quota ("size") for the guest volume. for PBS this looks like a big (probably very compressible ;)) backup.
Click to expand...

I don't understand what this means. What should I do to make sure the size is correct?The actual size is 112GB, but when backed up, it becomes 500GB+
 
you have a file that is probably a few hundred GB "big", but filled with zeroes. ZFS can store that and all the other data while taking less than 112GB of space. but PBS will still see the total size of the file and display that. PBS will most likely also take a lot less actual space for storing it, because it does compression and deduplication.

you can either ignore it, or try to make that file smaller. please also check out the thread that chris referenced.
 
You must log in or register to reply here.
Top Bottom