v0.9.0-beta.1 — first beta

First beta. Tested thoroughly and usable alongside your current backup, but not yet a
drop-in replacement for it. We test what we can ourselves (Nextcloud 32–35, SQLite, MariaDB and
PostgreSQL, S3, SFTP, FTP, SMB and NFS), but we need field experience from other setups: please
report what works and what doesn't, especially on large instances and on storage providers not
listed in the README.

Added

• Disaster recovery: occ backup:key:import and occ backup:restore:full restore the database,
  data directory and config onto a fresh installation of the same major version.
• Per-user backup and restore via user_migration: occ backup:user:backup and
  occ backup:user:restore (replace the account after a safety export, or restore as
  <uid>-bak), also onto a server where the user does not exist yet. The commands ask before
  installing user_migration (or take --install-user-migration).
• Checksum audit: occ backup:verify, shallow or --deep, for snapshots and per-user exports.
• Retention for per-user exports: occ backup:retention --user-last=N.
• FTP and SMB covered by the integration tests; NFS through the local backend on a mounted share.
• docs/HOWTO.md: step by step from setup to a tested restore.
• Warnings when a backup finishes with unreadable files or folders, or with files that kept
  changing while being read (log, occ, notification, snapshot).

Changed

• backup:restore:full refuses on an installation with more than one user and asks first;
  backup:user:restore --mode=replace asks before deleting an existing account (--force for
  scripts in both cases).
• A failed scheduled backup is retried at most three times a day, an hour apart.
• The recovery kit carries the deletion delay; the kit file is created owner-only.
• Adding a location through the web API needs password confirmation.

Fixed

• Exports of users whose id contains .part- could be deleted by cleanup on remote locations.
• Cleanup no longer frees the data of a per-user export whose manifest is missing.
• Crash safety of moving snapshots to and from the trash, of catalog writes by concurrent
  backups and per-user exports, and of short uploads.
• A file that keeps changing no longer makes a backup restart forever.
• Long restores and exports keep their lock on the location alive.
• Floating-point database columns are dumped exactly.

Known limitations

See "Known limitations" in the README: memory use on very large instances, never two servers
writing to one location, removing a passphrase slot does not revoke access, no rollback detection
before a disaster recovery, and a few smaller points. None of them block the road to 1.0.0; they
are on the backlog in PLAN.md.