How to use LeoCore Backup

Before you begin

LeoCore Backup has two halves. The LeoCore Backup Agent is a Windows service that runs every scheduled backup, upload, retention clean-up and restore drill — whether or not anybody is signed in. The console is the window you use to set it up and watch it. Closing the console stops nothing.

• A job is one database server, the databases you chose on it, where the copies go, when, and how many to keep. Most sites have one job per server.
• An archive is one backup of one database: an ordinary .zip, AES-256 encrypted by default, that 7-Zip, WinZip or WinRAR can open without LeoCore.
• A destination is somewhere archives are copied: a folder, a share, FTP, a cloud bucket or a cloud drive. A job can have several.
• The catalogue is LeoCore's record of every archive and where each copy is. It is what lets a restore work out which files to fetch, in what order.

What each edition includes

Solo is free with no key and no time limit. Server and Datacenter are licensed per machine. Whatever the edition, restore is never limited — not by edition, expiry or anything else.

Limits only apply when you add or switch on something. If a licence lapses, everything already configured keeps running and stays editable; only new use of a higher-edition feature is refused. See Licences and activation.

The console

The title bar names your edition. The sidebar lists your BACKUP JOBS — each with a coloured status dot — and ＋ New backup job. At the bottom are Dashboard, History & restore, The estate and Settings.

Banners appear under the title bar when something needs you:

• Scheduled backups are not running (red) — the service is stopped or not installed. Click Start the service or Install the service; Windows asks for administrator approval once.
• An amber banner with Retry — the console cannot reach the service right now.

Closing the window with ✕ hides it to the notification area. The tray icon offers Open LeoCore Backup, Run selected job now, History & restore and Exit, and shows a balloon when a backup completes, completes with warnings, is cancelled or fails.

The dashboard

Sidebar › Dashboard

The status line says whether everything is healthy, how many things need attention, and when the next backup runs. Buttons: Evidence report (see Evidence reports), History & restore and ＋ New backup job.

Below the tiles: Needs attention, a 14-day Backup activity chart (failures stacked on top so a bad night stands out), a Backup jobs table, and the last eight Recent runs. Click any job row or attention item to open that job.

Needs attention, item by item

Every item is something that would cost you on a bad day. Red items are critical; amber are worth fixing. When the list is empty the card turns green.

The checks that need the database server or destinations — reachability, permissions, missing databases, free space — run once a day per job, during working hours.

Jobs

Sidebar › ＋ New backup job, then click the job

A new job first asks What do you want to back up? — Databases opens the connect dialog, Files and folders opens the file set (see Files and folders). A database job opens the connect dialog straight away. Its retention starts from Settings › Retention for new jobs, and failure emails go to Settings › Send reports to if that is set.

On the job's dashboard:

• ✎ renames the job; 🗑 deletes it after a confirmation. Deleting never touches archives already written — LeoCore simply stops tracking them.
• ▶ Run now takes a full backup immediately. Verify now runs a restore drill.
• The line under the name shows Last backup, Next run and Retention with a Change… link.
• Cards: Source, Destinations, Schedule, Email notifications, Webhook, Commands before and after, Verification & restore drill and Point-in-time recovery, then the last five Recent runs.

Connecting to a database server

Source card › Change…

Pick the engine, fill in the server, then Connect & list databases. The connection is tested by the service, as the account backups run under — so a success here means scheduled backups will connect too.

A slot your engine cannot take — a differential on PostgreSQL, say — runs a full backup instead, with a warning in the log.

Advanced settings

• SQL Server: Encrypt connection, Trust server certificate, and Staging folder for BACKUP TO DISK. SQL Server writes the backup file itself, on its own machine. For an instance on this machine leave it blank. For a remote instance it must be a UNC share that both the SQL Server service account and LeoCore can reach.
• MySQL / PostgreSQL: the client tools folder (Detect / Browse…), timeout, and for PostgreSQL the default database, SSL mode and how the password is passed.
• Connect using SSH tunnel Datacenter — MySQL, PostgreSQL and Firebird on a server you can only reach over SSH. SSH host, port, user, and a password or private key file.

Passwords are stored encrypted on this machine and never shown again; leave a password box blank to keep the stored one. From 4.10.3 a stored password only goes back to the server it was saved for: change the server, port, login or engine and LeoCore asks for the password again, so a mistyped or changed address can never receive it.

• Client tools folder and SSH key file (4.10.3): the service runs these as LocalSystem, so LeoCore refuses a folder or key file that an ordinary user could change, such as a folder made directly under C:\. Use the tools' own install folder under Program Files.
• SSH tunnel host key (4.10.3): the server's key is remembered on first connection. If it ever changes, backups through the tunnel stop with both fingerprints shown; check with the server's owner, then Test connection and answer Yes to Server identity changed.

Choosing databases

After connecting, or Source card › Select databases…

Tick the databases to back up; Filter by name… and Select all / none help on busy servers. Each row notes anything unusual — full backups only, no log backups (SIMPLE recovery), or cannot be backed up by the service account. When some cannot be backed up, a red box offers Copy the SQL that fixes this, which grants db_backupoperator.

Back up new databases on this server automatically makes the job adopt databases created later, within your edition's database limit. Left off, new databases are not backed up but the dashboard tells you about them.

Files and folders Every edition

Sidebar › ＋ New backup job › Files and folders, or a file job's Source card › Change…

From 4.11 a job can back up files and folders instead of databases — an application's uploads, a shared documents folder, the config beside a database. Everything after the copy works as it does for a database: destinations, schedule, retention, encryption, email and webhooks, history and the recovery kit.

• Name — what history and the archive names call this set of files.
• Folders and files to back up — Add folder…, Add file…, or type a path such as D:\Data or \\server\share\folder. A folder is backed up with everything below it.
• Account for the network shares — appears when a source is a share. The service runs as LocalSystem, which most shares refuse, so it reads them as this account. Change a share or the account and the password has to be typed again.
• Leave out — one pattern per line. A name such as *.tmp or node_modules matches anywhere; one with a slash, such as Projects\*\bin, matches the path below the source; end with \ for folders only. * stays within a folder and ** crosses folders. New sets start with ~$*, *.tmp, Thumbs.db and .DS_Store.
• Read open files from a shadow copy (on) — files another program holds open, such as Outlook data files or QuickBooks companies, are copied from a Volume Shadow Copy snapshot as they stood at the start, instead of being skipped. Local drives only; a share cannot be snapshotted from here.
• Estimate counts the files, folders and size the set would back up now, and lists anything that cannot be read.

Always left out: the recycle bin, System Volume Information, the page and hibernation files, LeoCore's own data and temp folders, and the job's own local destinations — so a backup of D:\ never contains the backups it writes to D:\Backups. Junctions and folder links are listed as skipped rather than followed, and OneDrive files that are online-only are skipped rather than downloaded. Anything skipped is named in the run log and makes the run a warning.

What a backup is: one AES-256 archive per run, like a database backup, holding every file under a folder named after its source (D:\Data becomes D/Data, \\nas\docs becomes UNC/nas/docs) and a file list, leocore-manifest.json, with each file's size, modified time and SHA-256. After every backup each file is read back from the archive and checked against that list. From 4.11.2 the list also records each file's and folder's NTFS owner and directly-set access entries, for Restore NTFS permissions.

Size: there is no limit on the number of files beyond the server's memory. From 4.11.2 a file list takes about 270 MB of memory per million files, and a differential run of a million-file set peaks around 0.75 GB, so sets of four to five million files run in 4 GB.

Full and differential Server (from 4.11.1). A full copies every file. A differential copies only the files that are new or changed since the last full — same size and modified time means unchanged — and lists the rest as being in that full, so its file list is always the whole set and a deleted file is simply one it no longer names. A restore needs the full and one differential, never a longer chain. Schedule a weekly full with daily differentials as you would for a database. LeoCore keeps a copy of each backup's file list on this machine to compare against; when there is none — a rebuilt server, say — the differential is taken as a full, and the log says so.

When files change dramatically Server (from 4.11.1). Every backup is compared with the one before. If 40% or more of the files were rewritten or deleted at once, or 20 or more were renamed onto a new extension (report.xlsx gone, report.xlsx.locked arrived — how ransomware leaves files), the run is a warning and the backup before it is held back from retention on every destination, exactly as for a database whose rows vanished (see below). Sets of fewer than 50 files are not judged.

On Solo a job can be one file set of up to 50 GB, with full backups; file sets do not count towards the two databases.

Destinations

Destinations card › ＋ Add

• Test connection (and Test on each destination row later) writes a file, reads it back and deletes it — as the service, so it proves what scheduled backups will do. It reports the identity used and free space.
• Server identity (4.10.3): an FTPS certificate your machine already trusts is accepted as normal; a self-signed one, and every SFTP host key, is remembered the first time and must stay the same. A change stops uploads there with both fingerprints shown. Confirm it with whoever runs the server, then Test the destination and answer Yes to Server identity changed. An ftp:// server that has once offered encryption must keep offering it; one that never has still works, with a warning in every run log that the password and archives travel unencrypted.
• Changing a destination's address or user asks for its password or key again (4.10.3), for the same reason as on the connection.
• Ransomware resistance Datacenter — on S3, S3 Compatible, B2 and Azure, lock each archive for a number of days in Governance or Compliance mode. Object Lock (or version-level immutability on Azure) must already be enabled on the bucket or container. Nobody — including LeoCore and an attacker with your keys — can delete a Compliance-locked copy early.
• Append-only (LeoCore never deletes here) — uploads only; retention keeps everything on this destination.
• One destination failing does not stop the others: the run is a warning if some copies were stored, and a failure only if none were.
• ✕ on a destination row removes it from the job. Archives already there stay put; LeoCore stops uploading there and stops counting them towards retention.

Folder layouts

Destination row › Folders

By default archives go to {job}/{database} under the destination. A layout lets you organise them differently — useful when several servers share one bucket:

{machine}/{yyyy}/{MM}/{job}/{database}

Click a variable to insert it: {job}, {database}, {machine}, {server}, {engine}, {type} (full, diff or log), {yyyy}, {MM}, {dd}. The dialog shows the exact path the next backup will be written to as you type. Up to six folders deep.

Only folders change — every archive keeps its usual name, because that name is what LeoCore Rescue reads when a server is gone. Archives already stored stay where they are and remain restorable. On local folders and shares, dated folders that retention empties are removed. Use the standard layout puts it back.

Schedules

Schedule card › Edit…

• Full every so many hours (24 by default). Full backups anchor everything; with Full off, nothing is scheduled at all.
• Differential Server — changes since the last full; smaller and faster. SQL Server only.
• Trans. log Datacenter — every few minutes (5–720). This is what makes point-in-time recovery possible. SQL Server (FULL recovery model) and MySQL (binary logging on).
• Run between two hours (it may wrap past midnight), Run on chosen weekdays, and Run on certain days of the month only (1, 15, 32 — 32 means the last day).
• First full backup start anchors every slot. Leave it in the past; a time in the future means nothing runs until then. Start now anchors it at this moment.
• Estimated backup plan previews the next nine runs.

A slot missed because the machine was off or asleep for more than 30 minutes is skipped rather than replayed, and a slot that arrives while the previous run is still going is skipped. Every edition runs its schedule with nobody signed in; before 4.10.4, Solo waited for a signed-in session.

Retention

Job dashboard › Retention: … Change…

Retention decides which archives are deleted. An archive is kept if any rule wants it:

• Keep the newest N backups of each kind — full, differential and log counted separately, for each database — 30 by default. Before 4.10.3 the kinds were counted together, so a job taking a log every 15 minutes kept only hours of full backups; after upgrading, such a job keeps noticeably more.
• Also keep older full backups for the long term Datacenter — the newest full backup of each day, week, month and year, for as many of each as you choose (grandfather-father-son).
• Never remove anything younger than N days Server — a floor under every rule, for jobs that back up many times a day.

Three things are always kept whatever the numbers say: a full or differential that a kept backup depends on (so a chain is never broken), archives still under an immutability lock, and archives held back because a later backup found the data destroyed (see below).

Before you save, the dialog shows what the next run would do on each destination — "keeps 21 of 121, removes 100" in red when anything would be deleted. Lowering retention is the one setting that deletes backups; read that line first.

Different rules per destination

With two or more destinations, Applies to picks the job or one destination. Turn on Give this destination its own rules to keep, say, a week on the local disk and a year of monthlies in the cloud. A destination follows the job until you do.

Settings › Retention for new jobs is only the starting value for jobs created later.

Encryption and the archive password

Settings › AES-256 encryption, Compression

Every archive is encrypted with AES-256 (WinZip AE-2) by default, so a stolen copy is useless. LeoCore generates the password once and keeps it, protected, on this machine. Choose Use a password I choose if you want your own; it applies from the next backup, and older archives keep the password they were written with.

Compression: Fast, Balanced (default) or Max.

Turning encryption off is only sensible for copies that never leave a volume that is already secured. LeoCore asks before adding an off-machine destination to a job while encryption is off.

Running a backup and reading the log

▶ Run now starts a full backup and opens a live panel with progress and the log. If the job is not set up yet, a message says exactly what is missing.

Click any run — in the panel (Details…), Recent runs or History — to open its log. Copy log puts it on the clipboard for a support email; Open log folder opens %ProgramData%\LeoCore\Logs; ■ Stop job and ▶ Run again do what they say.

Each database in a run succeeds or fails on its own. A run with some databases failed is reported as exactly that — "2 of 12 databases were not backed up" — never as a total failure.

Verification

Verification & restore drill card › Configure… › Verify every backup

On by default, in every edition. Before anything is uploaded, LeoCore re-reads the finished archive and asks the engine whether the backup inside is sound: RESTORE VERIFYONLY on SQL Server, pg_restore --list on PostgreSQL, the dump trailer on MySQL, the gbak header on Firebird. A backup that fails is not uploaded.

Also capture logins, roles, linked servers and Agent jobs (SQL Server) adds a server-objects.sql script inside each archive. A database restored onto a new server without these comes back with orphaned users and no scheduled jobs. LeoCore never runs the script for you; reading login passwords needs CONTROL SERVER.

Restore drills Datacenter

Verification & restore drill card › Configure… › Scheduled restore drill, or Verify now

A backup nobody has restored is a hypothesis. A drill restores the newest backup into a scratch database ({db}_leocore_drill by default), checks it comes online, optionally runs a Validation query that must return at least one row, records how long it took, and drops the scratch copy. Production databases are never touched.

• Every (days) — 7 by default. Drills rotate through a job's databases, least recently proven first.
• Restore onto — another server, so a drill never loads production. A new drill server asks for the job's password once (4.10.3).
• The scratch name must be a name of its own (4.10.3). The drill drops its scratch database afterwards, so it refuses a name that is one of the job's databases or already exists on the server — including a copy an earlier drill could not remove; drop that yourself.
• MySQL with log backups: binary logs name their database inside every change, so they can only be replayed into the original. A MySQL drill therefore proves the newest dump (4.10.3).
• Verify now is part of the Datacenter drill feature; a job that already has drills keeps it.
• File sets (from 4.11.1): a drill restores the newest backup — full and differential together — into a scratch folder, every file checked against its SHA-256, then deletes the folder. Sets larger than 2 GB are proven on a random sample of up to 2 GB that always includes files from both the full and the differential. From 4.11.2 a drill reads only its sample from a folder, share, S3-compatible bucket or Azure container, instead of downloading the whole archive first.
• Results feed TIME TO RECOVER on the dashboard and the "Known good" restore points in the restore dialog.
• From 4.10.1, a drill's result is sent through the job's email and webhook triggers like a backup's, with its own wording — RESTORE DRILL FAILED, not BACKUP FAILED.

When the data changes dramatically

Before each backup of a SQL Server, Azure SQL or MySQL database, LeoCore records its tables and row counts, and compares them with the previous backup. It flags:

• The table … is gone or is now empty (it had at least 100 rows) — critical.
• The table … lost …% of its rows (30% or more) and The backup is …% smaller (40% or more).
• This backup barely compressed, and the last one did — critical. Encrypted data does not compress, so this is how ransomware encrypting a database looks from the outside.

The backup still succeeds — a warning, in the log, on the dashboard and in the email subject. On a critical finding LeoCore holds back the backup taken before it on every destination: retention will never delete it, so the last good copy cannot age out while somebody is still working out what happened. Held-back points are marked in the restore dialog, which explains why each was kept. Once you know the data is fine — or have restored what you needed — Release hold… there lets it follow the job's retention again (from 4.10.2).

Email reports Server

Email notifications card › Configure…

Send email after each run to comma-separated recipients, On success, On failure or both. Warnings are sent whenever either is ticked. Most sites should send on failure only — a nightly success email becomes wallpaper.

Reports go through LeoCore's own mail service over HTTPS — no SMTP server, no port 25. To use your own instead: Settings › Email notifications › Send through my own mail server instead (server, port, encryption, user, password, From address). Your server then replaces ours entirely; nothing falls back. Send test before relying on it. With encryption on Auto, ports 587 and 25 must offer STARTTLS from 4.10.3 (465 uses TLS from the start); a relay on this machine may still go without. For an internal relay that offers no encryption at all, choose None deliberately. Changing the mail server or its user asks for the password again.

Webhooks: Slack, Teams, JSON Server

Webhook card › Configure…

Posts each run's outcome to an https:// address, On success and/or On failure.

• Slack — create an app at api.slack.com/apps, turn on Incoming Webhooks, add one to your channel. Also works with Mattermost and Rocket.Chat.
• Microsoft Teams — in the channel, Workflows › "Post to a channel when a webhook request is received". The old Office 365 connector is retired; its addresses no longer work.
• JSON — for a monitoring tool — a flat document with machine, job, database, status, a boolean succeeded, size, duration and the warning or error lines. Field names are stable.

Send test message posts a sample. Email and webhook are sent independently, so one failing never silences the other.

Commands before and after a backup Server

Commands before and after card › Configure…

Usually a pair: stop something so its files are not being written, back up, start it again — net stop "My App Service" / net start "My App Service". Several lines are fine.

• The command after the backup always runs — even if the backup fails or is cancelled — so a stopped service is never left stopped.
• Do not back up if the command before it fails is on by default: a backup taken while the files are still being written can verify perfectly and restore into nonsense.
• Give up after — 300 seconds by default.

Commands run as the service account, normally LocalSystem. Anyone who can edit a job can therefore run anything on this machine, so treat the LeoCore Operators group as administrators.

Restoring a database Every edition

Restore beside any run (job dashboard or History), or Point-in-time recovery › Open…

1. Pick the Database and what to Recover to — the most recent point, or any listed backup. Each point is graded: Known good (a drill has restored it), Verified, Unchecked, Suspect.
2. The Backup chain strip shows which full, differential and log files will be replayed, how much will be downloaded, and warns before you start if a link is missing. LeoCore may recommend a point — Use last known-good point — but never chooses for you.
3. Choose where it goes:
   • Restore as a new database (default, named {db}_restored) — a side-by-side copy; nothing existing is touched. From 4.10.3 the name must be new: a database that already exists, a blank name or the original's own name is refused rather than overwritten.
   • Restore over the original database — replaces it, after a confirmation. Cannot be undone.
   • Restore to a different server — for migrations and replacement hardware. From 4.10.3 the dialog asks for that server's password (the job's saved one is never sent elsewhere); Windows authentication needs none. On the command line, --to-password-env VARIABLE.

Archives are fetched from the nearest copy — a local folder before a cloud bucket — checked against their recorded SHA-256, decrypted and handed to the engine. Closing the dialog does not stop a restore; it carries on in the service.

Restoring files Every edition

A file job's Restore files card › Open…, or Restore beside any of its runs

1. Backup — the newest, or any listed run.
2. What to restore — Everything in the backup, or Only these folders and files: browse the backup folder by folder, or search it by name, and tick what you want (from 4.11.1; the list comes from the copy of the backup's file list kept on this machine, so nothing is downloaded just to look). When this machine does not hold the list — an imported backup, a rebuilt server — it is read from the archive where it sits on a folder, share, S3-compatible bucket or Azure container, fetching only the list rather than the whole archive (from 4.11.2; other destinations download it), with a progress figure while the rest of the console keeps working. Patterns still work too, as the backup names paths: D/Data for a whole source, D/Data/Invoices for one folder in it, D/Data/**/*.xlsx for every workbook below it. Choosing a differential restores the state at that differential — LeoCore fetches the full it builds on as well.
3. Where — To a folder (the default; nothing that exists now is touched, and the folders inside keep the backup's layout), or To the original locations, after a confirmation.
4. If a file already exists — Leave it alone (default), Replace it if it is older, Replace it, or Keep both (the restored copy is written beside it as name (restored).ext).
5. Restore NTFS permissions (from 4.11.2) — puts back each file's and folder's owner and the access entries set on it directly, including folders whose inheritance was switched off. On by default to the original locations, off by default into a folder: there, the original permissions can shut out whoever asked for the copy. Inherited entries are not stored — each restored item inherits from wherever it now sits — and audit rules are not recorded. Backups made before 4.11.2 hold no permissions. Owners are set when the restore runs as the service; Rescue needs to be run elevated to set them.

Every file is written under a temporary name, checked against the SHA-256 in the backup's file list, and only then moved into place, with its modified time and read-only/hidden attributes put back. A restore that stops part-way never leaves a half-written file under the real name. On the command line: leocore restore-files <job> (--to FOLDER | --original) [--files PATTERN]… [--conflicts skip|newer|overwrite|keepboth] [--permissions | --no-permissions]; permissions follow the same defaults as the dialog.

Without LeoCore, leocore-rescue open <archive> -o <folder> extracts a file backup and checks every file (add --permissions to put NTFS permissions back), or open the archive in 7-Zip with the archive password.

Point-in-time recovery Datacenter

Point-in-time recovery card › Open…

With transaction-log backups scheduled, you can restore to any moment the chain covers — just before a bad DELETE, for example. LeoCore picks the newest full at or before that moment, the differential built on it, and every log up to it.

• SQL Server stops at the exact instant you choose.
• MySQL replays whole binary-log backups, so it recovers to the end of the log backup that covers your moment. More frequent log backups give finer points.
• PostgreSQL, Azure SQL and Firebird restore whole full backups only.

Recovering a single table Every edition

Point-in-time recovery card › Recover a table… — SQL Server

When one table was damaged and the rest of the database must not go back in time. Pick the database and the point, tick the tables (or type dbo.Invoices and Add), and choose where the rows go:

• In a new table beside the original (default) — e.g. Invoices_recovered, columns and rows only. Nothing existing is changed; compare and copy back what you need.
• Back into the original table — empties the live table and refills it. Refused for a table that other tables delete from by cascade.

LeoCore restores the backup into a scratch database on the same server, copies the tables, and always drops the scratch copy afterwards.

Commands around a restore Server

Commands before and after card › Around a restore › Configure…

1. Before the restore — a batch script, run once the archives are downloaded and decrypted, just before the database is replaced: stop the application.
2. After it is online — SQL, run inside the restored database as the job's own login: re-link users, mask personal data on a copy, point settings at a test environment. On SQL Server, GO lines split batches as in SSMS.
3. Last — a batch script that always runs: start the application again.

They run only for restores you start — never for restore drills or table recovery — and the restore dialog asks each time: Yes runs them, No restores without them. If the SQL fails, the restore is marked as a warning, not a failure: the data is back, and the log says which statement stopped.

Scripts can read LEOCORE_DATABASE, LEOCORE_SOURCE_DATABASE, LEOCORE_SERVER and LEOCORE_JOB; the last also gets LEOCORE_RESTORE_RESULT (succeeded, warning, failed or cancelled). Read them with setlocal enabledelayedexpansion and !LEOCORE_DATABASE! so an unusual name stays plain text.

Finding backups after a rebuild Every edition

Point-in-time recovery card › Find backups…

The catalogue lives on the machine that made the backups. After rebuilding a server, install LeoCore, create a job for the same database server, add the destination the old server used, then Find backups…:

1. Pick the destination and Search. Every folder is searched; nothing is downloaded.
2. Tick the databases to import. The job's own databases are ticked for you; others on a shared destination are not.
3. Enter the old server's archive password from its recovery sheet. Every installation generates its own, so archives from another server need theirs. LeoCore checks it against the smallest archive straight away.
4. Read the warning if one appears: imported archives count towards retention, so a "keep the newest 30 of each kind" job would delete most of a year of history on its next run. Raise retention first if you want to keep them.
5. Import. They now restore from the ordinary restore dialog.

Imported archives are treated as encrypted, and from 4.10.3 one that turns out not to be is refused at restore: someone with write access to the share could otherwise plant a crafted file. Archives written with encryption off open with LeoCore Rescue instead.

Searchable: local folders, shares, FTP/SFTP, S3-compatible storage and Azure Blob. For a cloud drive, download the archives to a folder and add that folder as a destination.

Recovering without LeoCore

Your backups do not depend on this product surviving. Three things make sure of it:

• The archives are ordinary zips. 7-Zip opens them with the archive password; inside is the engine's own backup file (.bak, .sql, .dump, .fbk, .bacpac).
• A recovery kit is written beside them after every backup — _leocore/recovery/…-recovery.html on each destination. It lists every database's current chain in restore order, each file's SHA-256, where every copy is, and the engine's own restore commands. It does not contain the password.
• LeoCore Rescue — a single free program, nothing to install — opens, verifies and orders the archives for you. See LeoCore Rescue.

History & restore

Sidebar › History & restore

Every backup across all jobs, newest first: status, when, job, type, size, time and destination. Filter with the job pills; click a row for its log; Restore on any row restores that backup.

The estate Datacenter

Sidebar › The estate

One view of every machine that backs up to the same storage. Each installation, in every edition, writes a small status file to _leocore/fleet/ on its destinations after each backup — counts and dates, no data and no passwords. Pick a shared destination under Read from and the estate assembles itself: per machine, its jobs, exposure, restore time, drill coverage and failures in the last 7 days. A machine silent for 48 hours is marked stale. Nothing is hosted, enrolled or sent to us.

Settings › Publish this machine's status controls the status file, and Include database names in it adds names (off by default).

Evidence reports Every edition

Dashboard › Evidence report, or leocore evidence

A dated, self-contained HTML report for an auditor: what was backed up, where, whether encrypted and off-site, every restore drill and its result, observed data-at-risk and restore times, and the gaps — each marked against ISO 27001, NIS2, HIPAA, SOC 2 and DORA controls. The console covers the last 90 days; the command line takes --days. The report ID is derived from its content, so the same records always give the same ID.

Settings, row by row

Sidebar › Settings — Save settings at the bottom

Licences and activation

Settings › Licence

• Online: Enter a licence key…, paste the LEOC-… key from your purchase email. The licence is bound to this machine.
• Offline, for a server with no internet: Activate offline… › Copy fingerprint, open leocorebackup.seksolution.com/activate on any connected machine, paste the key and fingerprint, copy the token it gives you, paste it back and Apply token.
• Moving to new hardware: Remove licence… on the old machine frees its seat; activate on the new one with the same key. Keep the purchase email.
• If a licence lapses or cannot be checked, the paid edition carries on for a 30-day grace period. After that the machine follows Solo limits for new work; existing jobs keep running and every backup stays restorable.

Updates

Settings › Updates

The service checks once a week, sending nothing about this machine; the result shows as "version … is available". Check for updates now, then Download and install. The download is checked against a signed description before anything runs. A normal install downloads the new installer and Windows asks for approval; a portable install updates in place and rolls back on failure — from 4.10.3 its folder is administrator-only, so Windows asks for approval there too. A backup running at the time is stopped and runs again at its next slot. Jobs, credentials, history and archives are never touched by an update.

Turn the weekly check off on an isolated server and install new versions from the download page.

The leocore command line

leocore.exe is installed beside the console. It needs no administrator rights — only membership of LeoCore Operators — so a scheduled task or monitoring probe can run it.

A job can be named by its name, a unique prefix of it, or its id. --json keeps standard output to JSON only. Exit codes never change meaning: 0 ok, 1 bad arguments, 2 service unreachable or account not allowed, 3 no such job, database or backup, 4 refused (edition limit, no destination), 5 the run failed, 6 warning or needs attention, 7 cancelled, 8 timed out waiting, 9 internal error — a defect; the application log has the detail (4.10.3; such failures used to return 2). An option given an empty value, such as --database "", is refused with 1 rather than ignored.

leocore status
leocore run "Nightly" --wait
leocore restore "Nightly" --database Sales --as Sales_check --wait

LeoCore Rescue Free

A single program for the worst day: the server is gone and you have the archives. Nothing to install, no .NET, no service, no LeoCore. It is in the install folder (Rescue\), in the portable zip, on the download page, and optionally on each destination. It only reads; it writes nothing but the files you ask it to extract.

Give the password with -p, or --password-file in scripts; otherwise you are asked for it.

The service and administration

• The service is LeoCore Backup Agent (LeoCoreAgent), running as LocalSystem, starting automatically and restarting itself if it stops. It listens on no network port; the console talks to it through a local named pipe. Outbound it uses HTTPS only — to your destinations, and to our site for licences and update checks.
• Who may use the console: members of the local LeoCore Operators group, and elevated administrators. Add someone with LeoCore.Agent.exe grant "DOMAIN\user" from an elevated prompt; they must sign out and back in. Trust operators as you would an administrator: they can set commands that the service runs as LocalSystem. Every change to commands or the tools folder is written to the log with the account that made it.
• The data folder %ProgramData%\LeoCore is restricted to SYSTEM and administrators from 4.10.3 (the service applies this at every start); it holds the encrypted credentials.
• Shares and domain accounts: to reach a share as a domain identity, run the service as a domain account or gMSA: LeoCore.Agent.exe install --account "DOMAIN\gmsa-backup$".
• Other service commands (elevated): start, stop, status, uninstall, --console to run in the foreground and watch.
• Where things live: program files in C:\Program Files\LeoCore Backup; jobs, catalogue, history and protected secrets in %ProgramData%\LeoCore\leocore.db; daily logs in %ProgramData%\LeoCore\Logs (kept 60 days); a snapshot of the database before every upgrade in %ProgramData%\LeoCore\Backups. On Server and Datacenter, warnings and errors also go to the Windows Application log, source LeoCore Backup, for monitoring tools to pick up.
• Portable and compact zips: extract to a permanent folder, right-click Install.cmd › Run as administrator, then start LeoCore.App.exe. The compact zip needs the .NET 8 Desktop Runtime.
• Uninstalling asks whether to remove configuration and history; the default keeps them. Archives are never deleted.

Silent and unattended installs, Server Core and Intune are on the installation page.

When something goes wrong

• "Your account is not allowed to manage LeoCore Backup" — sign out and back in after installing, or run the console as administrator.
• Scheduled backups are not running — the red banner's button starts or installs the service.
• A backup failed — click the run, read the first red line, Copy log.
• A share or bucket works for you but not for backups — Test the destination: it runs as the service and names the identity used. Give the share credentials, or run the service as a domain account.
• SQL Server says the backup succeeded but the file is not visible — a remote instance needs a staging UNC share both accounts can reach (Connect › Advanced).
• "cannot be backed up by the service account" — use Copy the SQL that fixes this.
• An archive will not open — it was written with a different installation's password; find that server's recovery sheet.