Skip to content

KNOWN_LIMITATIONS.md

Latest commit

 

History

History
41 lines (30 loc) · 2.71 KB

KNOWN_LIMITATIONS.md

File metadata and controls

41 lines (30 loc) · 2.71 KB
Raw

Known limitations

These limitations apply to public release 2026.07.30.3.

Incremental backup

  • QEMU changed-block incremental capture requires a running VM, supported QCOW2 disks, and valid libvirt checkpoint metadata.
  • Raw images, ZFS zvols or other block devices, and stopped VMs use sparse full capture.
  • A missing, incompatible, or reset checkpoint requires a new full baseline.
  • Final QEMU checkpoint synchronization can continue after data transfer has reached its last reported byte count.

Consistency

  • Successful QEMU Guest Agent filesystem freeze provides filesystem coordination, not guaranteed application-level consistency.
  • Without guest freeze, a running VM recovery point is crash-consistent.
  • Databases and transactional applications may require application-specific pre-freeze and post-thaw procedures.

Recovery Testing

  • Automated verification requires a responsive QEMU Guest Agent in the restored guest.
  • A booted console without guest-agent confirmation requires manual review and is not marked Verified.
  • Recovery Testing requires temporary local capacity for sparse restored disks and consumes host CPU while the test VM runs.
  • Network interfaces are disabled by default. Enabling them can create address, service, or workload conflicts.

Storage and performance

  • Repository setup requires a mounted NFS or SMB destination hosted outside the protected Unraid server by default.
  • The advanced same-host override weakens the failure boundary: host, controller, pool, filesystem, or power failures may affect both source and backup data.
  • Repository paths must remain below /mnt/. Same-host mode does not bypass mount or create, write, synchronization, read, rename, and delete checks.
  • Same-host detection uses mount metadata and known local host names and addresses. Administrators must verify destinations reached through unrelated DNS aliases.
  • NFS and SMB performance depends on mount options, latency, server behavior, and available bandwidth.
  • Sparse files remain thin only on filesystems and copy paths that support sparse allocation.
  • Deduplication and compression consume CPU. Source reads, network transfer, destination writes, or processing can determine throughput.
  • Garbage collection removes only unreferenced chunks after deletion and retention processing.

Compatibility

  • Supported baseline: Unraid OS 7.2 or newer with Node.js 22 or newer.
  • Hardware passthrough and host filesystem mappings are intentionally removed from Recovery Testing VMs.
  • Recreated production VMs require administrator review of storage, network, firmware, removable media, and passthrough mappings.
  • Public compatibility evidence is still developing across Unraid host, guest, storage, and network combinations.