What's New?
"What's New?" is a new blog series covering recent changes to Comet in more detail. This article covers the latest changes in Comet Voyager over March 2022.
Time since job end
Comet Server's web interface has a filter system that can be used for searching job history, and for generating backup job reports containing a summary table of that job history. The query system is very flexible, supporting boolean operators (and/or/not/nor), sub-clauses, grouping, and drag-and-drop rearranging. You can filter for jobs based on many different properties including the job's status (e.g. Success / Failure / Quota Exceeded), its classification type (e.g. Backup / Restore / Retention pass), its upload and download size, usernames, Protected Item and Storage Vault IDs, and many more.
This allows you to construct advanced email reports such as "Email me immediately if a job fails, plus a weekly summary" as described in our email report recipes section.
When using a custom job history search to construct an email report, it's important that the result set has a time bound on it. Without a time bound clause, the system will produce a report containing jobs from all time. The 'Preview' button on this dialog is helpful in ensuring the result looks correct.
In Comet 22.3.0 and later, there is a new available clause to filter by 'Time since job end', joining the existing 'Time since job start' filter. In some cases, using one filter or the other in your scheduled email reports could cause you to miss out on seeing jobs that take longer than the period interval. We advise following the documented recipe for best results.
Bulk upgrade campaign improvements
Comet Server allows you to remotely deploy a software upgrade to your live-connected user accounts. You can do this for a single user from their live-connected actions dialog, or you can deploy the upgrade in bulk via the Bulk Upgrade Campaign menu item. The bulk upgrade campaign takes care of intelligently waiting for devices to come online and avoiding interrupting running backup jobs, giving you an overall percentage indicator of the software uptake.
In Comet 22.3.0 there are more options to control the behavior of the bulk upgrade campaign:
Firstly, you can use our query system - mentioned above - to filter and select which devices should be considered eligible to receive the software update. If you are troubleshooting issues on a specific platform, you can restrict the update to individual device operating systems. You can filter by username and other properties too, allowing granular mass deployment without needing to resort to individually sending updates via the live-connected actions dialog.
Another new option is to control whether or not running jobs should be interrupted. The bulk upgrade campaign normally avoids sending a software-upgrade message signal to the client if a job is running, preferring to complete a backup job with old software, rather than have new software and no backup job. Having the client be one or two versions behind the Comet Server is not a problem as we maintain a strong commitment to backwards compatibility.
But if the customer's job schedules are running back-to-back, or they are infrequently online, then the campaign system might not find any reasonable opportunity to deploy the upgrade, and the devices could fall significantly far behind. It's now possible to override this behavior and ask for the bulk upgrade to be deployed regardless of any running jobs. The software installer will terminate all Comet's running processes as part of the upgrade.
These new settings are all optional and default to the previous behavior, of sending the update to all devices while not interrupting any running jobs.
Find matching Storage Vault addresses
Comet Server is split into multiple roles, including the Auth Role - where user accounts log in - and the Storage Role - one place where a customer might upload data to. These are conceptually independent parts of the Comet Server and can be enabled or disabled as required.
When you log in to the Comet Backup desktop app, if you check the 'advanced options' checkbox, you can see the server address that Comet is logging into. This is the Auth Role address. If you have a Comet-type Storage Vault in the customer's settings, you can check the hostname field for that Storage Vault. This is the Storage Role address.
In small installations, it's likely that Auth Role and Storage Role will be both enabled on a single server. If you are using direct-to-cloud storage, you might not even be using Storage Role. In larger installations, the Auth Role and Storage Role can be decoupled, to allow scaling them independently. For instance, you could have one single Auth Role server for all customers, with many dozens of Storage Role servers. In that case, the two hostname fields mentioned would have different content inside.
The Role system is simple and flexible, but managing these URLs at scale can be difficult. If you have to perform a server migration, such as a replication failover, the easiest way to do it is to change what DNS points to, instead of changing a lot of login-URL settings and Storage Vault hostname settings.
But sometimes these changes must be made. It is possible to remotely redirect a user to a different Auth Role login address via the live connection action dialog:
As well as the Auth Role login hostname, it is possible to change a user's Comet-type (i.e. Storage Role) Storage Vault hostname remotely by editing their Storage Vault settings. There is a way to do this in bulk via the 'Advanced' options > 'Bulk Replace Addresses' page. This page allows you to find-and-replace Comet-type Storage Vault hostnames across your entire user base.
In Comet 22.3.0, this page has gained separate 'Find' and 'Find and replace' modes:
You can now use the new 'Find' option to perform a dry-run, to see which customers are using any given Storage Vault URL. This is a helpful safety feature before switching to 'Find and replace'; and, it can also help with troubleshooting certain types of Constellation Role error message.
Simpler My Servers page
When you visit account.cometbackup.com, you can use the 'My Servers' page to manage your Self-Hosted and Comet-Hosted servers. Previously these were displayed on two separate tabs; we have now streamlined this page to show all your servers together, regardless of where they are hosted.
If you have a mix of environments (e.g. a primary a Comet-Hosted server and additional self-hosted servers for on-prem requirements; or, a primary self-hosted server and a test environment Comet-Hosted server) then you'll find it easier to see an overview of all your Comet Server infrastructure at a single glance.
Comet job information in custom command environment variables
Comet supports running commands as part of each backup jobs. You can configure a command to run before or after the backup job, or even when a disk snapshot is thawed. Custom commands can be attached to the Protected Item (e.g. for creating archives or database dumps for backup), to the Storage Vault (e.g. to supply extra login commands), or to an individual schedule (e.g. to shut down the PC after the backup job completes).
The commands are run as part of the job, and the output of the custom command is included in the job report. If your custom command returns a non-zero exit code, the job report will be marked as unsuccessful.
In Comet 22.3.0, the commands are run with additional environment variables available. These environment variables help you integrate Comet with your other systems. For example, you could use an After command that signals to your RMM software if a job has completed, including the device ID, job ID, and in-progress job status.
Export Device ID
Comet Server has a comprehensive API - anything that you can do in the Comet Server web interface can be done via our API. The API makes use of JSON over HTTP, and it's simple to interact with - we have sample code and SDKs for several programming languages.
When you are integrating Comet with other software, you will find that the customer's device running Comet Backup is always represented by a "Device ID". This identifier is automatically generated based on a private set of hardware and software identifiers. It is designed to remain stable throughout the lifetime of the device and be a consistent way to identify it. However, the proprietary nature of its generation means it can be difficult to correlate Comet's device IDs from the Comet Server API with any other identifiers running on the same PC.
For instance if you have RMM scripts running on a customer's PC, you may want to know the current PC's Comet Device ID in order to make API calls related to the current device.
On Windows, this has been possible up until now by reading the HKLM\Software\backup-tool\DeviceIdentificationID registry key. This key is created when Comet's services start up and is an easy way to correlate the current device with the Comet API.
However, macOS and Linux devices don't have a Registry that we can use in the same way. Comet 22.3.0 adds a new platform-independent technique for retrieving the Device ID, by running the backup-tool info device-id command. This command outputs the current device ID on stdout and should always have the same result as reading the registry key.
This feature is highly useful for ISV (Independent Software Vendor) partners who are looking to integrate Comet more closely with their other software utilities.
Wasabi integration improvements
Our partners at Wasabi are continuing to roll out new supported storage regions. Comet performs at its best when you minimize the latency from the end-customer through to the storage location, so when choosing a cloud provider, we recommend selecting a storage region as close as possible to the end customer.
Comet 22.3.1 adds support for the automatically detecting buckets in Wasabi's latest ca-central-1 region. Because Wasabi bucket names form a global namespace, Comet can generally autodetect the region without it having to be manually specified in the Storage Vault or Storage Role settings.
Elara rollup release
As with every quarter, we released our latest Comet 22.2.0 'Elara' release on March 8th. This release rolled up all the features from the 21.12.x Voyager series into a new long-term-support release that we will continue to patch and support. Some of the feature highlights include a new Settings page in the Comet Server web interface; support for WebAuthn as a 2FA method; and single file or folder restore for Disk Image backups. All users of the previous quarterly series 21.11.x 'Himalia' and earlier are encouraged to upgrade, but we’re happy for them to continue using older quarterly versions if they are not experiencing any issues.
Comet Elara takes its name from another moon of Jupiter - It is the eighth largest Jovian satellite, and is named after Elara, one of Zeus' lovers. It was discovered on January 5th 1905.
Thanks to everyone who joined us for the release launch webinar - if you missed this coverage of all the new features from Elara, you can watch the replay on our YouTube channel.
Synology improvements
We recently added support for installing Comet Backup on the Synology NAS platform using a *.spk file. This support debuted with Comet 21.12.7 and we have been continuing to improve it since then. In the latest 22.3.x 'Voyager' series, you'll find improvements for installation on DSM 6; reduced job log verbosity on DSM 7 with @eaDir paths; and better support for the AdminBrandingAvailablePlatforms API.
Thanks for reading - stay tuned for our next monthly update summary, and if you would prefer to watch instead of read, we have a large number of update summaries available on our YouTube channel.
Mason Giles, CTO