Known limits

What SQZ does not do yet, stated plainly, so nothing surprises you after you have relied on it.

Archives#

• Not stored yet: file owners, ACLs, extended attributes and sparse regions (sparse files are stored as their full contents). Folders, symlinks, hard links, permissions and exact modification times are kept.
• Skipped with a warning: names that are not valid UTF-8, sockets and device files.
• Not encrypted. .sqz files detect accidental damage but anyone can read them. Use SQZ Backup for encryption.
• No deleting snapshots. An archive keeps every snapshot. SQZ Backup has retention and prune.
• Restores go into a new folder and never overwrite. The destination drive must support hard links, so FAT32 and exFAT drives cannot be extraction targets.
• On Windows, folder times are not restored, and symlinks are created only when your account may create them.
• Very large archives: memory to open an archive grows with the number of files (about 400 bytes per file; 860 to append). Up to 2,000,000 files is measured. A paged index for archives beyond about 5,000,000 files is designed but not built.
• Unchanged files are still read when appending, to prove they are unchanged. Consistent open-file snapshots and journal-based change detection exist for backups on Windows, not for archives.

Compression#

• Max is not guaranteed to beat Balanced on every input, because it picks codecs from samples.
• Smart is not yet better than Balanced on the data measured so far; it is opt-in on the command line.
• Max is slow: the context-mixing engine runs at about 0.5 MB/s per thread in each direction, and uses about 260 MB per thread.
• Transforms apply to files up to 64 MiB, and JPEG recompression to images up to 4096×4096. Other media (JPEG XL, MP3, video) are stored with ordinary compression.
• Random or encrypted data cannot be compressed by any tool; SQZ adds under 0.1% on it.
• The memory caps on transform output are not a sandbox for the third-party codecs used.

Backups Preview#

• The repository format (version 1) may still change.
• S3-compatible storage is tested only against a simulated server, not yet a real bucket. Multipart upload is not used.
• Shadow copies, the change journal and Windows metadata are still being tested on real Windows.
• Sparse files are read at their full size and restored as ordinary files. The content is right, and the zeros compress away in the repository.
• The desktop app is an early preview: its schedules and saved passwords have been tested on Linux only so far, and it backs up one folder per plan to a local or network folder (no S3, no excludes yet).
• The backup pipeline is single-threaded; disk speed usually dominates.
• Not built: removing passwords, exporting a key file, rotating the master key, sampled check --read-data.
• Only one writer at a time; restoring while pruning can fail (never with wrong data).
• Repositories in the hundreds of GB and network drives are not measured yet.

Measurements#

Numbers in these docs come from the runs described next to them: mostly small generated inputs and a few real folders, on one machine each. They show what to expect, not a promise about your own data. sqz estimate and sqz bench measure your own files.