Known limitations

Go to the contents

• Encryption knows no key rotation: the key applies for the lifetime of a store (of a generation); import does not re-encrypt.
• ID hash and chunk size of a store are fixed on creation; they are changed through a new generation. Re-chunking existing runs does not exist.
• On a local file system and in the target WORM locks are metadata that prune/delete respect; only on S3 is a lock enforced (Object Lock).
• bkp_restore --list and bkp_sched only show the sinks of the agent configuration as places of a run, no mirrors.
• Snapshots: LVM (Linux) and VSS (Windows); bkp_proxmox additionally uses ZFS, RBD and qcow2 snapshots. Other techniques (btrfs, ZFS outside Proxmox, thin without LVM) do not exist; the hooks remain for them. Changed block tracking exists for Proxmox VMs (QEMU dirty bitmaps) and Hyper-V (RCT); otherwise every backup reads the used areas of the source completely.
• Free area detection: ext2/3/4 and NTFS; other file systems are read completely. With ext4, BLOCK_UNINIT groups are not yet treated separately.
• Archives: bkp_dump shows no archives; the restore from stdin does not check the SHA-256 at the end (but every object is checked against its ID); import --dry-run checks completely. bkp_verifier cannot check an archive.
• Fail-safe network backup (Chapter 4): the real restart trigger (systemd unit, scheduled task) has so far not been checked by a real reboot, only bkp_agent --resume-pending by hand or by killing the process.
• Holding (bkp_sched hold, target console): holding VM backups (proxmox, xenv, hyperv) has so far not been checked on real hypervisors. A held run with an LVM snapshot keeps the snapshot until it continues; with long holds watch the snapshot space.
• bkp_target, bkp_maintenance and bkp_monitor only run on Linux; on Windows bkp_sched only runs bkp_agent jobs; the management console bkp_console only exists for Windows (but it also manages Linux servers).