Container backup is very slow compared to VM backup. I have a 500 GB container (sftp server) with minimal changing files, but even the incremental bakcups take 2 hours with heavy disk activity. Almost nothing is transfered to the backup server. It seems that it it reads the whole container everytime, without any optimization. Before I did backup with zfs send it there it took only a couple of seconds or minutes for every didfferencal backup.
No differantial container backup with big containers?
- Thread starter carsten2
- Start date
no, because that is at a totally different level (zfs send streams operate on ZFS objects, PBS/pxar operates on a chunk stream generated from a file/dir hierarchy).
But "zfs diff" works at the file level, so if pxar needs to know which files changed it could determine it with "zfs diff".
yeah, but a changed/removed/added file (potentially) changes the chunking boundaries, so we can't just say 'oh, all files except X are unchanged so we just need to upload X'. it's a lot more complicated compared to the fixed-index VM/block backups, where we can really just skip parts which have not changed 
yeah, but a changed/removed/added file (potentially) changes the chunking boundaries, so we can't just say 'oh, all files except X are unchanged so we just need to upload X'. it's a lot more complicated compared to the fixed-index VM/block backups, where we can really just skip parts which have not changed
I don't think so. If PBS would backup the snapshot (instead of the live filesystem) and would use "zfs diff" to detect all changed/added/deleted files, it knows which data changed and does not have to reread everything unchanged. Snapshots are also unchangeable to there is no possibility of any possible changes during backup.
Even if you would compose chunks from changed and unchanged files, it would be no problen, because the whole snapshot is readable as a constant files system.
So please explain in more detail where there should be any problem.
ZFS is not used, so you cannot use ZFS toolset.
Proxmox Backup Server is designed to work with all storage types and file-systems.
ZFS is one of the main if not THE main filesystem used in proxmox, several things like replication, VM and container snapshots use ZFS functionality, so PBS should support this main usage in a fast and efficient way. The currently PBS is incredible slow on large containers, which makes it nearly unusable. So please think about a solution for this main configuration with ZFS and containers. With snapshot and zfs diff, the changed/new/deleted files can be detected and there for a very fast differential backup can be implemented.
Also the documenation says, that for container, the underlying snapshot feature of the file system ARE used, i.e. it is not agnostic and already uses ZFS feature, why not use additional features like "zfs diff" for fast differential backup?
https://pve.proxmox.com/wiki/Backup_and_Restore
Also the documenation says, that for container, the underlying snapshot feature of the file system ARE used, i.e. it is not agnostic and already uses ZFS feature, why not use additional features like "zfs diff" for fast differential backup?
https://pve.proxmox.com/wiki/Backup_and_Restore
Last edited:
BUMP. Backup speed could be improved by factor 100-1000!
https://bugzilla.proxmox.com/show_bug.cgi?id=3138
https://bugzilla.proxmox.com/show_bug.cgi?id=3138
pbs is solving a real problem with VM image level backup , which is not solvable at the end-user/admin level, imho. i'm happy that we have a solution now.
i can understand your desire to have efficient container backups, but i also can understand why proxmox is not re-inventing the wheel for container/file-level backup or has no capacity for that.
so if you want efficient backups at file level inside containers, i would recommend taking a look at other regular file-level backup solutions like borgbackup or others.
you could also rsync (--inplace) into another zfs dataset on different host and use rotating snapshots (with sanoid for example). furthermore you could do rotating snapshots on proxmox server and use zfs level replication (with different retention policy on the backup server side)
borgbackup, rsync, zfs-replication is efficient with a large number of files, because all of them only backup changed files.
i can understand your desire to have efficient container backups, but i also can understand why proxmox is not re-inventing the wheel for container/file-level backup or has no capacity for that.
so if you want efficient backups at file level inside containers, i would recommend taking a look at other regular file-level backup solutions like borgbackup or others.
you could also rsync (--inplace) into another zfs dataset on different host and use rotating snapshots (with sanoid for example). furthermore you could do rotating snapshots on proxmox server and use zfs level replication (with different retention policy on the backup server side)
borgbackup, rsync, zfs-replication is efficient with a large number of files, because all of them only backup changed files.
i can @carsten2 understand very well, but the position of proxmox i can not folllow. at the moment there exist no solution to backup big container mappings with many files. But it exists a lot of apps they produce such enviroment like file servers, proxies. if there is no possibility to develop it for ceph and other basis fs so then people who use local zfs should use it because zfs can support this (see upwards). zfs is supported since the beginning of proxmox and is well integrated for instance there is a separat menu point for storage, you can replicate over menu and actually there exist the possiblility to install the root on zfs. it's all other as unlogical to support better backup speed for pbs.
I think I'm going to rsync or "duplicati" for docker/filesystem contents of my containers (duplication support) to another disk on a VM that can do quick backups (5 secs lol). I'm in the same boat in that CT's take forever to backup. I use mountpoints as well and they cripple snapshot functionality as well.....
yes, there are.
@Chris just posted a first RFC patch series: https://lists.proxmox.com/pipermail/pbs-devel/2023-September/006679.html
note that this is a big change that needs to be reviewed and tested thoroughly, so there might still be some iterations or changes to the approach taken - and in its current form, it's still only a rought draft as noted in the cover letter.
most importantly - please do not attempt to run this anywhere near production systems (yet)! there might be bugs, the format changes are not yet finalized, etc.pp.
@Chris just posted a first RFC patch series: https://lists.proxmox.com/pipermail/pbs-devel/2023-September/006679.html
note that this is a big change that needs to be reviewed and tested thoroughly, so there might still be some iterations or changes to the approach taken - and in its current form, it's still only a rought draft as noted in the cover letter.
most importantly - please do not attempt to run this anywhere near production systems (yet)! there might be bugs, the format changes are not yet finalized, etc.pp.