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.9.2 — 3 September 2026

Current release

• 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.