Changelog

Version 1.0.5

Fixed

• A destination’s own limit on simultaneous uploads was ignored. How many files a run wrote at once came entirely from the job’s impact profile. A local folder has no such limit, so this was invisible there — but Google Drive does, and a machine with many cores set to Full speed would have opened one upload per core against it. A run now takes the smaller of what the impact profile asks for and what the destination says it can take. Restore is deliberately unchanged, because it reads from the destination and writes locally.

Added — a remote server straight to the cloud

• An FTP, FTPS or SFTP source with a Google Drive destination means neither end of the run is on this computer, and that combination is now proven rather than assumed. It streams: bytes are read from the server, transformed in flight and uploaded in chunks, with nothing staged on the local disk — so backing up 10 GB from a server needs no free space here at all.
• Verified against a real server on all four protocols — backup, catalog, browse, verify, restore, and a differential over an unchanged tree correctly storing nothing. Every protocol’s restore was also compared against the others, since all four read the same directory and must therefore produce identical bytes.

Version 1.0.4

Added — Google Drive destinations

• Connect a Google account under Settings, then pick a folder in it as a job’s destination. Sign-in happens on Google’s own page in your browser; BackupDesk never sees your password, and the permission it is handed is kept by the background service so scheduled backups run without asking you anything.
• BackupDesk can only ever see folders it created itself. It asks Google for the narrowest permission available, so the rest of your Drive is invisible to it — which is also why the folder picker shows a flat list rather than a tree: there is nothing else it is allowed to look at, and a tree would promise access the permission does not grant.
• Retention genuinely frees the space. Pruning an old backup chain reclaims the storage it occupied in your Google account rather than moving it to the trash.
• Rate limiting is retried with backoff, and a full Drive is reported with the step that fixes it rather than in Google’s own wording.

Fixed — found by testing the feature above

• Verify reported a good encrypted cloud backup as damaged. The worst of the defects this feature turned up, because a backup product that denounces a good backup is failing at the job either way. Two parts of BackupDesk disagreed about how a stored file’s path is written down, so every file in a cloud backup read as unreadable. A restore of the same backup was byte-identical throughout: the backup was always fine. Both sides now follow the same rule, and a shared test suite holds them to it.
• An ordering mistake truncated the file list of every encrypted cloud backup. The backup was published a moment before the encrypting writer had emitted its final chunk. Harmless on a local drive, where the file stays open and is flushed anyway — which is why it stayed hidden until a backup was written to Drive. It was caught on reading as a truncated payload, which is the authenticated encryption doing its job.
• Browse, verify and retention could look in the wrong place. Several read paths fell back to a local folder instead of the job’s actual destination, so cloud backups were written correctly and then reported unreadable or invisible. The quietest was the baseline a differential builds on: with none found, every differential silently promoted itself to a full and re-uploaded everything.

Version 1.0.3

Fixed — the important one

• A folder the scan could not read had its contents recorded as deleted. Deletions are found by elimination — whatever the scan never reached is presumed gone — which is only sound when the scan actually looked. A folder denied by permissions, an access-rights change, a network share hiccup, or an ordinary blip mid-scan on a remote source was enough to trigger it. The consequences compounded: that backup restored the moment in time without those files while they sat on disk untouched, every later backup in the chain inherited the loss until a full re-scanned the folder successfully, and the run still reported itself completed. BackupDesk now records which folders it could not open and carries their previous contents forward untouched instead of writing them off. Real deletions elsewhere are unaffected, and the folder failure is still reported. Covered by two regression tests, both of which fail against the old behaviour.

Fixed — correctness & resilience

• The file that declares a backup complete was written before its own checksum. A crash in that window produced a backup that reported itself restorable and then failed verification as damaged — a good backup denounced as corrupt. The checksum is now in place first, and the backup stays checkable with ordinary command-line tools.
• A file symbolic link was restored as a folder link. Windows makes those two different objects, chosen when the link is created and not inferable afterwards from a target that may not exist on the machine being restored to. Which kind it was is now recorded at backup time. Links deeper than 260 characters also always read as absent, producing a confusing report of a problem that was not the problem.
• A run stopped by shutting the service down was recorded as a failure. An ordinary restart went into history as Failed. A backup product reporting failures for ordinary events is how a real failure ends up unnoticed, so cancellation is now its own outcome with a sentence saying what happened. Genuine faults are still failures.
• Finished runs were never removed from the queue. Every completed, failed and cancelled run stayed in memory for the life of the service, and that list is walked several times a second by the scheduler, the dashboard and every status refresh. A machine running hourly backups accumulated tens of thousands of dead entries a year.
• An unexpected Store failure could close the app mid-purchase. The upgrade dialog handled the failures the Store was expected to produce; anything else escaped and took the app down while someone was trying to pay.
• “Something more urgent took your slot” when nothing had. A job waiting behind another job of equal priority was told it had been overtaken. The message is now checked against the priority of whatever actually started.

Changed

• The dashboard’s New job button now offers the upgrade first. The free-tier check covered the Jobs screen but not the dashboard — the app’s most prominent button — so a free-tier user could pick sources, build a schedule, set retention, press Save and only then be told the job could not be created. Nothing was ever created that should not have been; the wasted work was the problem. Every route to a new job now goes through one place.
• Pruning orphaned backups says when it has emptied a job. Backups whose full is gone cannot be restored and so protect nothing, which is why the guard that keeps your last chain does not cover them — but a job with no chains at all ends that pass with nothing left on the destination, and you should be told rather than find an empty folder later.

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.