Changelog

Every release, with the SHA-256 of each package so you can verify what you downloaded. Older builds stay available: download any previous version.

4.11.2 — 24 October 2026

Current release

• NTFS permissions (every edition). Each file's and folder's owner and the access entries set on it directly are recorded with the backup, and Restore NTFS permissions puts them back — on by default to the original locations, off into a new folder. Also --permissions on leocore restore-files and LeoCore Rescue. Backups made before 4.11.2 hold none.
• Browsing never holds up the console. A file list this machine does not keep is fetched in the background with a progress figure, and from a folder, share, S3-compatible bucket or Azure container only the list is read, not the whole archive.
• Faster file restore drills (Datacenter). On those destinations a drill reads just its sample instead of downloading the archive first.
• Larger file sets. A file list takes about a quarter less memory, and a differential run about half: a set of a million files now peaks around 0.75 GB.

Installer — LeoCoreBackup-4.11.2-setup.exe, x64, self-contained (no runtime prerequisite). Includes LeoCore Rescue.

5FECE156B5653A3827022B13E4842D5C633C207D87E75EB9124BCC45CB9A5A09

LeoCore Rescue — leocore-rescue-4.11.2-x64.exe, x64, standalone, free. Now restores NTFS permissions with --permissions.

3F66D0617FE4B0A5E23C4F339B7782C93B3A725AAC95B5207D9CD8106E87E2AF

Compact package — LeoCoreBackup-4.11.2.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime. Rescue is not in this package — get it separately above.

25AF909F2E5AF0D2F3CD576FD3EF227E8D01B5DAF1221F51E342A53B668F1A0B

4.11.1 — 24 October 2026

• Differential file backups (Server and Datacenter). Only files that are new or changed since the last full are copied; the backup's list is still the whole set, so a restore needs the full and one differential. Schedule them exactly as you would for a database.
• A warning when files change dramatically (Server and Datacenter). When 40% or more of the files were rewritten or deleted at once, or many were renamed onto a new extension such as .locked, the run is a warning and the backup before it is held back from retention.
• Browse and search a backup when restoring. Open folders, search by name and tick what you want; patterns still work. Nothing is downloaded just to look.
• Restore drills for file sets (Datacenter). The newest backup is restored into a scratch folder — a sample of up to 2 GB for larger sets — every file checked against its SHA-256, then deleted.
• LeoCore Rescue opens differentials, finding the full beside them by its identity, and the new leocore files command lists what a backup holds.
• The schedule and drill dialogs now show edition limits before you save, rather than refusing at Save.

Installer — LeoCoreBackup-4.11.1-setup.exe, x64, self-contained (no runtime prerequisite). Includes LeoCore Rescue.

ED5ABB0BD68BA887D65EF5B36FAF62AED6D3E6A4E8E9DC3F6EEF55207DDB5743

LeoCore Rescue — leocore-rescue-4.11.1-x64.exe, x64, standalone, free. Now opens file differentials as well.

2EC73930371194FC6103CAC09159A66BB374CE663B9FCA67FE52EC0062B25299

Compact package — LeoCoreBackup-4.11.1.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime. Rescue is not in this package — get it separately above.

5B785D4D00E849D83EB8077FC25F50C04BA71EEA6DCDA932BC683D4E7B92C0C1

4.11.0 — 24 October 2026

• Open files are copied, not skipped. Local folders are read from a Volume Shadow Copy snapshot, so files another program holds open — Outlook data files, QuickBooks companies — are copied as they stood at the start of the backup.
• Every file is proved. Each backup carries a file list with every file's SHA-256, and after every run each file is read back from the archive and checked against it.
• Restore what you need, where you want it. Everything, or only the folders and files you name; into a new folder or back where they came from; and existing files are left alone, replaced if older, replaced, or kept beside the restored copy. Each file is checked before it replaces anything. On the command line: leocore restore-files.
• Sensible by default. Exclusion patterns, with Windows' own files, LeoCore's folders and the job's own backup destinations always left out; folder links are not followed, and OneDrive online-only files are not downloaded.
• LeoCore Rescue opens file backups without LeoCore installed, checks every file, and shows how to copy them back. The recovery kit explains the same.
• Editions: Solo backs up one file set of up to 50 GB, and file sets do not count towards its two databases; Server and Datacenter are unlimited. Differential file backups, browsing a backup when restoring, and restore drills for file sets follow in 4.11.x.
• Fixed: an encrypted archive entry stored without compression could not be read back. Nothing shipped before this release wrote one, so no existing backup was affected.

Installer — LeoCoreBackup-4.11.0-setup.exe, x64, self-contained (no runtime prerequisite). Includes LeoCore Rescue.

53EDED97928311D8DFB5167A2ED4276E184E3DE1E0B276F51EFCC62EF18C41AA

LeoCore Rescue — leocore-rescue-4.11.0-x64.exe, x64, standalone, free. Now opens file backups as well as database backups.

F2914DD39CCD67ED48023E0DD5CE4AA5519260A0A293F5D3BFD6E2CFF16BD8FC

Compact package — LeoCoreBackup-4.11.0.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime. Rescue is not in this package — get it separately above.

F014C65C46B1425670E94D891FEF7691060D2AC0A93BA6DEA0676ADE7B787CED

4.10.4 — 24 October 2026

• The installer closes the console first. Installing over a console left open in the tray could stop with "DeleteFile failed; code 5" on a program file. Setup now closes it before replacing anything.

Installer — LeoCoreBackup-4.10.4-setup.exe, x64, self-contained (no runtime prerequisite). Includes LeoCore Rescue.

045B2C395DD9D55A247B2B908EE42958C9FF8F3CEE44AC36C67BCF85F3CF183E

LeoCore Rescue — leocore-rescue-4.10.4-x64.exe, x64, standalone, free. Unchanged apart from its version number.

FCD7CED4AEA4AB06AB0555D194D508CF865EC5D6C4EE9ADA6666C8931FAE54A5

Compact package — LeoCoreBackup-4.10.4.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime. Rescue is not in this package — get it separately above.

C9F29A27F47B691EA6DCFB44944FC0B10E73BB9DD6CFD0307567A53BA7816880

4.10.3 — 24 October 2026

This release also closes everything found in a full security review of the product and the website.

• Stored credentials are readable only by administrators. %ProgramData%\LeoCore inherited read access for every user of the machine. The service now restricts it to SYSTEM and administrators each time it starts, so existing installs are repaired by the update.
• Server identity is checked. FTPS certificates are validated; a self-signed certificate, an SFTP host key and an SSH tunnel's host key are remembered on first use and a change is refused until you accept it with Test. An FTP server that has offered encryption must keep offering it, and SMTP on Auto now requires STARTTLS on ports 587 and 25.
• Saved passwords stay with their server. Changing a server, port, login or destination address — or restoring to a different server — asks for the password rather than sending the saved one to the new address.
• Restore drills cannot drop a real database. A scratch name that is one of the job's databases, or already exists, is refused before anything runs.
• Tampered encrypted archives are always caught. The AES authentication code was not checked for some compressed entries.
• Retention keeps the newest N of each kind — full, differential and log counted separately — so frequent log backups no longer push full backups out within hours. Such jobs will keep more.
• Updates and installs are harder to tamper with: the download is verified and run through one locked handle, older update descriptions are refused, a zip install's folder becomes administrator-only, and a failed update can no longer remove a working install.
• The console and command line confirm they are talking to the real service, and the service refuses tools folders and SSH key files that ordinary users could change. Changes to commands are logged with the account that made them. LeoCore Operators can run commands as the service account — trust them as administrators.
• Edition limits hold for "Run now" and the command line (differential, log and extra databases), and manual drills follow the Datacenter drill feature.
• Smaller fixes: a refused save in any dialog leaves the job unchanged; the console always opens even when the service cannot be reached; a double-click cannot start two restores; passwords embedded in a destination address are masked in logs; staged SQL Server backups are removed after a failure; PostgreSQL passwords containing : or \ work; command-line exit code 9 now means an internal error; LeoCore Rescue repairs archives over 2 GB and its password command needs an administrator prompt.
• Three third-party libraries with published vulnerabilities were updated (SQLite, System.IO.Packaging, System.Security.Cryptography.Pkcs).

Installer — LeoCoreBackup-4.10.3-setup.exe, x64, self-contained (no runtime prerequisite). Includes LeoCore Rescue.

E2D7321AF2353200545CD14262F1143654CFB65DAAF2901460B79289F12AAEEB

LeoCore Rescue — leocore-rescue-4.10.3-x64.exe, x64, standalone, free.

03A1CC0A930F033E471D4B1528BED31E46029C28683F2519F3F13B98E728BF08

Compact package — LeoCoreBackup-4.10.3.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime. Rescue is not in this package — get it separately above.

9FD9AF4155622159BE545E6DED6F3BDCAC1882CAF847DBD7F44E17C5502B126F

4.10.2 — 8 October 2026

• Engine-level verification is in every edition. RESTORE VERIFYONLY, pg_restore --list and the other engine checks were listed as Datacenter but ran on every backup everywhere. Rather than take that away, it is now simply part of every edition, and the pricing page says so.
• Release a held-back backup. When a backup finds the data looks destroyed, LeoCore keeps the copy taken before it from being deleted. The log said it was kept "until you release it", but nothing could. The restore dialog now explains any hold on the database you pick, with Release hold… once you know the data is fine.
• Azure Blob takes the account name and key you would expect. Put the storage account in Account name and its access key or a SAS token in the secret box. A connection string or container SAS URL on its own still works.
• No more Stable/Beta switch. There is one release channel; a choice that changed nothing has been removed.

Installer — LeoCoreBackup-4.10.2-setup.exe, x64, self-contained (no runtime prerequisite). Includes LeoCore Rescue.

44C03B8246FC374ED50ADFF06559FFFF60E49AD5558A575286526F0956FFCE7F

LeoCore Rescue — leocore-rescue-4.10.2-x64.exe, x64, standalone, free. Unchanged apart from its version number.

BE524D468746FDAD63C92FF2C41434B5FE01A5B08CC0B34E6C4A4FD3AC86D8F9

Compact package — LeoCoreBackup-4.10.2.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime. Rescue is not in this package — get it separately above.

6F7470AA28B3F324D036F636EDD63E80284CA34F539A9556A221816F9EB8226A

4.10.1 — 8 October 2026

• Drill results are reported. A drill now goes through the job's own email and webhook settings, worded as a drill: RESTORE DRILL FAILED rather than BACKUP FAILED, so nobody goes looking for a backup problem that is not there.
• A complete how-to guide, one click from Settings. Settings now opens with How to use LeoCore Backup, which opens the new reference: every screen, setting and feature, with a search box. On a server with no web browser set up, the address is copied to the clipboard instead.
• The encryption setting describes itself correctly. It said "Off by default". It is on by default, and always has been.
• Smaller corrections. LeoCore Rescue's help no longer says 4.7.2 archives need repairing (they do not), and the portable package's notes name the right data folder, %ProgramData%\LeoCore.

Installer — LeoCoreBackup-4.10.1-setup.exe, x64, self-contained (no runtime prerequisite). Includes LeoCore Rescue.

06038207B9B94379E44127275FFA5C2E4797998DB5DFC128B4AFFD57526BB9E6

LeoCore Rescue — leocore-rescue-4.10.1-x64.exe, x64, standalone, free. Unchanged apart from a corrected help line; earlier copies open every archive.

0B93CAA5158DB8467F8BDBAD0DC4EC66FC65A3AA8B59066519CEBDFDACA1570E

Compact package — LeoCoreBackup-4.10.1.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime. Rescue is not in this package — get it separately above.

6A2A19846D31CE71D83DE028D2982678E1C5EB432F8724F0CB75BB5DB956C8B2

4.10.0 — 8 October 2026

• Retention you can set per job — including long-term copies. Keep the newest N backups, plus the newest full backup of each day, week, month and year for as many of each as you choose (grandfather-father-son), plus an optional floor under which nothing is removed. Before you save, the dialog runs the real retention rules over the archives you actually have and says, per destination, how many the next backup would delete. Long-term copies are part of Datacenter; until now they were sold with it but could not be switched on.
• Each destination can keep its own amount. A week on the local disk for quick restores and a year of monthlies in the bucket, from one job. A destination follows the job until you give it its own rules.
• Choose the folders archives go into. Folders on a destination takes a layout such as {machine}/{yyyy}/{MM}/{job}/{database} — useful when several servers share one bucket — and shows the exact path the next backup will be written to as you type. Only folders change: file names stay exactly as they were, because they are what LeoCore Rescue reads when a server is gone. With no layout set, every destination keeps the folders it already has.
• Find the backups an earlier install left behind. After rebuilding a server, Find backups… under point-in-time recovery searches a destination — every folder, on local disks, shares, FTP/SFTP, S3-compatible storage and Azure — adds the archives it finds to the job, and they restore from the ordinary restore screen. Archives from another installation were written with its archive password: enter it from that server's recovery sheet and LeoCore proves it against the smallest archive straight away, rather than during the restore you needed it for. Before importing, it also tells you if this job's retention would delete any of them.
• Commands and SQL around a restore. A script before the restore, SQL run inside the restored database once it is online — re-linking users, masking a copy — and a script after it that always runs. They run only for restores you start, never for restore drills or table recovery, and the restore screen asks each time whether to run them. If the SQL fails, the restore is marked as a warning rather than a failure, because the data is back. Server and Datacenter, like the commands around a backup.
• A lapsed licence no longer locks a job. A job that used a Datacenter feature, such as long-term retention or restore drills, could not be saved at all once the licence moved to Server — not even renamed. Features a job already uses now stay editable; only switching on something new is refused.
• Archive password recovery is safer. LeoCore Rescue and Get-ArchivePassword.ps1 now ignore the imported password of another server, so they can never hand back the wrong one. The script also takes the newest stored value rather than the first it finds, and works when a SQLite library is present beside it.

Installer — LeoCoreBackup-4.10.0-setup.exe, x64, self-contained (no runtime prerequisite). Includes LeoCore Rescue.

5F1DD70884144040E700D02E7CBFC6B2CB234A8F3AB4C23DF2C1E085A06D35C2

LeoCore Rescue — leocore-rescue-4.10.0-x64.exe, x64, standalone, free. Its archive-password command now ignores another server's imported password; earlier copies still open every archive.

5440B87E556475BFFAC86CCF275FEC4CEE084FB35DC334011D6FF8198759753E

Compact package — LeoCoreBackup-4.10.0.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime. Rescue is not in this package — it is always self-contained, which would take the download past the size the file host allows. Get it separately above.

4D07B54528E53F082AF0C840A89C7FB5B05F71A787AF75D3E0C4E6D012287906

4.9.2 — 3 September 2026

• Solo backs up while somebody is signed in. A scheduled run on a Solo licence now waits for an interactive session — the console, or a remote desktop, and a locked screen still counts. The slot is deferred, not dropped: the run log says why, names the next attempt, and points at both ways out. Server and Datacenter are untouched and go on running signed out, across reboots, on Server Core.
  Two things deliberately still work on Solo with nobody there: backups you start yourself, and restore. Restore has never been gated by edition, expiry or anything else, and this does not change that.
  If the sessions cannot be read at all, LeoCore runs the backup. Being wrong in the direction of taking a backup costs us a licence sale; being wrong the other way costs somebody their data.
• leocore.exe is in the box. The command line has been finished, documented and listed on the pricing page since 4.9.0 — and shipped in no release, because it was missing from the publish step. It is now installed beside the console for Server and Datacenter: leocore status as a monitoring probe that exits 0 or 6 with no JSON to parse, plus run, restore, jobs and evidence. It needs no administrator rights, which is the whole reason it is a separate executable from the agent.

Installer — LeoCoreBackup-4.9.2-setup.exe, x64, self-contained (no runtime prerequisite). Includes LeoCore Rescue.

702FEDAE977B594D3006B8B9B9A06076A655D5811033DFCB2F185771C491717B

LeoCore Rescue — leocore-rescue-4.9.2-x64.exe, x64, standalone, free. Unchanged apart from its version number; a 4.9.0 copy opens 4.9.2 archives and always will.

3D851D6AED22E511C11269BAE50EDD8CA4AF839B3E8BEF4FBF01A4AD68FE2A05

Compact package — LeoCoreBackup-4.9.2.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime. Rescue is not in this package — it is always self-contained, which would take the download past the size the file host allows. Get it separately above.

D49C27E33E8CD61B48E746CBC9986C9072B9AAC71D70BF265663E6F1AB62307E

4.9.1 — 2 September 2026

• The estate view is a Datacenter feature. Reading it, that is — every edition goes on publishing its own status document beside its archives, and that distinction is the point rather than a detail. If a Server-licensed machine stopped publishing, a Datacenter console in a shop with eight of them would show an estate of one, and the only way to find out whether the view was worth anything would be to buy seven more licences first. So one Datacenter licence anywhere on that storage — including on the machine you are sitting at — shows you the whole estate immediately, with nothing to install on the others and nothing to enrol.
  Below Datacenter, The estate stays in the sidebar and says what it is, because somebody running four servers cannot decide whether it is worth paying for if they have never been told it exists.

Installer — LeoCoreBackup-4.9.1-setup.exe, x64, self-contained (no runtime prerequisite). Includes LeoCore Rescue.

7464330B1665094CA403996992ED5264334301FBA9113D7BAD4BECA18B41F5D1

LeoCore Rescue — leocore-rescue-4.9.1-x64.exe, x64, standalone, free. Unchanged from 4.9.0 apart from its version number; a 4.9.0 copy opens 4.9.1 archives and always will.

DE9D0D4FB5669460076E0D413BF5DADB30287D971058F134B2128B8CE95A2413

Compact package — LeoCoreBackup-4.9.1.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime. Rescue is not in this package — it is always self-contained, which would take the download past the size the file host allows. Get it separately above.

AD1F38243339C4C4279C22871408D90FA2823FEE664EF0E22839C7B402225246

4.9.0 — 2 September 2026

• Known-good restore points. LeoCore already recorded three separate facts about every archive: whether its own run verified it, whether a restore drill has since rebuilt that database, and whether the backup that produced it found the data destroyed. None of them reached the one screen where they decide something. The restore timeline is now marked with all three, every point carries a rating and the sentence behind it, and the point LeoCore would go back to is offered as a single action. In a ransomware recovery the difficult question is never how to restore — it is which copy is from before, and that is the copy this picks even when a newer one exists. It says so, too, rather than quietly choosing an older backup than the one you asked for.
  When nothing has been verified or drilled it recommends nothing at all. A confident default assembled out of no evidence would be worse than the plain timeline it replaces.
• A recovery kit beside every archive. Written to every destination after every run, under a folder named _leocore. It names each database, the archives that make up its current chain, the order they go back in, the SHA-256 of each, every destination holding a copy, and the restore commands for that engine — typed out in full, so they can be pasted rather than adapted. It is a single self-contained HTML file that references nothing external, because it is read on a machine that may have no internet and may be all that is left.
  It states plainly that it does not contain the archive password, and where to look for it instead. An encrypted backup stored next to its own password is an unencrypted backup with extra steps.
• LeoCore Rescue. One executable. It extracts an archive, checks one is intact, works out what is restorable in a folder of them with no catalogue at all, recovers the archive password from the machine that made the backups, and repairs archives written by 4.7.1 and earlier so other ZIP tools will open them. Self-contained: no installer, no service, and no .NET runtime to put on first, because the machine somebody reaches for it on is the machine least likely to have one.
  It is free and needs no licence, and it reads the archive format through the same code the product itself uses — so it cannot drift from the archives it claims to open. LeoCore can also copy it into your own storage beside the archives, so a recovery needs no internet, no download page and no vendor. Download it →
• The fleet view, with nothing hosted. Every machine writes a few kilobytes of status beside its archives — run outcomes, exposure, measured recovery time, next scheduled run, drill coverage. A LeoCore console pointed at the same storage reads every file it finds and shows the estate, under The estate in the sidebar.
  (Reading the estate became a Datacenter feature in 4.9.1, below. Publishing did not.)
  The usual way to build this is an aggregation service with per-machine enrolment. That introduces something to host, a new trust boundary and a consent flow — and "opt-in telemetry" is still telemetry to somebody who chose this product because nothing phones home. Every one of these customers already has storage several machines can reach, so LeoCore uses it. Nothing is hosted, nothing is enrolled, and nothing leaves storage you already own. It works over a plain file share, for a shop with no cloud at all.
  No credentials, no data, no log text, and no database names unless you switch them on — everything else in the document is a count, a date or a duration. A destination LeoCore cannot list says so by name rather than showing an empty estate, and a file that will not parse becomes a machine carrying a problem rather than vanishing from the list.
• Two backups in the same second no longer overwrite each other. Archive names are stamped to the second, so two runs of one database finishing inside the same second produced one file name — and the second archive replaced the first on the destination while the catalogue kept both. The older record then pointed at a file whose contents were something else, and restoring it failed its checksum comparison. The check was doing its job and that is no comfort: a restore point still being offered had quietly stopped being restorable. Names now take a suffix on an actual collision, and only then, so every ordinary archive keeps the name your own scripts expect.
• What LeoCore writes beside your archives is now a setting. Under Settings: the recovery kit and the fleet status document can each be switched off, database names in the fleet document are off by default, and copying Rescue itself to your destinations is off by default. Neither document contains a credential or any of your data, and neither is sent anywhere.

Installer — LeoCoreBackup-4.9.0-setup.exe, x64, self-contained (no runtime prerequisite). Includes LeoCore Rescue.

4B347F094008B38B531146D25E676926D85ED835D55E9D7214D77BEDC59517B4

LeoCore Rescue — leocore-rescue-4.9.0-x64.exe, x64, standalone, free

77B13838E67746DCA019487A605F99E543A5E54A8706FEC230751D7E4B908B1F

Compact package — LeoCoreBackup-4.9.0.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime. Rescue is not in this package — it is always self-contained, which would take the download past the size the file host allows. Get it separately above.

37A7402F5C0680840E73B842807119DCD3E8EB86CC8A0AD1569D3F99712F9B2E

4.8.1 — 1 September 2026

• Restores and drills use the job's staging path. Backups have always written through a staging folder that both LeoCore and SQL Server can reach, because SQL Server is the process that writes the file. Restores read through the agent's own temp folder instead, which works only when the two are the same machine and the SQL Server service account can read that folder. Anywhere else it surfaced as Operating system error 5, or as a path that does not exist on the server at all. The restored file now goes to the staging folder, in a subfolder named after the run, and is removed when the restore ends. If it cannot be removed, the run says so — it is a full copy of the database, and nothing else will clean it up.
• A licence upgrade reaches machines that are already running. The edition an installation enforces comes from the signed token it was given when it activated, so moving a licence between Server and Datacenter previously changed nothing until the customer re-entered their key. The weekly licence check now notices the difference and collects a replacement token by itself. The replacement is accepted only if it passes the same signature check as the original and names that machine — the edition is never taken from anything unsigned.

Installer — LeoCoreBackup-4.8.1-setup.exe, x64, self-contained (no runtime prerequisite)

C5C2355B321D97ACAAA6288BB96C73BBF236ED94A303C343557F82F4EBECCE05

Portable package — LeoCoreBackup-4.8.1.0-x64-portable.zip, x64, self-contained

C68CD510FD87E08E37D32AF3C5F19B2685C512770611FA2825FFBA519ADC3D7C

Compact package — LeoCoreBackup-4.8.1.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime

6E69710FF2BC0EF87DC10D97047D3A9E9A188D43AB50EEFB18C0A75F9F462862

4.8.0 — 1 September 2026

• SQL Server Express and Web editions can be backed up. Neither supports backup compression, and LeoCore requested it unconditionally, so every run against them failed at the first database. Nothing is lost by leaving it out: the file SQL Server writes is a staging file that LeoCore compresses into its own encrypted archive seconds later, and the archive is the same size either way. Express is the free edition, so this was worst exactly where it was least likely to be noticed.
• How much data is at risk, and how long recovery takes. Two figures on the dashboard, both measured rather than assumed. Data at risk is the age of the newest stored archive, not what the schedule intended — a job set to run hourly whose last archive is four days old reports four days. Time to recover comes only from a drill that actually restored the database, carrying the size and date it was measured on. These are the two numbers every framework asks for as RPO and RTO, and the usual answer is a target copied out of a policy document. The evidence pack now states them as observations, under a control row of their own.
• Restore drills cover the whole job. A drill used to restore the first database in the job, every time. A job with twelve databases proved one of them repeatedly while eleven were never restored by anything — and the evidence pack showed drill history for the job, which read as coverage it did not have. Drills now rotate, least-recently-tested first, and coverage is reported honestly as 9 of 12 proven. A database whose last drill failed is reported separately from one that has never been tried, because those need different things done about them.
• Databases nobody is protecting. A database created after a job was set up is backed up by nothing, and no run ever fails to tell you — the job succeeds, because it is doing exactly what it was asked. LeoCore now compares what the server reports against every job's selection and names what is covered by none of them. The server's own databases are never counted: tempdb cannot be backed up by anyone, and an alarm with no available remedy only teaches people to stop reading the alarms. There is an optional per-job setting to adopt new databases automatically, off by default.
• A readiness check, in daylight. Everything a backup depends on rots silently and is discovered the same way: a failed run at 02:00. A password expires, permissions are tightened, a destination fills up, an upgrade moves a tool. Once a day, during working hours, LeoCore now makes the same round trip a real backup makes — connects as the account that does the backing up, asks which databases it may actually back up, and writes, reads back and deletes a file at every destination. A revoked permission found at 01:55 is the same outage; found at 14:00 it is a five-minute fix. Free space is reported as nights remaining, from the median of recent runs.
• A restore that SQL Server cannot read now explains itself. SQL Server, not LeoCore, is the process that opens the backup file, and they are different accounts — on a remote server, different machines. That failure used to arrive as Operating system error 5 and nothing else, during a recovery. It now names the account SQL Server is running as, the folder it could not read, and what to do about it.
• The connection test reports who the server saw. Previously SQL Server only. MySQL and PostgreSQL now report the account the server actually matched, which is not always the one that was typed — backup@% where somebody believed they were using backup@10.0.0.5 is exactly the difference that decides whether a backup is permitted.

Your existing jobs, history, schedules and archives are carried forward untouched. This release adds tables to the LeoCore database for drill coverage and readiness results; as with every schema change, a snapshot is written to %ProgramData%\LeoCore\Backups before anything is altered.

Installer — LeoCoreBackup-4.8.0-setup.exe, x64, self-contained (no runtime prerequisite)

0E735513ED89445730D3D9AEB89691A2454DED680E6FE1C9794FDCF087C1A664

Portable package — LeoCoreBackup-4.8.0.0-x64-portable.zip, x64, self-contained

E891EFEEEB639F8350D10222ACB69E21ACAB86DEB3ED75DF87E00350E2EA2F6B

Compact package — LeoCoreBackup-4.8.0.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime

43A8754460E3E89DF0D620BB8BA4096A2053AEB045BEEB8A86A6361C08EDE907

4.7.6 — 1 September 2026

• Recover one table instead of two hundred gigabytes. Somebody dropped a table, or ran an UPDATE without a WHERE. The data needed is a few megabytes, and SQL Server has no native single-table restore — so the only supported route is restoring the entire backup into a scratch database and copying the table across by hand. Hours of work and a lot of free disk, for a mistake that took two seconds.
  LeoCore already restored into a scratch database, validated it and dropped it again, on a schedule, for every restore drill. Recover a table… on the job page is that same proven machinery with a table picker in front of it. The scratch copy is named after the run that created it, so nothing is ever dropped that LeoCore did not just create, and it is removed whatever happens — including when you press Stop half way through.
• You choose where the rows land. By default they arrive as a new table beside the original — Invoices_recovered — because somebody recovering a table is usually acting on a mistake made minutes ago, and overwriting the live table is a second irreversible act layered on the first. Put the rows back is there when you want it, and a table that was dropped outright is simply recreated under its own name.
• It refuses the recoveries that would quietly do damage. A table whose foreign keys cascade on delete is not emptied and refilled, because emptying it would take rows out of other tables with it. Landing a recovered copy on top of a table that already exists is refused rather than merged. Identity columns, computed columns and rowversion are each handled as the engine requires, and a table whose columns have changed since the backup is copied on the columns the two have in common, with the rest named in the run log. Every refusal says which table and why, and the other tables in the same request still go ahead.
• The table list comes from the backup, not from the server. The table you want back is very often one the live server no longer has, so a picker built from the server would be missing exactly the thing you came for. LeoCore reads the list recorded by the backup itself and marks anything that is no longer on the server. Backups taken before 4.7.0 recorded no such list; for those the dialog falls back to the live server, says so, and invites you to type the name instead.
• Restores no longer count as backups. A fix worth stating plainly, because it hid a real alarm. Restores and restore drills are recorded against the job they belong to, which is where you look for them — but the dashboard decides whether a job has gone days without a backup by looking at its newest successful run. A restore done on Friday therefore silenced the warning for a job whose last real backup was a fortnight earlier: the exact failure that warning exists to catch, hidden by the act of recovering from it. Restores, drills and table recoveries are now excluded from the success rate, the activity chart, the protected-data figure and the staleness alarm.
• A network share that cannot be found now says which half is missing. Windows reports the same error whether the server could not be found or the share on it could not, and the two need completely different fixes. The destination test now checks whether the machine name resolves from this computer and says which case it is — and, if the name does not resolve at all, says that this is not a permissions problem and that there is nothing at that address to ask. Anyone looking at that message has usually just opened the same share in Explorer on a different computer and concluded the product is wrong; the backup runs from this machine, as the service account, and that is the only place the question means anything.

Table recovery is SQL Server only. Moving the rows out of the restored copy is a cross-database query, which needs both databases reachable from one connection — Azure SQL Database cannot do that at all, and the other engines have no equivalent path. Rather than offer a button that fails at the end of a long restore, each of them says what to do instead: restore the backup as a new database and copy the table across from there.

Installer — LeoCoreBackup-4.7.6-setup.exe, x64, self-contained (no runtime prerequisite)

B941087B2BEA30F4D8C364E8A0F905FCB96C21E55CEE0FDC152845888B061F89

Portable package — LeoCoreBackup-4.7.6.0-x64-portable.zip, x64, self-contained

FE9985A6F8EA24FEF59432FD37DFE8DEAF9D890B0BCE9BEEEF1430EDEF5C2FAF

Compact package — LeoCoreBackup-4.7.6.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime

1484F8FD68C47957F8189FD9788697865BD850A205B713EFF3F80D9918F86614

4.7.5 — 17 August 2026

• A destination that cannot be reached no longer cancels the backup. Destinations are opened before any database is dumped — deliberately, so a bad credential is found before an hour is spent on a large database. But the first failure ended the run, so a NAS switched off for the weekend or a share password that expired overnight meant no backup was taken anywhere, including the destinations that were working perfectly.
  That inverted the whole point of having more than one: adding a third destination made the job more likely to fail. Each is now opened on its own, the run continues with the ones that answered, and nothing is written to or deleted from the one that did not.
• One problem database no longer abandons the rest. A job covering twelve databases that hit a locked file, a database in RECOVERY, or a dump that ran out of disk on the third one backed up two and skipped nine — nine databases left unprotected by a fault in a different one. Every database is now attempted.
• The report email names which databases succeeded and which failed. Every database in the run is listed with its outcome, its size and how many destinations stored it. The subject line names the ones that were missed, because "BACKUP FAILED" across twelve databases does not tell you which one now has no recent copy.
  A partial failure no longer reads like a total one — it will not tell you no restore point was produced when eleven of twelve have a fresh, verified copy.
• A backup stored nowhere is now reported as a failure. If every destination refused the archive, the run finished with warnings rather than failing: each failure was counted, but nothing asked whether any had succeeded. An archive that was built, verified and then discarded is a failure.
• Fewer copies than you asked for is always visible. A run that reached two of three destinations says so in the run log, the history row, the tray notification and the report email — and still sends the failure email, so a quietly degrading destination cannot go unnoticed for months.

Runs that are missing a database or a destination are still marked failed or warned — nothing here makes a problem quieter. What changed is that the work that can be done now is.

Installer — LeoCoreBackup-4.7.5-setup.exe, x64, self-contained (no runtime prerequisite)

CF1673578246F681FCACBE685D74FE7943831E1C303F62F8DA28F90326A896A4

Portable package — LeoCoreBackup-4.7.5.0-x64-portable.zip, x64, self-contained

F76AEBDD63E240DB3564BEBE045B8FA1BDDB17E34E09517E8861A1D220A32F03

Compact package — LeoCoreBackup-4.7.5.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime

E8C13E931AB4604E76A1E7183595425958AEF07F96B47F0BEE8866F2D4ABCA93

4.7.4 — 17 August 2026

• Dialogs stay on the screen. The window is now checked against the work area of the monitor it is actually on and moved up when it does not fit. The height limit had been right all along — the position was not. Windows centres a dialog on its owner, and a maximised window is larger than the screen in every direction, so half of that overhang put the buttons below the bottom edge.
  The measurement now also asks which monitor and at what scale. It previously assumed the primary monitor at the system scaling, which is wrong on a second screen of a different size and wrong again on a display at 125% or 150%.
• Long dialogs scroll, and their buttons do not. Add destination, Verification & restore drill, Advanced backup schedule and Select databases now keep Cancel and Save pinned at the bottom while the form between them scrolls. Confirming a dialog no longer depends on how much room your screen happens to have.
• The destination picker is one row shorter. The window is wider, so the thirteen destination types fit five to a row instead of four — less to scroll past before reaching the fields.
• Emails no longer invite a reply that would go nowhere. The footer said "Reply to this email or write to support@…", but every message is sent from a no-reply address. It now points at support@seksolution.com only. The failed-payment email said the same thing and had the same problem.

Installer — LeoCoreBackup-4.7.4-setup.exe, x64, self-contained (no runtime prerequisite)

B8123898E3E91912A974F45FEAAEAC583930189872FEBC0FC532B73246B2C04F

Portable package — LeoCoreBackup-4.7.4.0-x64-portable.zip, x64, self-contained

A96800302565A7FB0C9232313B0D8A6FEC30D5B3D513D4A1CABF24649ACAD1FB

Compact package — LeoCoreBackup-4.7.4.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime

F6D2E67DCF8F341B3C31867F09C76620D91AC8C1E6ECF0A40E4FB2B9848C5CCD

4.7.3 — 17 August 2026

• Test connection, on every destination. Add destination has a Test connection button, and every destination already saved has a Test link beside it on the job screen.
  It is not a reachability check. LeoCore writes a small file to the destination, reads it back, compares it byte for byte and deletes it again — the same four things a backup needs. A share can be listed by an account that cannot write to it, an S3 prefix can be readable and not writable, and an FTP login can succeed against a full disk. All three pass a "can we see it" check and fail the first real backup.
  The reading-back matters as much as the writing. A destination that accepts a file and hands back something different — a failing disk, a quota, antivirus or a sync client rewriting it in place — would otherwise produce archives that restore to nothing, and nothing later in the process would notice.
• The test runs as the backup service, not as you. This is the point of it. Backups are uploaded by NT AUTHORITY\SYSTEM, which on the network is the computer account — not the person signed in at the keyboard. A UNC path you can open in Explorer is routinely refused to it. A test performed by the console would confirm your rights and tell you nothing about the ones that matter, so the console asks the service to do it and reports which account the destination actually saw.
• Failures say what is wrong, not "could not connect". Windows distinguishes a rejected password from a valid account with no write permission from a share that does not exist — three different jobs for whoever has to fix it. Each now gets its own explanation. When no credentials were supplied, the test says plainly that the share was approached as the computer account, which is the single thing that catches people out.
• A share that Windows silently connects under someone else's credentials is now reported. Asked for a second session to a server it already has one to, Windows reuses the existing session rather than opening a new one — so the user name and password you typed were never used. It works now and fails later, once that other session has gone. LeoCore warns when this happens and tells you how to clear it.
• A new job no longer tries to back anything up before you have set it up. Clicking New backup job created a job with a schedule, no databases and nowhere to put them — and the scheduler then ran it and recorded a failure saying "No databases are selected", about a job you were still in the middle of creating. A job is now simply not due until it has a server, at least one database and one destination. The job screen shows the missing piece where the next run time goes, and the dashboard raises one ordinary note instead of three critical alerts.
  A job that had been running and has since had its databases or destination removed is still treated as critical — that one is a real gap in protection.
• The Add destination window no longer outgrows the screen. With Amazon S3 selected and a test result showing, the Add destination button could be pushed below the bottom of a laptop display. The form scrolls now and the buttons stay put.

Installer — LeoCoreBackup-4.7.3-setup.exe, x64, self-contained (no runtime prerequisite)

31575295E992CB838E479589151591B7EE10121572C8FF4C2A3E845D65078C14

Portable package — LeoCoreBackup-4.7.3.0-x64-portable.zip, x64, self-contained

E1BD76079CB91BE88CEAE0F7D4756A91BA7BB7F16F884E4CD8E85B4BAF0CC9F6

Compact package — LeoCoreBackup-4.7.3.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime

6745FABE17BE68C9DC6EF4FAE6A9FB2C5AC34B79A438ECF080302E3DF1EA6903

4.7.2 — 16 August 2026

• Encrypted archives are now readable by other ZIP tools. A ZIP entry declares that it is encrypted by setting bit 0 of its general purpose bit flag. LeoCore was not setting it. Everything else was correct — AES-256, WinZip AE-2, the right compression method, valid checksums — but without that bit 7-Zip, WinRAR and Windows File Explorer do not know to ask for a password. They try to decompress the encrypted bytes as though they were ordinary compressed data, and report the archive as corrupt.
  Nothing was lost and nothing was at risk. LeoCore itself decides an entry is encrypted from the compression method rather than that bit, so every archive verified, restored and round-tripped correctly through the product — which is exactly why this went unnoticed. The problem only appeared when somebody opened an archive with something other than LeoCore.
  Archives written by 4.7.2 onwards open normally in any AES-capable ZIP tool.
• Existing archives can be repaired without re-running a backup. Repair-ArchiveFlags.ps1 sets the missing flag on archives you already hold. It changes two bytes per entry and touches nothing else — not the encrypted data, not the checksums, not the names or dates — and writes a repaired copy beside the original rather than overwriting it. Point it at a file or a whole folder.
• The archive password can now be exported. Settings → Export the archive password previously explained that it would not do that. Archives are encrypted with a password generated on first use and bound to the machine that made it, so an archive plus a dead server meant nothing recoverable by anyone — including us. It now writes a recovery sheet you can keep off the machine, with instructions for opening an archive without LeoCore. Do this once, today.
  For a machine you cannot update yet, Get-ArchivePassword.ps1 recovers the same password. Run it as administrator on the machine that made the backups.
• LeoCore now reminds you to save your archive password. Encryption stays on by default. The password is generated automatically and stored on the machine being backed up — so until a copy of it exists somewhere else, the backups and the only key to them share a single point of failure, and it is the same machine the backups exist to survive.
  The dashboard raises this until you have saved it, and Settings → Show the archive password writes a recovery sheet with the password and instructions for opening an archive without LeoCore. Do it once, keep it in a password manager or on paper somewhere else, and the reminder stops.
• Encryption can now be turned off, per installation. A copy that never leaves a volume you already control gains nothing from a password and loses the ability to be opened by whoever is on shift. Switch it off in Settings and archives are plain Zip64 that opens in Windows File Explorer or anything else.
  If you do, LeoCore asks again the moment you add a destination that sends copies off the machine — S3, Azure, Dropbox, Google Drive, OneDrive, Box, Backblaze, FTP — because that is the point at which the decision changes. A local folder or network share raises nothing, and the dashboard flags any job uploading unencrypted copies off the machine.
• You can now set your own archive password. Settings → AES-256 encryption offers a password you choose or one LeoCore generates. There was previously no way to set your own at all.
• Emails now point at support@seksolution.com, matching the rest of the site, and the header band is light so the logo is visible.

Opening a backup without LeoCore

Every archive is a standard Zip64 container, so your backups are readable whether or not LeoCore is installed — on any machine, years from now.

• Encrypted (the default) — see below.
• Not encrypted, if you have turned encryption off — open it with anything, including Windows File Explorer. Inside is the dump exactly as the database engine produced it: .bak for SQL Server, .sql for MySQL and PostgreSQL, .fbk for Firebird, plus server-objects.sql when that option is on.

For an encrypted archive you need 7-Zip or WinRAR and the password. Windows File Explorer cannot open AES-encrypted ZIPs at all and will call the archive invalid however correct it is.

7z x "sales_20260816_full.zip" -p"<password>"

To find the password: open Settings → Show the archive password. It writes a recovery sheet with the password and these instructions on it. Keep it somewhere other than the machine that made the backups — the password is bound to that machine, so if it is lost with the machine, the archives cannot be opened by anyone, including us.

On a machine you cannot update yet, Get-ArchivePassword.ps1 recovers the same password. Run it as administrator on the machine that made the backups.

Installer — LeoCoreBackup-4.7.2-setup.exe, x64, self-contained (no runtime prerequisite)

5FC0677F48EF21F5FC4566C149B131A08099D2337C0AAEF6F04173B2BAF7FA7F

Portable package — LeoCoreBackup-4.7.2.0-x64-portable.zip, x64, self-contained

6ABF7DAC766B0F647BF391C3E9F06BECC2656CD2CAED8FB4B68B42FCA038CD44

Compact package — LeoCoreBackup-4.7.2.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime

41B377CD45376AE5FD441D8C7CB28DBB7BD774D01911C2BC3A3CA6B6F60957B8

4.7.1 — 16 August 2026

• In-place updates could not start. LeoCore updates itself by running a small separate program, because a running application cannot overwrite its own files. That program was copied to a temporary folder as four files — and a self-contained build, which is what the installer produces, also needs the .NET runtime beside it. It exited immediately with "the library hostpolicy.dll could not be found", before any LeoCore code ran, so nothing was written to any log.
  What you saw: a console window appear and disappear, the application close itself to be replaced, and the old version still installed afterwards. No files were changed and no data was touched — the update never got as far as starting.
  The updater now runs from inside the downloaded package, which already contains it alongside the complete runtime. There is no longer a list of files to keep in step with what the runtime requires, which was the actual defect.
  Installations that use the shared .NET runtime — the compact package — were never affected, which is why this went unnoticed.
• A failed update no longer closes its own window. Every failure now waits to be read. A window that vanishes tells you nothing, and made a broken update look identical to a successful one until you checked the version.
• An incomplete download is caught before the application closes. The package is checked for the updater first, so a problem is a message rather than a machine with nothing running on it.

Installer — LeoCoreBackup-4.7.1-setup.exe, x64, self-contained (no runtime prerequisite)

2AC2769C0D7531ACBC0B448425896BE2F8DDC7C86FDB65D6F31BF243291099EE

Portable package — LeoCoreBackup-4.7.1.0-x64-portable.zip, x64, self-contained

B327A8D1BC3E24CBC4CE4B7610D5158F647A9583BE78031BF13D8C8E32DFC614

Compact package — LeoCoreBackup-4.7.1.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime

9BEF83A2DAC77F5CDD038E62417BDB823D0BA00E9D717AC3200CD81B937F3F9C

4.7.0 — 16 August 2026

• Mass-change detection. Every backup records what the database looked like — which tables exist and how many rows each holds — and compares it with the previous backup. A table that is now empty, a table that has disappeared, or a table that has lost most of its rows is reported on the dashboard, in the run log and in the report email, naming the table and both row counts.
  This is the failure every other part of a backup product is blind to. The archive is valid, verification passes, the upload succeeds — and the backup faithfully preserves a database that lost a table overnight. The good copy then ages out on the retention schedule while nobody is looking.
  So the copy taken before the change is held back from retention automatically. That is the point of the feature: an alert nobody reads changes nothing, but an archive that cannot be deleted is still there a fortnight later. It shows the reason it was kept, and it stays until you release it.
  It catches the ransomware case from the same signal: data encrypted in place stops compressing, so a database that always squashed to 15% suddenly sitting near 100% is reported. Row counts and compressibility rather than file entropy — every LeoCore archive is compressed and AES-256 encrypted, so an entropy check would flag every healthy backup it ever took.
  Deliberately quiet. Ordinary growth, routine churn, a new table and small lookup tables report nothing, because a warning that fires on a normal night is one people learn to dismiss. MySQL and MariaDB report InnoDB row counts as an estimate that drifts by tens of percent on its own, so estimated counts are held to a much higher bar than exact ones — except zero, which no engine estimates for a table that has rows, so a truncation is caught either way. A database's first backup reports nothing, because there is nothing yet to compare it with.
  No configuration, and it costs one query against statistics the database engine already maintains — no table scans, and nothing measurable added to a backup window.
• Server-level objects can be captured with the databases. SQL Server only. Logins with their SIDs, server role membership, linked servers and Agent jobs are scripted into server-objects.sql inside the archive, beside the databases they belong with. A database restored without them comes back with orphaned users, no scheduled jobs and no linked servers — intact data that nobody can sign in to.
  Off by default, because reading login password hashes needs more rights than a backup otherwise needs, and a feature that quietly wants CONTROL SERVER should be asked for rather than assumed. Whatever could not be read is listed in the run log rather than silently omitted, so a half-captured script is never mistaken for a complete one. LeoCore never runs the script — it is for a database administrator to read and apply during a rebuild.
• MySQL and MariaDB tools are found where they actually are. When mysqldump was not on the PATH the backup failed rather than looking for it, and where several installations existed the newest was chosen even when the running service was an older one — which produced a dump that server could not restore. LeoCore now prefers the installation belonging to the service that is actually running.

Installer — LeoCoreBackup-4.7.0-setup.exe, x64, self-contained (no runtime prerequisite)

31D9ABB862F634A43CF333704D3B6F80ECD3BB3E108233945C59D33EEAC8343A

Portable package — LeoCoreBackup-4.7.0.0-x64-portable.zip, x64, self-contained

C076A0BDD965C9B62A42168B199A137159F7C2DAC5FBBE671D68F5DB7F3A0845

Compact package — LeoCoreBackup-4.7.0.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime

06E77AE406C2C0DC8E41002DD1C80FA10CB718500834FF1D0B1FFE1B7126E4CE

4.6.1 — 16 August 2026

• Setup checks whether it can actually back a database up, not just see it. Connecting to SQL Server and listing databases needs no rights over the data — the server shows every database name to every login — so a connection test could report “5 databases found” and every backup then fail. LeoCore now asks the server, for each database, whether the account the backup service runs as may run BACKUP DATABASE against it.
  Databases it cannot back up are marked in red in the picker, the result line names the account the server actually saw, and a panel offers to copy the exact SQL that grants the right. That script asks for db_backupoperator and nothing wider — the least privilege that permits a backup, granting no access to the data itself.
  Granting it needs a SQL administrator. LeoCore cannot grant it to itself and should not be able to: a backup service that can widen its own rights inside the database it protects is a worse problem than the one it solves.
• Every third-party licence now ships with the product. The licence agreement has always said the complete list and licence texts are installed with LeoCore and published here. They now are: THIRD-PARTY-NOTICES.txt sits beside the application in every package, and the list is at /docs/third-party/. It covers 163 components and is regenerated from the packages on every build, so it cannot drift.
• A migration snapshot is written beside the database it belongs to. No change on an installed system, where that is the same folder as before.

Installer — LeoCoreBackup-4.6.1-setup.exe, x64, self-contained (no runtime prerequisite)

86595F3E7E61B729F75B5C560A90DE7EAFB330C505324836341B6EAC0767EFEC

Portable package — LeoCoreBackup-4.6.1.0-x64-portable.zip, x64, self-contained

03B2E274C6EC66D8C8B23244A3029D4AAE592CF111BFE2DE68D801C1506F393B

Compact package — LeoCoreBackup-4.6.1.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime

5B6A4B0EF3D57D14BBB1CB3EBB89FB332F8528161072047939CEB15168E6354E

4.6.0 — 16 August 2026

• Evidence report. Dashboard → Evidence report writes a self-contained HTML document covering the last 90 days: backup runs, restores tested, data written, and every exception. It opens on any machine, prints to PDF from any browser, and references nothing external, so it renders the same years from now.
  It carries six control requirements — backups taken, restoration tested, protection against unauthorised access, copies held away from the protected system, protection against deletion, and retention — each marked met, partial or not met, with the evidence quoted beneath it and the framework clauses that ask for it.
  Two rules govern it. Nothing is asserted: every status is derived from records, and a requirement with no evidence behind it reads not met rather than blank. Failures stay in: failed drills, stale databases, unencrypted copies and jobs that never test their restores are listed in full, because a report showing only successes tells an assessor nothing except that it was filtered.
  It states plainly that it is not a certificate of compliance. It is the underlying evidence an assessor examines.
• Restore drills are now recorded as drills. They were previously identified only by the words “restore drill” appearing in a display field — reword that and the proof of recoverability silently stopped counting. Drills recorded by earlier versions are still recognised, so no existing testing history is lost.

Installer — LeoCoreBackup-4.6.0-setup.exe, x64, self-contained (no runtime prerequisite)

E0FE1C1F2727F5BAB04549C1D3D7097AE500F3C476CAB27A029CC2AC494183F8

Portable package — LeoCoreBackup-4.6.0.0-x64-portable.zip, x64, self-contained

830BA8BFF51EAA0B7207737114730BD2DD443E3EA137E57F913EE46B827E3E45

Compact package — LeoCoreBackup-4.6.0.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime

CF6B6DD15C176365E85E47109CD4BF3787BACCC53F80D6D203C770C68149BEED

4.5.1 — 16 August 2026

• Upgrading no longer stalls on “unable to close all applications”. The backup agent runs as a Windows service, and setup replaces the files it is running from. Setup asks Windows to close whatever holds those files, but that mechanism closes ordinary application windows and does not reliably stop a service — so the upgrade stopped and offered three choices, all of them bad: retrying failed the same way, ignoring the error left old and new files mixed in one installation, and cancelling abandoned the update.
  Setup now stops the agent service itself before replacing any file, and waits until it has actually stopped rather than assuming it did. It is started again at the end, as before. Your backups, schedules, credentials and history are untouched throughout.
  The uninstaller had always stopped the service before removing it. The installer not doing the same before replacing it is what caused this.

Installer — LeoCoreBackup-4.5.1-setup.exe, x64, self-contained (no runtime prerequisite)

962C2C65B4209F575FFE5F2AAEF307DE5070179116351753D4EE940EF5652C4E

Portable package — LeoCoreBackup-4.5.1.0-x64-portable.zip, x64, self-contained

1F0D811061A5C21F08EB49EF3057A56A6136433649E149D69EBD7481C4790E01

Compact package — LeoCoreBackup-4.5.1.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime

AA394896DBFFC23A17992505538A328160A945573C777558D5DBBAFE417932D6

4.5.0 — 16 August 2026

• LeoCore now opens on a dashboard. One screen for every job: what is protected and how much of it, the success rate over the last fortnight, when the next backup runs, a fourteen-day activity chart, and the most recent runs across all jobs.
  The part worth reading is Needs attention. It does not list totals — it lists the specific ways a backup can be quietly protecting nothing: a job with no databases selected, a job with nowhere to store its archives, one that has never run, one whose last run failed, one with no successful backup for three days, and one whose restore drill failed. Each says what to do about it, and opens the job it belongs to when clicked.
  The stale-backup check is measured against actual runs, not the schedule, because a schedule that silently never fires is exactly the failure it exists to catch.
• “Download and install” works again. The console asked the download server for the installer without identifying itself, and the server refuses anonymous requests — so the update check correctly reported a new version and the download then failed with 403. Every request LeoCore makes now identifies itself, and the download address has been corrected on our side so that existing 4.4.2 and 4.4.3 installations are fixed without needing this update first.
  The same omission was present in licence activation and the weekly update check. Both are fixed here, and a build-time check now fails the build if any part of the product makes an unidentified request.
• Clearer messages when a download fails. A failed update said “Response status code does not indicate success”, which tells you nothing at the moment you most need to know something. It now names the problem and points at the manual download.

Installer — LeoCoreBackup-4.5.0-setup.exe, x64, self-contained (no runtime prerequisite)

6FFA19A82324A0EC09D2FA64A046A96CE0BEAE2DC44DC4F98991292F0759DC93

Portable package — LeoCoreBackup-4.5.0.0-x64-portable.zip, x64, self-contained

E28CD20151CC868EC7C81D67987684AF7E4B3BED9FB5AFDAA4C76C765B350947

Compact package — LeoCoreBackup-4.5.0.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime

EC54EEC387A72B2F09163744C8EAF9767305A6B871F27B651BBE208443F65247

4.4.3 — 15 August 2026

• The Connect dialog no longer crashes when SQL Server instances are found. It shows one clickable chip per detected instance so you can fill the server box without typing it. Those chips are buttons, but they were styled with a style that targets a radio button, and WPF rejects that outright — so the dialog died at the moment it tried to be helpful. The chips now use a matching button style.
  Why it took until now to surface: the code only runs when an instance is actually found, so it could never fire on a machine without SQL Server installed.
• Every password field has a show/hide button. Database passwords, SSH passphrases, destination secrets, OAuth client secrets and SMTP passwords. A mistyped credential is otherwise not discovered until a backup fails that night. Revealed text is hidden again automatically when the window loses focus, so a password is not left on screen on an unattended server.
• A build-time check now catches this class of crash. Styles applied from code are verified against the control they are applied to, so a mismatch fails the build rather than reaching a customer's server.

Installer — LeoCoreBackup-4.4.3-setup.exe, x64, self-contained (no runtime prerequisite)

B535A86E2222871E749E16FA0F8C221289BAD108A7AC19F05699FC5A0861958D

Portable package — LeoCoreBackup-4.4.3.0-x64-portable.zip, x64, self-contained

40D707403812DB6B0B454562377182A3C68B29DBA98C89CDBC56E8A32D0F62E1

Compact package — LeoCoreBackup-4.4.3.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime

347B84C328116702745653D5723B1E9AC902966F6438BE8AC1F61CC90285C9AF

4.4.2 — 14 August 2026

• Updates install themselves. Previously the console could only replace its own program files when it was already running as an administrator, which almost never happens: a normal install lives in Program Files and the console runs as you. Everyone else was told to download the new version manually and left to find this page. The console now downloads the signed installer and runs it, and Windows asks for approval at that point. Declining the prompt cancels cleanly and changes nothing.
• There is a Dashboard button in the sidebar. History and Settings each had one; the dashboard did not, so the only way back to it was clicking a job in the list. With no job selected — or before the first job exists — there was no way out of Settings at all except closing the window.
• The dashboard says something useful when no job is selected. It showed its full layout wrapped around an empty job: a blank title, dashes in every card and a Run now button that did nothing.
• The Firebird "add a database" row is laid out properly. The browse button was pinned narrower than its own padding, so its label had no room and it rendered as an empty box wedged against Add — which read as two buttons overlapping. The path box now gets the full width of the pane, which matters when what goes in it is a full Windows path, and both buttons carry a readable label.

Two notes on the update change. The published release description now names the installer alongside the ZIP packages, and the application refuses to run anything whose SHA-256 does not match what that signed description promised — the same rule that has always governed the ZIPs. And the installer is still unsigned, so Windows will describe the publisher as unknown; that is unchanged from downloading it here by hand.

Installer — LeoCoreBackup-4.4.2-setup.exe, x64, self-contained (no runtime prerequisite)

B0155BF4FC506FF9D4BFA700C95844BFD693B673AD63DC7E933626EE47F76A4D

Portable package — LeoCoreBackup-4.4.2.0-x64-portable.zip, x64, self-contained

131942B7D157261B86E27620C53CA4260331E5DA6AB89FD10F8FB8FBFAFB3855

Compact package — LeoCoreBackup-4.4.2.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime

B150FA7C4CDC1AF02B49F2DB5BBC44220DE3B7C8D94D5295D207CA3F5EDA2C3D

4.4.1 — 14 August 2026

• Granting console access works for accounts with a space in the name. The message shown when the console cannot reach the service printed a command without quotes, so LeoCore.Agent.exe grant DELL-SERVER\DELL SERVER was read as two arguments and granted access to an account that does not exist — reporting success while the console stayed locked out. The command is now quoted, and grant also accepts an unquoted name rather than silently using only the first word.
• The message now says which problem you actually have. It reads local group membership directly instead of assuming, so it can tell three situations apart: your account is already a member and only needs a fresh sign-in; the group was never created; or the account genuinely needs adding. Previously all three produced the same instructions, and the most common one — already a member, Windows just has not noticed yet — was the one those instructions did not solve.
• grant checks its own work. It reads membership back afterwards instead of trusting the exit code, and says so if the account did not end up in the group.

Why a fresh sign-in is needed at all: Windows records group membership in your logon token when you sign in and never refreshes it. An account added to a group is not treated as a member until it signs out and back in. Locking and unlocking does not count.

Installer — LeoCoreBackup-4.4.1-setup.exe, x64, self-contained (no runtime prerequisite)

12BEF78715007119EC65663372A9A4F03A48965615A4AD796B0F7B5AB79B725D

Portable package — LeoCoreBackup-4.4.1.0-x64-portable.zip, x64, self-contained

6E1115C16008D55196D310DF223C9D826898C9C3567B0B796AA722FF53899833

Compact package — LeoCoreBackup-4.4.1.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime

844C94C1010664B5AF24F49EE524A4A62713E46F22015A30D01C574A4032020A

4.4.0 — 14 August 2026

• Firebird databases can now be backed up. Firebird 2.5, 3.0, 4.0 and 5.0, on every edition including the free one — no separate licence tier. Backups use Firebird's own gbak through the Services API and are streamed straight to the machine running LeoCore, so nothing is written on the database server and no file share is needed. Nothing has to be installed alongside Firebird.
• Your application keeps running during a backup. gbak takes a snapshot, so no exclusive access is needed and nobody is locked out. Only restoring over an existing database requires exclusive access, and LeoCore says so plainly if something is still connected.
• Firebird databases are added by path. Firebird has no way to list the databases on a server — a database is a file, and the server only learns about one when something connects to it. So each database is added by its file path, for example C:\Data\ACME.FDB, or by an alias from databases.conf. LeoCore suggests whatever it can find and lets you add the rest.
• Full backups only on Firebird. Firebird's incremental mechanism produces a physical page image that cannot be restored on top of a gbak dump, and Firebird has no transaction-log backup at all. A scheduled differential takes a full backup instead and says why, rather than silently skipping the run.
• Security fix in a dependency. The SSH library is now pinned to SSH.NET 2026.0.0, which fixes GHSA-q939-rpr3-3284 — a high-severity arbitrary file write through server-controlled SCP filenames. LeoCore never used the affected component, but the version carrying it is gone rather than merely unused.

Installer — LeoCoreBackup-4.4.0-setup.exe, x64, self-contained (no runtime prerequisite)

AB9C8D95555EF2B82050FBA0623AA3B88498937A3F99F273111CA86B12B4FCFE

Portable package — LeoCoreBackup-4.4.0.0-x64-portable.zip, x64, self-contained

FC65F4EFD55F7278111E42CCB6ADD5E335853F1F393F174B4A04A8B22BECACC2

Compact package — LeoCoreBackup-4.4.0.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime

239C816312E9D06A7496F568EEB8A0853FDCC2AF628C0DA4B9183FB4B28EED61

4.3.3 — 14 August 2026

• Restore works again. In 4.3.2 the restore window failed to open from anywhere — the job screen, the history table and Point-in-time recovery alike — and reported only "Object reference not set to an instance of an object". A radio button marked as selected in the window's own layout fired its handler while the window was still being built, before the field it writes to existed. Nothing was wrong with your backups or the archives themselves; the window simply could not be shown. There is now an automated check that fails the build if this pattern is reintroduced anywhere in the application.
• When email cannot be sent, LeoCore now explains what to do about it. If a run report cannot go out through LeoCore's email service, the message says which of the possible causes it was — this server cannot reach the service, the credential was refused, an hourly send limit was reached, or the service itself is faulting — and, where switching would genuinely fix it, makes the case for sending through your own mail server instead. A mistyped recipient address is reported as exactly that and does not suggest reconfiguring anything, because your own server would reject it too.
• Switching to your own mail server is now one click from the failure. Sending a test that fails offers to set it up and takes you straight to the fields.
• A single network blip no longer produces advice to reconfigure your mail infrastructure — transient failures are reported plainly and only argue the case once they repeat.

Installer — LeoCoreBackup-4.3.3-setup.exe, x64, self-contained (no runtime prerequisite)

B68481A3E8DB98D8E038EFBFDC33688E1B4CD6CDFBFD63E079A2DCEB90FD156D

Portable package — LeoCoreBackup-4.3.3.0-x64-portable.zip, x64, self-contained

AB81B96ECC4C1FFDD5BB24ED2412D5F7F9333BFD028343A2BB05E64DCCCB8937

Compact package — LeoCoreBackup-4.3.3.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime

4190634E45E775B22A6E3ED47BCA79E0A45BA4EDD59E222777EB7C57D9C5CA24

4.3.2 — 12 August 2026

• Send run reports through your own mail server. Settings → Email notifications → Send through my own mail server instead takes a host, port, encryption, credentials and your own From address. Switching it on replaces LeoCore's email service for that installation: every report and test message then leaves through your server, from your address, and ours is not used at all. There is deliberately no fallback in either direction — a report that quietly took the other route would defeat the point of choosing this one, and would hand the run's details to a relay you had just opted out of. If your server refuses a message the report fails and the reason is recorded in the run log, so send a test before relying on it. The password is stored DPAPI-protected on the machine, never in the settings row, and leaving the field blank keeps the one already saved.
• Each installation now has its own email send budget. Reports sent through LeoCore's email service carry a per-installation identifier, generated once and kept in %ProgramData%\LeoCore\install-id. It buys this server its own allowance of 50 messages an hour rather than competing for a pool shared with every other customer, so one busy site can no longer exhaust the allowance the rest depend on. When a limit is reached the message now says which one and roughly when sending resumes, instead of a bare failure.
• Backups no longer wait on a throttled mail service. The hourly window slides, so being asked to retry in fifty minutes is normal and legitimate. LeoCore now declines to wait longer than two minutes: the report is reported as failed and the next scheduled run reports again, rather than holding a completed backup open for most of an hour.
• Delete a backup job. There was no way to remove one that was no longer wanted. The bin icon sits beside the rename pencil on the job screen and asks first.
• Clicking a job in the sidebar returns to that job. Once you had navigated to Settings or History, clicking the job that was already selected did nothing at all, because Windows raises no selection change for a row that is already selected.
• Maximising the window no longer hides the Save button. On a maximised window the bottom of the Settings page — including Save settings — sat behind the taskbar. The window now sizes itself to the monitor's work area rather than its full bounds.
• Security fix in a dependency. The SMTP library is now pinned to MailKit 4.16.0 or newer, which fixes GHSA-9j88-vvj5-vhgr: a STARTTLS response injection that let a network attacker downgrade the authentication mechanism. That is exactly the path the new mail-server route uses, so it is fixed rather than waived.

Installer — LeoCoreBackup-4.3.2-setup.exe, x64, self-contained (no runtime prerequisite)

188D9B7F29B015F36A2460DC0C3B12DD3945CB6D2B9B49D35050429B33F17029

Portable package — LeoCoreBackup-4.3.2.0-x64-portable.zip, x64, self-contained

4E3A0C5DCF30547EAA5FE5861515BFD941AF8CAD6FFA75E1AAA0FF63D50A19E7

Compact package — LeoCoreBackup-4.3.2.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime

5E6FF37B7DC2ADB2BB282204EA5BFB66915A26DB7DF53C903EDD1A69220645EE

4.3.1 — 11 August 2026

• The management console works without running it as administrator. This is the important one. The console runs as the signed-in user by design, but the agent's named pipe only granted Administrators and Backup Operators — and Windows marks both of those groups deny-only on an ordinary interactive token, so the ACE could never match. In practice the console could not reach the service at all unless you right-clicked and chose Run as administrator. Installing now creates a LeoCore Operators local group and adds the installing account to it; custom groups are not filtered, so the console connects normally. Members must sign out and back in once — Windows stamps group membership into the logon token and never refreshes it in place.
• Grant access to a colleague without making them an administrator: LeoCore.Agent.exe grant DOMAIN\user.
• A clearer message when access is denied. It used to say only "Access to the path is denied", naming neither the path nor the fix.
• Run reports can go out over HTTPS. A new delivery route hands the report to LeoCore's hosted mail service, so a database server needs no relay, no local MTA and no outbound port 25 — the usual reason run reports never arrive. The API token is stored DPAPI-protected and machine-bound, like the SMTP password.
• Redesigned run reports. Success and failure emails now carry the product's own styling, state the outcome in words and colour rather than an image, and lead with what went wrong rather than burying it under a details table. They stay readable with images blocked, which is the default in Outlook and for unknown senders in Gmail.
• Test messages are real previews. Sending a test now delivers an actual success or failure report, so you can see what will land in the operator's mailbox. LeoCore.Agent.exe email-test does the same from a headless server.
• The installer now ships LeoCore.Updater.exe, which was missing from the 4.3.0 installer and silently prevented in-app updates on installs made with it.

Installer — LeoCoreBackup-4.3.1-setup.exe, x64, self-contained (no runtime prerequisite)

BC7B64D762B47EC806F63114618C172F7F91A89FA7D6179E8817DE9B46831985

Portable package — LeoCoreBackup-4.3.1.0-x64-portable.zip, x64, self-contained

DFF69B19D95701CAAC99DE9C7E56EB0175F0749633FCC0CBE90E72D5AF359519

Compact package — LeoCoreBackup-4.3.1.0-x64-compact.zip, x64, needs the .NET 8 Desktop Runtime

67141EF4EDA1C85C3D111371623ED74A72DE638F45A2A17553B17FD757E8DFED

4.3.0 — 1 August 2026

• A proper installer. setup.exe replaces extract-and-run-Install.cmd: destination, Install, done. It registers and starts the LeoCoreAgent service itself, bundles the .NET runtime so there is no prerequisite, and fails with a non-zero exit code rather than reporting success if the service cannot be registered. See Installing LeoCore Backup.
• The service starts later and recovers better. It now uses delayed automatic start, so it no longer competes with the database engine during boot, and reinstalling over an existing copy rewrites the service path instead of leaving the old one registered.
• Windows Server 2012 R2 is supported again. The installer previously refused to run below Windows 10 1607 despite the runtime supporting 2012 R2 under ESU.
• In-app updates. Settings → Updates → Check for updates now will download, verify and install a new version, then restart. The release information is ECDSA-signed and the download is checked against a SHA-256 from that signed manifest, so a tampered or truncated file is discarded rather than installed.
• Rollback on failure. The previous version is set aside, not deleted. If an update fails at any point it is put back, and the backup service is restarted.
• Versioned database schema. Upgrades apply additive-only migrations inside a transaction, after writing a snapshot. An older build now refuses to open a newer database rather than writing to a schema it does not understand.
• Store installs defer to the Store. A packaged copy never self-updates.
• Cross-server restore, offline activation, and a licence panel under Settings → Licence.

Superseded by 4.3.1, and the one release deliberately left off the version list: the console in this build cannot reach the backup service without being run as administrator, so there is no good reason to install it.

Verifying a download

Get-FileHash .\LeoCoreBackup-4.3.1-setup.exe -Algorithm SHA256

If the hash does not match the value published here, do not run the file — email us instead. Each package is also published with a .sha256 file beside it.

How updates are delivered

1. LeoCore asks /api/v1/updates what the current version is. The request carries no licence key, no machine identifier and no version — it is a plain GET.
2. The reply is signed with the same offline key that signs licences. An unsigned or badly signed reply is treated as "no update available", never as "install from this URL".
3. The package is downloaded and its SHA-256 compared with the one inside that signed reply.
4. Only then is anything unpacked, and only into the program folder.

Automatic checking is weekly and can be turned off in Settings → Updates. Nothing is ever installed without you clicking Download and install.