Changelog

Version 1.0.2

Fixed

• Granting access closed the app instead of opening it. On a successful grant, the first-run window was the only one open, so closing it shut the whole application down a moment before the main window could be built. The app now stays alive through the grant and opens normally.
• Permission grants on a standard account always failed once the service had started. Clicking “Allow” on the first-run manage backups screen reported an error every time in what turned out to be the ordinary case, not an edge case — the elevated helper did not have enough rights on one of its own files to add the account that clicked Allow. Only a second, non-administrator account ever reached this path, which is why the first round of testing missed it.

Version 1.0.0

Added — backup engine & format

• Change detection that skips unchanged files by size and modification time without reading them, and hashes the rest with SHA-256 — so a file whose timestamp moved but whose contents did not is correctly treated as unchanged.
• Three backup levels — full, differential and incremental — with the space-versus-resilience trade-off shown at the point where you choose, and again where you delete backups.
• Self-describing backup sets. Each set is a plain folder holding a manifest, a per-file list with hashes, a checksum of both, and your files stored whole. No central database to lose, and a single surviving folder can be read and restored on its own.
• A set is only committed once it is complete, so a cancelled or interrupted run never leaves a half-written backup that looks restorable.

Added — jobs, scheduling & retention

• Job-based operation with a background service that runs whether or not the window is open — sources (one or many, on different drives), exclusions with suggested defaults, a destination, a schedule and an impact profile.
• Schedule presets — Standard, Most resilient, Smallest daily backups and Manual only — each editable afterwards rather than a locked mode.
• A job queue instead of parallel runs, so two jobs do not fight over the same disk; a queued job says what it is waiting for. Cancel always works, and pause/resume are offered where they make sense.
• A missing destination is a wait, not a failure. An unplugged external drive puts the job into waiting and it starts on its own when the drive returns.
• Retention by chains — a full plus everything that depends on it, always pruned as a whole, so a full is never deleted out from under its differentials. BackupDesk announces every prune, refuses to delete the only remaining chain even on a full disk, and never prunes a chain being restored from.
• Impact profiles — Low impact (default), Balanced and Full speed — plus an optional throughput cap for shared networks.

Added — restore, verify & open files

• Restore by point in time or by search — walk a set as the tree looked then, or search a filename across every set to see all its versions with dates. Restore all or just what you tick, to a chosen folder or the original locations, with three overwrite behaviours.
• Every restored file is checked against the hash recorded when it was backed up, so a file damaged in storage is reported rather than silently restored.
• Verify re-reads a stored set and checks every file against its recorded hash — the defence against bit-rot on archival drives.
• Volume snapshots so files held open by another program are still captured; a file that genuinely could not be read is listed in the run report rather than quietly skipped.

Added — remote sources (FTP, FTPS, SFTP)

• A job’s source folders can live on another machine over FTP, FTPS or SFTP, browsable from the job editor.
• Test connection runs from the background service, not from the window — so a successful test is evidence the unattended run will connect, rather than proof that your account can.
• SSH host keys must be accepted before a job depends on the server. An unknown key is refused rather than trusted silently, which would otherwise make jobs work whenever you were watching and fail every time you were not.
• SSH private keys are imported, not linked, because the service does not run as you and cannot read files in your user profile.

Added — compression

• Per-job compression: Off (default), Faster, Balanced or Smaller.
• The three levels were chosen by measurement, not guessed — benchmarked against a real mixed tree of source and binaries. The measured curve overturned an evenly-spaced first guess: Balanced turned out to be the real knee, with much slower settings buying almost nothing over it.
• Already-compressed extensions (archives, images, video, Office formats) are skipped, so compression never burns processor time on a payload that would come out the same size or larger.
• The compression level you pick is always honoured; the impact profile governs only priority and how many cores are used.

Added — encryption

• Per-job encryption with AES-256-GCM over file contents and the file list, so an encrypted destination reveals neither what your files contain nor what they are called.
• A chunked authenticated stream means a truncated payload fails verification instead of silently restoring short.
• Two independent ways in — your password and a mandatory one-time recovery key — with every set in a chain carrying its own copy of both, so a single differential folder stays decryptable without needing any other file.
• Verify stays keyless even for encrypted sets, so bit-rot checking on an archival drive needs no password.
• The service keeps a machine-protected copy of each job’s key so scheduled runs never stop to ask for a password — and that copy is never written into the backups, which would have made them readable only on the computer that produced them.
• New job-editor cards for compression and encryption (with password and one-time recovery-key dialogs), and a password field on the restore screen shown only for an encrypted set.

Added — free tier and the Pro add-on

• The free version runs one backup job, and that job is not limited in any way — all three levels, retention, remote sources, snapshots of open files, compression, encryption, verify and restore all work fully. The limit is on job count and nothing else.
• Nothing ever touches an existing job. Losing Pro leaves every job present, enabled, editable and running; only a new one is refused. A backup product that stopped protecting files when a payment lapsed would do more damage than the sale was worth.
• Being unable to reach the Store is never treated as “not owned” — offline and not-signed-in are ordinary situations, and the last known answer stands through them. A genuine refund still takes effect.
• The upgrade dialog is offered before the editor opens rather than after a job has been filled in and refused, and leads with what does not change — the existing job keeps running and its backups stay restorable.
• The Jobs screen shows “0 of 1 job used” on the free tier, and nothing at all on Pro.

Changed

• The package now declares a single listed application, resolving a Store submission that rejected the earlier build as a headless app. The background service is unchanged — same executable, same account, same automatic start — and there is no second Start-menu tile.

Security

• The SFTP component was updated ahead of release to clear a published high-severity advisory. BackupDesk never used the affected code path — the feature it belongs to was ruled out by design — but shipping a package with an open advisory into a manual Store review was not a trade worth making.
• Only accounts approved once at first run may control the background service, because that service can read every file on the computer.

Known limit in 1.0: restoring an encrypted backup needs the job to exist in BackupDesk on the machine you are restoring on. Recreate the job pointing at the same destination and your password or recovery key will open the backups.