26.7.3 Janus released
Changes compared to 26.7.2
Changes compared to 26.7.2
Changes compared to 26.8.5
Changes compared to 26.8.4
The WinPE Recovery Environment now has its own Disk Management dialog, so disks can be prepared for a Disk Image restore without calling out to Windows' diskmgmt.msc. It can list disks and their partitions, initialize a raw disk as GPT or MBR, clean a disk, create a new simple volume through a wizard, format a partition, assign or change a drive letter, extend a volume into adjacent unallocated space, shrink an NTFS volume, and delete a partition.


A backup job's speed limit can now follow a schedule, so a job can be held to a lower speed during business hours and run at full speed overnight. This is a long-standing feature request from customers whose devices share a slow internet connection, where a large first backup can run for days. When a scheduled window starts or ends, the new limit applies immediately, including to transfers already in progress.


engine1/mysql Protected Items support a METADATA_FILE EngineProps key: an optional client-local file stored in each snapshot as .metadata, skipped by database replay restores and retrievable with a file restore (COMET-60200)This lets an integration attach its own recovery metadata to every MySQL snapshot, so each snapshot is self-contained for disaster recovery. Comet only carries the file: it is read at backup time, only the path appears in the Protected Item settings, and if the file is missing the job logs a warning while the database streams still back up.
engine1/mysql Protected Items support an INCLUDE_USERS_GRANTS EngineProps key: when set to "1", the server's user accounts and privilege grants are captured as a SQL script stored in each snapshot as .users-grants.sql, skipped by database replay restores and retrievable with a file restore. Verified against MySQL 8.0.43 and MariaDB 11.4 and 10.6, including MariaDB roles; servers without SHOW CREATE USER fall back to SHOW GRANTS alone (COMET-60200)The generated script replays in dependency order and creates each account with IF NOT EXISTS, so an account that already exists on the target, such as root, is left alone while its grants still apply. A restore never runs the script automatically, because doing so could rewrite the target server's accounts; it is retrieved with a file restore and applied by hand.
Changes compared to 26.8.3
User profiles have supported free-form metadata since Comet 26.2.1, but it could only be edited through the API. The user profile page in the Comet Management Console now has an Extra Fields section for editing it directly, useful for notes, contact details, or IDs linking the user to an external system. Each entry can be marked as admin-only or visible to the end user, and the same key name may be stored at both visibility levels independently.
Previously, a wrong server address or credentials for a Proxmox restore started from the Comet Management Console only surfaced after the job had been submitted. The Proxmox destination page of the Restore dialog now has a Test Connection button, matching the Comet Backup desktop app. The test is relayed through the connected device, so it checks the same SSH connection the restore job itself will use. A successful test with no destination node or storage target selected prompts you to pick them, and a failed test against the Proxmox web interface port (8006) suggests using the SSH port instead.
Changes compared to 26.8.1
A top-level administrator can now inject custom JavaScript and CSS into the web interface. Code can be supplied inline or loaded from an external URL, placed in the document head or at the end of the document body, and is applied to the login page and to the web interface of all tenants. The page Content-Security-Policy is extended automatically to permit only the specific code that was configured.


Changes compared to 26.8.0
When Comet Server Authenticode-codesigns the Backup Agent installers it generates for download, the signing key can be accessed through a PKCS#11 driver module. A top-level administrator can now maintain an allowlist of the driver module file paths permitted for this codesigning. Only modules whose file path appears on the allowlist may be used; a path outside the allowlist causes installer downloads to fail. When upgrading, any PKCS#11 module paths already in use are seeded into the allowlist automatically.

ConnectWise Manage joins Comet's existing PSA integrations. Once configured, Comet Server automatically raises a ConnectWise Manage ticket when a backup job fails or a scheduled backup is missed, matched to the affected client, device, and Protected Item, with a severity mapped from the failure type. Repeated failures on the same device and Protected Item add a note to the existing ticket and escalate its severity instead of opening duplicates. The integration is configured under the PSA settings in the Comet Management Console, where you provide the Site URL, Company ID, public and private API keys, Client ID, and an optional Service Board and fallback ticket company.






The account selection for Microsoft 365 Protected Items has been redesigned around an ordered list of include/exclude rules in both the Comet Management Console and the Comet Backup desktop app. You can now exclude specific users, groups, teams, or sites — for example, backing up an entire organization except a few accounts — with an "All accounts" rule automatically protecting users added to the organization later. Rules require Comet Backup 26.8.1 or later on the device.






Changes compared to 26.7.0
Changes compared to 26.5.4
Keeping every device on the latest Backup Agent usually means an administrator remembering to launch a Bulk Update Campaign by hand after each server upgrade. A new Automatic Upgrade Campaign option now does this for you: when enabled, Comet Server starts a fresh Bulk Update Campaign automatically each time the Comet Management Console restarts, rolling the update out across your device fleet with no manual step.
To avoid redundant campaigns caused by quick or repeated restarts, a new campaign is only started if it has been more than 24 hours since the last bulk upgrade campaign.
The option is configured by a top-level administrator under the Backup Agent Downloads settings. Turn on the Enabled toggle, then use Configure upgrade campaign to pre-set exactly how the automatic campaign should behave — whether to upgrade older versions and/or downgrade newer ones, whether to wait for running backup jobs to finish or interrupt them, and whether to target all devices or a filtered subset.



NinjaOne is a unified IT management platform combining RMM, endpoint management, and ticketing. Comet's new NinjaOne integration surfaces backup status directly inside NinjaOne, so you can monitor your customers' backups alongside the rest of their endpoint data instead of switching between tools.
Once configured, Comet writes the outcome of each backup to custom fields on the matching NinjaOne device — Last Backup Status, Last Backup Time, Last Backup Destination, Last Backup Total Size, and the Comet Job ID — refreshed automatically after every job.

Optionally, you can also enable automatic ticketing. When a backup fails, Comet opens a NinjaOne ticket against the affected device, with a link back to the Comet job log and a summary of the run. Repeated failures on the same device and Protected Item add a comment to the existing ticket and escalate its severity rather than creating duplicates, and when the next backup succeeds Comet resolves the ticket automatically with a resolution comment.


The integration is configured under Settings → Integrations in the Comet Management Console and requires the NinjaOne Agent on each device. For full setup instructions, see the NinjaOne integration guide.
