"What's New?" is a series of blog posts covering recent changes to Comet in more detail. This article covers the latest changes in Comet Voyager over November 2022.
November was a more active month for Comet development. There were six "Voyager" releases in the 22.9.x series during November, plus the first release of our new 22.11.0 "Ananke" quarterly series. This exceeds our previous quiet release volumes in October and September. A large number of minor cosmetic improvements were added, as well as many small bugfixes, so we would recommend that all users of previous 22.9.x versions should continue to follow the latest updates for the best experience.
Comet 22.9.8 now includes a native Apple silicon version of Comet Backup for macOS. This will improve efficiency when running on recent Apple computers with M1 and M2 chips.
Your existing macOS users will likely be running the current, x86_64 version of Comet Backup for macOS on their M1 or M2 hardware. The x86_64 version does run well under Apple's high-performance Rosetta2 emulation layer included with macOS. In addition, the backup job speed is usually limited by network speed or disk I/O, not CPU speed, so running under emulation is not likely to significantly impact backup job runtimes. However, the native version for Apple silicon will be more CPU and battery-efficient. After upgrading to the native Apple silicon version, there will be no visible difference to the end-user, except for a snappier and longer-lasting computer.
When an existing macOS user, running a version of Comet prior to 22.9.8 on M1 or M2 hardware, is part of a Bulk Upgrade Campaign to upgrade their installed Comet Backup client app, they will first upgrade to the 22.9.8 x86_64 version under emulation. This version can detect that it is running under Rosetta2, and during the following software upgrade, it will upgrade to the ARM64 version instead of the x86_64 version. As a result, two upgrade cycles may be required for all macOS users to receive the full performance and efficiency benefits of this change.
Comet 22.9.6 added a built-in feature to integrate with Gradient MSP. Gradient MSP is an external service that allows you to sync user account data and backup job error alerts into many RMM/PSA systems including ConnectWise, Autotask, Kaseya, Syncro, Pulseway RMM, HaloPSA and more. There is no cost to connect one Comet Server to one PSA.
Check out our launch webinar below to see how to take advantage of this service to connect your Comet Backup user accounts to your PSA platform, perform billing and invoice reconciliation, and receive alerts about failed backup jobs.
The latest version of Comet Backup adds support for a quick access download button directly within the navigation bar. This is intended to help first-time users of the Comet Server app find this option more easily, as well as being a quick option for experienced users.
Long-time users of Comet Server might remember the original version of this feature - a download icon in the top navigation bar - that existed between Comet Server 17.3.2 and 18.5.0 "Phobos". It was removed in Phobos owing to the introduction of the download links on the login screen, and also the download button within the home-screen 2x2 button pad.
Change your root keys for Comet Storage Powered By Wasabi
During November we added support for regenerating the top-level root access keys for your Wasabi account. The top-level root access keys are needed by Comet Server for the Storage Templates feature, to automatically provision new direct-to-cloud Storage Vaults for your customer. Being able to rotate these keys and issue new replacements can be a crucial feature if anyone gains access to your Comet Server configuration.
For your convenience, if the old keys are in use on a Comet-Hosted server for a Wasabi Storage Template, or for Constellation, then the Comet-Hosted server will automatically have its settings changed to use the replacement keys.
It comes with built-in examples and is built for TypeScript first. The SDK also contains generated JSDoc typings, ESM and CommonJS bundles, making this suitable for both Node.js and browser users. We've also created a sample app using the Next.js framework that shows how you can use this framework to create a custom B2C signup form for Comet Server using the new SDK.
The Comet Server web interface is a "single-page app" (SPA) that uses the same Comet Server API for its entire feature set, ensuring that our Comet Server API is stable, reliable and well tested. For many years now, our own Comet Server web interface has been entirely developed using Typescript, using a private internal version of this same SDK. We're very pleased to be able to release this work publicly under the open-source MIT license, unlocking productivity for Node.js, TypeScript, and JavaScript programmers looking to integrate Comet Server more closely with their businesses.
The Comet Server API is JSON over HTTP and can of course still be used in programming languages that do not yet have an official SDK, and we have many code samples available for other programming languages in our documentation.
We've just put the finishing touches on our latest Quarterly release, 22.11.0 "Ananke". This rolls up the whole quarter of 22.9.x enhancements into a new fixed point for you to build your business on.
Like Comet's previous recent quarterly software releases, "Ananke" is named after a moon of Jupiter, discovered as recently as 1951. It's the largest moon of the "Ananke group", a set of seven of the moons of Jupiter that have similar orbits and are thought to have a common origin. The moon is named after the ancient Greek mythological goddess of inevitability and necessity.
If you prefer to watch and listen rather than read, I'm hosting a webinar next week to discuss the latest 22.11 "Ananke" software release. Please register for a notification before we go live on December 6th (PST) to catch up on all the latest Comet news with me - there will be a free live Q&A session after the presentation.
As well as that, we have many more videos available on our YouTube channel, including guides on getting started with Comet, individual features, demonstrations with our technology partners, and webinars for previous quarterly software releases.
"What's New?" is a series of blog posts covering recent changes to Comet in more detail. This article covers the latest changes in Comet Voyager over October 2022.
October was a quiet month for Comet development. There were two "Voyager" releases in the 22.9.x series during October, matching our previous September release volume. A large number of minor bugs were fixed, so we would recommend that all users of previous 22.9.x versions should continue to follow the latest updates for the best experience.
In the Comet Server it's now possible to migrate a user account between Tenants. To do so, click the "Transfer user" option from the "Actions" menu on the user account page.
When you log in to the Comet Backup desktop app, the login is directed to the Auth Role server URL. Each Tenant in Comet Server generally has its own isolated Auth Role URL for the clients to log in to. When you use the "Transfer user" option, a signal will be sent to the online logged-in devices, to redirect them to log in again to the updated URL.
However, it's not possible to send this message to an offline device. If there are any offline devices, the Comet Server web interface will warn you about this situation - you'll have to manually reconfigure any such devices to use the new login URL, as they will not be able to log in at the previous URL. You can make this change from the Comet Backup desktop app at the login screen, or by using the 'Update Login URL' live action at any other time.
Our June 2022 recap blog post covered the new feature to allow custom SMTP servers at the Tenant level. One of the key limitations of this work was that the top-level administrator was required to configure these settings on behalf of the tenant. This is unfortunately an important restriction from a safety perspective, as it can help insulate the top-level administrator from any repercussions related to the IP reputation of their mail server.
The Comet-Hosted service is based on the Tenants feature, and correspondingly the responsibility for custom SMTP configuration falls on the account.cometbackup.com web application. We're pleased to announce that the IP reputation concerns have been addressed for this environment, and it is now possible for you to configure a custom SMTP server for your Comet-Hosted server via the 'My Servers' page:
Another change affecting the My Servers page on the account.cometbackup.com website, is that this page has received a design overhaul to now show your servers in a table view, instead of a card view.
When redesigning this page, our design goals were to make the page more intuitive for new users as well as more powerful for existing users. With the new design, the page is more scalable if you have a large number of Comet servers (either Self-Hosted or Comet-Hosted). It's more visually consistent with the design of the rest of the account.cometbackup.com site, and the ability to log in to a Comet-Hosted server is now clearer and much more obvious.
The Credit Usage report at account.cometbackup.com shows you a detailed history of all deductions to your Comet account balance. It's an essential tool for partners, to ensure you are appropriately matching your Comet expenses to your customer invoices. For partners with a large number of installed devices, or a very long history, this page can become cumbersome. We introduced a search feature on this page some years ago, but advanced filtering was not yet available, unless you exported the whole result as CSV or XLSX for external processing.
We're pleased to announce that it's now possible to filter your Credit Usage history by date, via the fields on the 'View' dialog.
This feature was a long-time request from our Feature Voting system. The regular feedback for requesting this feature helped us prioritize the work - so if there's anything you want to see in Comet, please do make your voice heard in the feature voting system.
It's long been possible to "copy and paste" a Protected Item from the Comet Server web interface to duplicate it, however, this functionality was restricted to the web interface. As of Comet 22.9.4, you can now right-click a Protected Item in the desktop app to "Duplicate" it.
This is a welcome convenience feature for users of the Microsoft SQL Server, Office 365 and Hyper-V Protected Item types, which can in some cases benefit from having multiple Protected Items with slightly different settings. By duplicating a Protected Item and then making minor customizations, it can be much faster to configure these from the Comet Backup desktop app.
Throughout the COVID-19 pandemic, the Comet team have been fortunate to be able to keep working remotely, while still continuing to expand the team by hiring and training teams of developers all over New Zealand. As restrictions lift, we brought the NZ team together face to face for the first time for the inaugural "Cometcon", a week-long event of networking, professional development, training, and brainstorming about Comet development.
We're looking forward to bringing the remote team together more regularly in the future!
"What's New?" is a series of blog posts covering recent changes to Comet in more detail. This article covers the latest changes in Comet Voyager over September 2022.
September was another busy month for Comet, following on from August and our release of Comet 22.8.0 "Carme". The Carme release has been very well received, and we have not yet needed to release a patch update for it.
There were two "Voyager" releases in the 22.9.x series during September. We followed through with the removal of Windows Vista support, as discussed in our August blog post. This has reduced the filesize for downloading the Comet Backup installer by about half, which is a significant improvement and helps new users start using the app sooner. This change has also made it possible for us to perform a lot of technical cleanup internally to the software, removing edge-cases and upgrading libraries.
Comet 22.9.2 added support for direct streaming restore of Microsoft SQL Server backups, straight back to your database server, without any temporary spooling.
This follows from last month's support for streaming MySQL restore in 22.9.0.
When you use this option, the Microsoft SQL Server backed-up data will be streamed from Comet's Storage Vault into Microsoft SQL Server without needing to temporarily storing any .bak files and manually importing them via SQL Server Management Studio (SSMS).
You can configure the Microsoft SQL Server restore feature with all the same connection settings as for backup. The settings will be prefilled based on the current matching Protected Item, or they can be changed as required. This feature is available for restores performed in the desktop app, or remotely via the Comet Server web interface, or via the Comet Server API.
If your Microsoft SQL Server uses the "FULL" recovery mode, Comet Backup can take differential or log backups from the database. Generally we recommend always taking Full or Copy backups - Comet will chunk the whole database into an incremental-forever deduplication system, so that you don't need to worry about chains or full images or log truncation. However, in some very large databases, you may still wish to do this. To restore a differential or log backup in Comet, you should first restore the matching full backup with the "I want to keep restoring additional files (WITH NORECOVERY)" option set; and then, restore your target differential or log files with the "This is all I want to restore (WITH RECOVERY)" option set.
Following on from last month's redesign of the Comet Backup desktop app main screen, we've made some more minor changes. When creating a new Storage Vault using the 'Custom' option, the Comet Backup desktop app now shows this in a wizard.
This brings the behavior in line with creating new Protected Items in the Comet Backup desktop app: a wizard is used for initial creation, to help guide you through the process, but after initial creation a tabbed dialog is used, for quickly jumping to any setting.
We've also applied a cosmetic redesign of the Search dialog in the Comet Backup desktop app, to also use a wizard, allowing easier back and forward navigation. In particular, this is helpful if you want to change the set of search snapshots after having already entered a filename.
The restore dialog now lets you properly resize columns when selecting a Protected Item for restore.
There were also various fixes for viewing job reports from inside the desktop app. The 'View Log' button is now more responsive when first shown; long job report lines have better word-wrapping behavior, especially on macOS; and very long job reports will now load more quickly.
Webhooks and Websockets are two features of Comet Server, for external partners to receive live notifications of changes inside the Comet Server. These features are used by third-party apps and services to ensure their synced data is fully up to date and responsive to the latest changes.
In Comet Server, the Tenants (formerly "Organizations") feature allows you to create a private, isolated zone of user accounts. The top-level administrator has visibility over all tenants, both in the Comet Server web interface and in the API. In Comet 22.9.1 we've ensured that Webhook and Websocket events for the top-level administrator will now include events from sub-tenants, fixing a consistency gap.
We've also added the option to filter which types of live event messages you would like to receive when constructing a Websocket, by using query parameters (e.g. ?allowList=4100). This brings the websocket support more in line with the Webhook support, which allows any choice of event messages.
Now that the Webhook and Websocket features are more aligned in terms of feature support, the choice of tool is primarily driven by whether you prefer the "push" or "pull" model for events. This comes down to practical decisions about network firewalls, connection establishment, message ordering, deliverability guarantees and observability.
One last thing to point out about Webhooks is that in the Comet Server web interface, we've renamed this tab to "Integrations" - for reasons that will become clear next week!
Thanks for reading - there are some great new features in the development pipeline, that we're excited to be able to share with you soon in the upcoming 22.9.x Voyager series.
"What's New?" is a series of blog posts covering recent changes to Comet in more detail. This article covers the latest changes in Comet Voyager over August 2022.
This month at Comet we've been busy with behind-the-scenes changes. We've been lucky to continue to welcome many more new staff members that have joined the development team. Throughout August, there were three "Voyager" releases across the 22.6.x series; the launch of the new 22.8 "Carme" quarterly release track; and the slightly early reopening of Voyager for the 22.9.0 release.
Carme is the latest entry in our quarterly rollup series. It branches off from our main rolling Voyager development, into a fixed target for our partners to qualify and build upon.
Comet 22.8 "Carme" takes its name from another moon of Jupiter. It was discovered along with our previous Comet release "Lysithea" by Seth Barnes Nicholson in 1938, and both discoveries were reported in the very same publication. Jupiter's moons are classified into groups, and despite sharing a discovery event, Lysithea and Carme come from different groups of moons and have very different orbital properties. The moon itself is named after the Cretan goddess Carme, one of Zeus' lovers.
Carme brings 7 features and 14 enhancements, including IDrive e2 support, presigned clients, the ability to spread out peak job load across a random period, custom SMTP servers for Tenants, support for fallback domain controllers, more restore options, and improved performance.
For this last month of August, there have been very few features landing in the Voyager release track, with mostly a focus on fixing issues. This has resulted in a trouble-free release process and a great release that we have confidence in. It does mean that there are only a few new features and enhancements to cover, as all the larger changes were held back for the 22.9 "Voyager" release.
In early versions of Comet, macOS codesigning required Comet Server to SSH into a real Mac machine somewhere on your network in order to run the official XCode toolchain. We were very proud to integrate rcodesign as a native, built-in alternative in Comet 22.3.3; the bundling of pre-signed clients in Comet 22.6.2; and now, no longer requiring the third-party iTMSTransporter application as of Comet 22.6.9.
In our company we use the Go programming language extensively, so it's perhaps a little unusual that we didn't have a public Go SDK until this point. That's largely because PHP and Ruby produced the largest demand from external developers looking to integrate Comet with their web sites and ecommerce platforms; and in our in-house Go development environment, we can use the type definitions directly from Go without any SDK at all. However, having a public Go SDK definitely makes it easier to write and develop auxiliary tools, and we've already seen several utilities being ported to this great and efficient programming language.
Announcement about legacy operating system support
The 22.8.0 "Carme" release is the culmination of everything up through the previous 22.6.x "Voyager" release cycle. From this point, we're planning to make some bigger changes.
During the 22.9.x timeframe, we expect to remove support for running the Comet Backup desktop application on Windows Vista, Windows Server 2008, and macOS 10.10 "Yosemite".
If you have end-users running these operating systems, you should either
(A) stay with the 22.8 "Carme" release cycle, or
(B) install the 22.8 "Carme" Comet Backup desktop app and use it along with an upgraded version of Comet Server, or
(C) arrange for your end-users to upgrade to Windows 7, Windows Server 2008 R2, macOS 10.11 "El Capitan", or newer.
⚠ No longer supported in 22.9.x, please continue to use 22.8.x
⚠ No longer supported in 21.12.x, please continue to use 21.11.x
Windows Server 2008 R2 (NT 6.1 / Windows 7-based)
✅ Still supported
✅ Still supported
We don't take this removal lightly, but it's clear that in the present day, Windows Vista is not widely used or relevant, and we expect minimal issues as a result of this deprecation.
Although the Vista-based Windows Server 2008 and the Windows 7-based Windows Server 2008 R2 have the same extended support lifecycle, the underlying technology of the R2 update is significantly more advanced than the Vista-based RTM edition, and correspondingly easier for us to develop for. It's likely that Windows 7 and Server 2008 R2 will remain supported by Comet for a much longer period of time.
In Comet 22.9.0 "Voyager", we've put a new coat of paint on the Comet Backup desktop app. A picture says a thousand words:
The desktop app now shows you a summary of your Protected Items, Storage Vaults, and recent job history at a single glance. We're very happy to have struck a balance between information density, visual identity, and efficient performance as the charts remain using an optimized native-code renderer. We are excited to continue improving the UI going forward and we expect to make tweaks over the 22.9 "Voyager" series in response to your feedback before this lands in the next quarterly release.
This dashboard screen is divided into five main areas:
The Storage Vaults chart at the top left shows up to three Storage Vaults. If the Storage Vault has a quota, the sawtooth segment will be split into two colors showing the partial usage percentage of your Storage Vault quota. If you have more than three Storage Vaults, three are chosen for display based on whether they have Quota limits in place, and also whether they have been recently used on this device. Further details about your Storage Vaults remain available on the Settings tab.
The Currently Protecting chart at the top right shows a breakdown of your Protected Item size, across this device and across other devices in your account. If your Comet user account has a limit on the number of total devices allowed to be registered, or a limit on the total Protected Item size, these figures will be displayed here.
The Storage Vault size chart at the lower left looks at the past 10 days' of job history to build a visualization of how your Storage Vaults have grown or shrunk in that time. Comet measures the size of a Storage Vault during backup operations, so this chart is most effective if there are recent backup jobs for your Storage Vaults. A maximum of three Storage Vaults are shown, and as long as the necessary data points are available, the same choices and colors will be used as per the Storage Vaults chart at the top left.
The Transfer chart in the lower right looks at the past 10 days' of job history as well, to show the upload and download size for your jobs, including both backup and restore operations. These figures correspond to the Uploaded and Downloaded job report columns and at a technical level they reflect the transfer size to- and from- the Storage Vault. Notably this means that Upload/Download sizes may be reported even for Local Path storage vaults, and, Upload/Download transfer amounts for over-the-network Protected Item types (such as remote MySQL and MongoDB servers, or Office 365 tenants) are not currently reported here.
The news widget at the bottom shows bulletin messages created by the Comet Server system administrator. It's useful for contact details, notices of recent service changes, or promotional messages. Any news messages you create in Comet Server are shown immediately in the desktop app. If you have no news entries, this bottom section is hidden entirely.
We're excited to announce a partnership with Storj.io, a decentralized cloud storage provider. It's been possible to use the Storj service with Comet's S3-compatible option, but in Comet 22.9.0 "Voyager" it's now possible to connect directly to the Storj P2P network without involving the centralized gateway. This allows for faster performance during download operations and lower latency without the centralized bottleneck.
At the time of writing, Storj coordinate a network of over 13,000 storage nodes worldwide and can offer great low-latency to nearby storage nodes at an industry-leading price of $4 / TB and a generous free tier of 150GB.
Please note that when using Storj in this way, Comet performs client-side erasure coding to distribute data redundantly throughout the Storj network. The file upload size reported in Comet reflects the amount of data delivered to Storj, but the upload size experienced over the network may be higher as a result of client-side redundancy.
A key aspect of the Storj integration is the ability to configure Storj as a Storage Template provider:
Storage Template providers (formerly known as Requestable Storage providers) allow your Comet Server to automatically provision new, private Storage Vaults for each of your customers, with isolated credentials - including Constellation Role support for automatically cleaning up Storj buckets that are no longer used by any Comet user account.
As with all of our supported storage platforms, the new Storj integration is also available as a backend for Comet Server Storage Role, if you would prefer all customer data to flow through your Comet Server.
Comet supports backing up MySQL using our dedicated Protected Item type. This was one of the original Protected Item types included with the very first Beta versions of Comet, and is available at no additional charge. It works by streaming the output of mysqldump directly into our chunking deduplication engine, without requiring any spool space or temporary files.
In Comet 22.9.0 "Voyager" we've introduced corresponding support for streaming MySQL restores:
The data will be streamed from Comet's Storage Vault into the MySQL server without needing to temporarily store any .sql files and without needing to manually import them.
You can configure the MySQL restore feature with all the same connection settings as for backup. The settings will be prefilled based on the current matching Protected Item, or they can be changed as required. This feature is available for restores performed in the desktop app, or remotely via the Comet Server web interface, or via the Comet Server API.
This is a great feature that simplifies the restore process for this highly popular database. We expect to announce a similar feature for another popular database very soon, so keep an eye on our release notes for the latest news.
Configure webhooks from the Comet Server settings page
Webhooks are a feature to send live events from Comet Server to your other systems. They are largely of interest to developers who want real-time information to flow from Comet Server into other systems, such as CRM and ERP systems.
Comet Server has supported webhooks since 20.6.1, with major enhancements happening for custom header support in Comet 21.9.2. However, they've largely been hidden and confined to users who read the documentation and can make manual changes to the cometd.cfg file. In Comet 22.9.0 "Voyager", we're improving the discoverability of this feature by allowing you to view, edit and manage your current webhooks from the settings page in the Comet Server web interface.
This feature is available for webhooks both at the top-level, and for individual Tenants, including Comet-Hosted users.
As a top-level administrator, you can control permission to access this feature via the admin permission checkbox or via the AllowEditWebhooks API field.
Constellation Role has previously been restricted only to the top-level administrator. In Comet 22.9.0, it is now available at the Tenant level as well:
A "Bucket Users" report generated by a tenant Constellation is entirely independent of the top-level Constellation. The tenant also has an independent choice for the "Data deletion" setting.
Access to this feature can be controlled by a top-level administrator. If your Tenant administrator has all settings features enabled, this feature is included. If your Tenant administrator has been configured to have no- or limited- settings available, the Constellation Role feature is enabled by default. This is because Constellation Role is an essential partner of the Storage Template feature, to clean up disk space or cloud bucket space that was used by since-deleted user accounts.
Misuse of the Constellation Role feature can cause data loss, so please take care when configuring this setting. Our documented advice is that you should have exactly one Constellation Role for your Comet Server cluster; when running multiple Constellation reports on a per-tenant basis, the key advice is likewise to not overlap Constellation responsibilities - one set of user accounts and one set of buckets (local, Cloud Storage, Storage Role or otherwise) should be managed by one Constellation Role configuration only.
If you are using Constellation at the top-level of the Comet Server with top-level credentials, then it is able to see Tenant user accounts and deallocate their buckets as required. However, if you are in the situation of not using Constellation at the top level, or if you are not in control of which remote Storage Templates are used by your Tenants, then this new feature is especially useful to enable data cleanup.
If you prefer to watch and listen rather than read, I'm hosting a webinar next week to discuss the latest 22.8 "Carme" software release. Please register for a notification before we go live on September 6th (PST) to catch up on all the latest Comet news with me - there will a free live Q&A session after the presentation.
As well as that, we have many more videos available on our YouTube channel, including guides on getting started with Comet, individual features, and webinars for previous quarterly software releases.
"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 July 2022.
It's been a busy month for Comet, and we've been lucky to welcome many new staff members that have joined the development team. This month, the 22.6.x "Voyager" release track has seen five minor updates. We've also released two minor updates for our 22.5.x "Lysithea" quarterly release track. There were many interesting improvements:
We're pleased to announce that IDrive e2 are now available as a built-in option in the Storage Vault selection type. This direct integration uses the IDrive e2 API to automatically determine the target bucket hostname, reducing the number of configuration steps compared to the S3-compatible option.
As well as using IDrive e2 directly, you can also add them as a Storage Template provider (previously known as "Requestable" Storage provider) in the Comet Server settings area. If you enter your top-level credentials in this field, Comet Server can use them to provision private buckets with separate credentials for each user, allowing seamless direct-to-cloud backup without traversing through the Comet Server Storage Role.
A quick reminder - when using the Storage Templates feature, it's likely you'll want to configure cleanup for cloud buckets that are no longer being used by any user account. Comet's solution for this problem is called Constellation Role, and it's available from the settings page of your Self-Hosted Comet Server. In Constellation, you can enter the same IDrive e2 top-level credentials for it to search through. When a Constellation report runs, it finds all your buckets; checks all the user accounts; cross-references the user's Storage Vaults with the available buckets; and deletes any discovered buckets that are not in use by any user account.
Constellation is designed to scale up to clusters of multiple Comet Servers, with any mix of server replication, Storage Role, or direct-to-cloud buckets created by the Storage Template feature. You should have precisely one Constellation Role server amongst your entire cluster of Comet Servers.
In Comet Server 22.6.6, Constellation now has an extra safety guard to prevent deleting any data if no Auth Role server is configured. This feature can help prevent accidental misconfiguration. This feature joins the many other safety features in Constellation, such as the ability to turn off deleting buckets until you are satisfied with the discoveries it makes.
Amazon AWS first launched their ground-breaking S3 service ("Simple Storage Service") back in 2006. In the 16 years since then, the S3 protocol has evolved and grown, adding support for V4 signing, path-vs-subdomain bucket addressing, multiple regions, batch processing, streaming processing, and many more features. As "S3-compatible" has become the de-facto standard cloud protocol for object storage, there are many varied implementations of the protocol and many different providers require different quirks for compatibility.
Comet has an extensive set of auto-detection for various S3-compatible cloud storage providers, which all require slightly different configuration. We've recently encountered several S3-compatible providers all needing the same type of custom configuration, related to the region field. For providers that we officially support and partner with, such as Wasabi and Storadera, we were able to specify the necessary fields internally, but it wasn't an available configuration option for any custom S3-compatible provider. This is now available in Comet 22.6.7.
For example, configuring a custom S3-compatible Region field helps Comet connect to Scaleway Object Storage in their Paris, Amsterdam, or Warsaw regions with the latest V4 signing mode instead of requiring legacy V2 signing. We're happy to improve support for Scaleway as a well-established European cloud provider offering 6+3 data redundancy (6 data drives plus three parity drives).
Last month, we launched the Job Execution Delay feature, to pseudo-randomly delay a backup job schedule by a different amount each time. If you apply this random job execution delay across your entire customer base, it can spread out the load on your storage infrastructure, reducing the peak spike of CPU usage that happens when many jobs all start simultaneously.
This month in Comet we've expanded our support for this feature. In Comet Server 22.6.3 you are able to enforce this setting at the Policy level and also at the whole-server level, where it will override any user or policy settings.
In the Comet Server web interface, when looking at a user's Protected Item or Storage Vault, a "Test Connection" button is available that uses Comet's code to reach out to the target and ensure the device is able to reach it successfully. Because Protected Items are private for each device in a user account, it's clear that we should send this live-connected signal to the correct device, but for a Storage Vault, any device in the account could potentially respond with this information for us. Up until now, Comet Server has picked a random device in the account for the connection.
For Storage Vaults, the situation can be a little different. In the case of shared Storage Vaults in the cloud, it's likely that any device can reach them. However, there are various situations where only some devices in an account might be able to access a Storage Vault. For example, a Local Path vault for an external harddrive; or troubleshooting if one specific device is unable to reach the target network. To help in these situations, the "Test Connection" button now shows a dropdown if multiple device connections could be used for the test.
We also fixed a security issue related to the Test Connections button in the web interface in Comet 22.5.2 and 22.6.4. If you are running an older version of Comet Server, please upgrade at your earliest convenience, or avoid using the web interface button.
For the programmers in the audience - the AdminDispatcherListActive API that underpins the live-connection selection here was also extended to support choosing the target username. This change is available now also in the latest updates to our PHP and Ruby SDKs on GitHub - and watch this space for more programming language SDKs coming very soon.
This month we've upgraded the main compression library used by Comet Backup - the industry-leading Zstandard - to its latest 1.5.2 release. This brings with it a major improvement in compression performance. The practical impact will be limited - backup jobs are almost always bottlenecked by the speed of reading files from the local disk, or by the network speed of uploading them to the Storage Vault - but even in that case, a more efficient compression system should result in lowered CPU usage during backup jobs.
There is a second compression-related story to discuss this month - I'd like to thank everyone who reported a recent issue with the RPM installer for Comet Server. In last month's "What's New" report, we described the new option for pre-built clients. Bundling these pre-built clients with Comet Server resulted in a large size increase for the Comet Server installer. To compensate for this, we adjusted the compression settings used by the Comet Server installer to use a larger window size, so that the pre-built clients would compress effectively with the piecemeal client components that are used with custom branding. This was highly effective, and the pre-built client feature ultimately had a negligible effect on Comet Server install sizes.
However, this compression change caused issues with some RPM-based Linux distros. After some research and testing, we were not able to resolve the issue while still maintaining the optimized file size of the RPM installers - so apologies to RPM users, the Comet Server installer for 22.6 "Voyager" has jumped from ~150MB to ~250MB. This is still a relatively small file size for the great functionality packed within, so we're sure you'll be happy to have the RPM installer functioning correctly again.
"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 June 2022.
After our 22.5.x "Lysithea" release last month, June saw the reopening of Voyager under the 22.6.x release track. This month we shipped four software releases - one Lysithea point upgrade and three Voyager versions. There were many interesting improvements:
If you have a large customer base on your Comet Server, it's likely that across your users, there is a large number of jobs starting at 7pm, 8pm, and 9pm, and in general a pattern where a lot of jobs start at the top of the hour. In some cases, this can cause a performance issue with the Comet Server to have to accept so many jobs at once.
There is now a new feature in the backup job schedules, to specify a random delay. The random delay is calculated based on per-user, per-schedule parameters, and if applied to many customers, it will stochastically have the effect of spreading out this peak load spike over a longer time period.
Early next month we're looking at extending this to support bulk application in the Policies system and also server-side, so watch this space!
This month in Comet 22.6.2, there is a new option to download a pre-built codesigned client installer (Comet branded):
Until now, Comet Server has always generated a custom Comet Backup client installer, customized to embed your own branding and Comet Server login URL. But this makes all our MSP partners into distributors of custom software, and therefore subject to some of the problems faced by software distributors.
If you are experiencing issues with SmartScreen, Gatekeeper, or AV products with your custom-generated client installer, and you are in a position to allow the default Comet branding, then using a pre-built codesigned client installer may resolve the issue.
When using a pre-built client installer, Comet Server no longer has an opportunity to embed your default server login URL into the application. To compensate for this, we've made three other changes:
Firstly for the silent install process on Windows, there is a new /SERVER= command-line parameter to override the default login URL
The silent installer has long since allowed pre-filling the username and password on the command-line, but it always relied on the internally embedded Comet Server login URL. The new pre-built codesigned installer does not embed any Comet Server login URL, and you must enter the Comet Server URL at the Comet Backup login screen. This is a problem for the silent installer which is resolved with this new /SERVER= parameter.
If your silent install runs under cmd.exe, you should use double-quotes as per /SERVER="https://example.com" to avoid issues with character escaping.
Secondly, the Comet Backup Windows installer now allows reading the default URL from the installer's filename if there is no embedded default URL. On Windows, the Comet Server URL will be read from the installer's EXE filename (e.g. Comet Backup (http-my-company-com-8060).exe) if present. This information is only used if there is no default URL embedded into the installer itself.
Thirdly and finally - if the default server login URL could not be determined - then the user is of course required to enter it in the login dialog in the software. Generally this field is hidden behind the 'Advanced Options' checkbox:
We now automatically open this area up in more cases if no default URL is known.
We've also decided to automatically open this area up if a 192.168.x.x address is used for the Comet Server. When you are first configuring Comet you may be accessing the Comet Server by its LAN or localhost IP address. This address may get compiled in to a custom client installer and be difficult to troubleshoot. Comet already showed the server URL by default if a localhost IP was used, but also showing it for a LAN IP can help speed up troubleshooting this issue.
Comet Server supports using external authentication sources for admin accounts. If you have a highly-available LDAP server infrastructure using multiple servers, such as an Active Directory failover cluster with primary- and fallback- domain controllers, you are now able to configure multiple LDAP server addresses in Comet Server. When an admin user tries to authenticate at the Comet Server login screen, if a connection to the first entry on the list fails, Comet will try the remaining entries on the list before denying the authentication attempt.
In Comet Server, the Tenants feature allows you to create an isolated zone within the Comet Server that has its own user accounts, admin accounts, domain name, and branding settings. You can use Tenants for resellers, branding imprints, or just general customer grouping. It's a very flexible feature but every Tenant is ultimately under the jurisdiction of the top-level system administrator, and there are some limitations on the allowable settings.
A Tenant can have customized email settings, so that the Tenant's customers will receive their email reports "From" the tenant company's email address. This month, we've expanded this to also allow customizing the SMTP server used for a specific tenant.
In the last few years, email has become highly rigid and standardized. In order for your email to be properly delivered to the recipient's Inbox folder, there is a certain amount of administrative work required to authorize domain names, set up SPF and DKIM, before allowing someone to control these fields arbitrarily. An incorrect email configuration can result in tarnishing your IP address's reputation. As a result, we only allow the top-level Comet Server administrator to configure these email settings on behalf of the tenant.
Our own Comet-Hosted service is based on the Tenants feature. We expect to be able to offer custom SMTP support to Comet-Hosted users soon!
We have renamed "Requestable storage" to "Storage Templates". This is the feature of Comet Server that can provision new per-customer credentials for your storage platform.
This change is currently rolling out across our online documentation and the Comet-Hosted service. If you are operating a Self-Hosted Comet Server, the change will appear after the 22.6.2 upgrade in the Comet Server settings page and in the Comet Backup desktop app.
Overall, the new name should make the behavior clearer to new Comet partners.
We've released new major versions of our PHP SDK and Ruby SDK. These SDKs allow you to very easily write code that talks to the Comet Server API to list users, create accounts, and change settings - doing anything at all that the Comet Server web interface can do.
Our SDKs use Semantic Versioning ("semver") and bumping the major version is done to indicate a compatibility break, as has happened here. We take backwards compatibility very seriously at Comet, it's a key aspect of how our API is designed. The API itself remains fully backward compatible at the HTTP / JSON wire-level. Old versions of the SDK will continue to work, even against new versions of Comet Server.
So why make a "semver-major" breaking change at all? The compatibility break is solely in SDK code, not in the Comet Server API. We cautiously made a change to the MAJOR number in response to some minor type definition changes. These changes are fully compatible at the HTTP / JSON level, but if your application was using these type definitions - for instance, declaring variables explicitly using these types - then you might get an error when upgrading the library. Please read the full changelog (PHP / Ruby) for detailed upgrading guidance.
As long as a "semver-major" change was required to clean this up, we've taken the opportunity to modernize our system requirements for the PHP SDK. The PHP SDK now uses PHP 7 return type declarations, as well as parameter type hinting for scalar values. This should give a better development experience and help you catch bugs sooner before they make it to production. If your PHP server platform is still using PHP 5.x, we advise looking at upgrade options - or else the previous 3.x major version will remain available on GitHub and in Composer.
We're always happy to see work taking place in our language translations. In the course of June we saw updates to the Thai (22.6.0) and Dutch (22.6.1) translations for Comet.
As always - Our staff mostly only speak English, so we do hire translation contractors for the bulk of this work - but over the years we have consistently found that the best-quality translations come from our customers, who have a full understanding of both the software and the IT / MSP backup industry. If you see a typo in our translations, or if you want to help translate Comet into a new language, we'd love your contribution and it couldn't be easier to get started - just head to our GitHub page and follow the instructions.
I grew up on a dairy farm in rural New Zealand. I went to a country school with 30 kids and only two classrooms. One of the teachers at that primary school used to go to the computer graveyard and pick up old Macs. He'd have us cobble together working computers from the parts. If you got enough gold stars at the end of the two weeks, the person with the most gold stars got to keep the computer. That's where I got into technology.
What attracted you to Comet? You impressed during the hiring process because you applied for more than one role and took a lot of initiative during the hiring process.
I liked working at my student job, 24 hours a week, being the IT guy for a local high school. It was client-facing work which was great experience for working on Comet's Support Team. Mainly, I helped teachers get their laptops and projectors working. But it was part-time, so I needed to move on.
I was scrolling through job applications when a development role at Comet popped up that didn't specify the experience level needed. I thought, "Oh, maybe I'll get lucky". I applied and interviewed for that role. I really liked the team members I interviewed with. The main thing that attracted me to the job was the modern tech stack, which includes Golang and TypeScript. If a company is advertising for that, it means they have a modern product; you're not going to be working on something from 2005. I was really excited about that aspect.
Unfortunately, I wasn't experienced enough to get that role. The same week I didn't get it, I saw another job at Comet pop up, the Support role. I emailed and asked, "Is there a way that I could do support for a year, learn about the product, and upskill to the point where you'd be happy to bring me on as a Junior Dev?" I thought I would be a good fit for the Support role since I was already in support, but I didn't want to do Support in the long run; I wanted to use my degree and go into programming.
The team hired me! A few weeks later, I was working at Comet.
Support to Junior Dev wasn't a role that existed before at the company. You are pioneering this. How have you found the process of being the first to follow this pathway?
At first, I thought, What have I gotten myself into? I'm just going to be doing Support for another year, having already done Support for a year and a half. And then I'll be dumped into a junior developer position. I was worried I wouldn't have the training or the skills to go into that position.
But basically, from Day 1 at Comet, I've been doing development work on the side, along with the support work. It's been really good to be able to take on small things that need doing. So when I did move into a full-time developer position, I would be confident that it would go well.
I get small tasks assigned to me during the monthly dev meeting. The leadership team gets together and figures out the priorities, then the work gets divvied out. I will pick up smaller tasks. There are a lot of opportunities at Comet. You could be working on the Comet client one day, or the account dashboard, or the billing system. You go where you're needed.
Do you like that about working at Comet? At larger companies, people will often be quite specialized in one area of the code.
It keeps me from getting bored and isn't repetitive because you're not getting stuck in one area of the code base. I really like that.
The other way that development work lands on your plate is through working on the Support tickets, correct? For someone who moves into this role after you do they need to be able to take the initiative?
Being in Support, small problems come to you. I either raise them to the Development Team, or sometimes I just go into the code myself and have a look around and see if I can figure out why it's not working properly.
Have you had times when you've been able to do bug fixes by yourself?
Probably not by myself, but I have had quite a few investigations with the support developer of the day. We'll have a look at it together and figure out why it wasn't working, and that's always quite fun.
Why choose Comet over working at a large corporate?
When I was choosing where to work, I looked at some post-graduation programs, like at the big banks. I read one of their 'Day in the Life of a Developer' articles, and it seemed overly structured. Having a schedule is good, but having to be so strict, it seemed like extra, unnecessary stress.
Yes, I meet with Ersin, the Technical Lead here at Comet, once a week. Any development I'm working on, I can take to him and ask for ideas or help or review, which is really nice.
Have you learned a lot through that process that you don't think you would have learned otherwise?
Yes, definitely. Going from being a student, where most of the projects are individual, to working in a team, where everything is reviewed, was a learning experience. I've learned to work within a team in a way that I haven't needed to before, which is good.
Does Ersin often lead you in a direction that's a new way for you to think about the problem?
It's always different! I'm constantly learning new approaches and gathering new ideas. I will go to Ersin, "I want to implement this. This is how I'm planning to do it, but how would you go about it?" Then after a while, I see why his solution was different than mine, and I see why I'm a junior developer and he's a senior developer. [Laughs]
Do you feel it's contributing to your career growth in the direction you want to be going?
Definitely, the more interactions you have with people who have more knowledge, the more knowledge rubs off on you, the better you become as a developer.
What advice would you have for someone following in your footsteps in this Support to Junior Developer role?
Learn Git!
Have you been given opportunities to grow at Comet?
Shortly after starting, I was asked, "We're looking for team members who want to continue to upskill. Would you like to get certified in AWS?" I had only been doing Support for a month and did not expect to get an opportunity like that so early on in a new role. I worked on it for a few months, did the test, and got the certification along with another developer.
It was great! I really appreciate these sorts of opportunities. I had used AWS before but wondered, Do I really know what I'm doing? It's nice to have that knowledge validated. It's already been useful.
The hackathon was really cool! Just having a few days to work on whatever you wanted to work on. Having time dedicated to that was really nice. Completing some small features, it was really, really gratifying to look at that and say, "I did those! These little bits of Comet were done by me and they're in the product!" After those few days, having accomplished that felt great.
If you could have any tech superpower, what would it be?
Test your backups! Don't just expect everything to be configured correctly or assume that your end-user hasn't changed any settings.
On support calls, I always try to ensure that the customer is backing up their server. It's a common oversight. People remember to backup devices but forget to back up their backups!
Comet is headquartered in Christchurch; what do you enjoy about living here?
Christchurch is very well placed to get to anywhere else on the South Island. I like the proximity to so many things. There is lots of stuff to do. Over the weekend, I went out to the Akaroa Peninsula and the Lyttelton Farmers Market.
The BBQ's are always great. Coming into the office, there's always people to talk to. You can always ping someone on Slack and reach out to them, have a chat -- work related or not. Everyone is friendly and approachable.
This year, one of the developers cultivated a bunch of chili plants and gave seedlings out to some of the team members. I enjoyed it when people posted their chili garden updates on Slack. Even though I didn't get in on growing chili's, I enjoyed everyone sharing their updates.
We'll get you into the chili club next year! Maybe we'll pick something to grow that isn't spicy next time.
Maybe by then, I'll have built up my tolerance. We'll see! [Laughs]
"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 May 2022.
May was a busy month for us at Comet - we've continued to expand our development team, and we are making great progress improving Comet. We've also grown our customer success team and support team, so if you see some new faces in the support tickets, please give them a warm welcome!
The headline news of this quarter is that we've rolled up the 22.3.x Voyager series into a new long-term-support release. If you're not comfortable with weekly Voyager software updates, we strongly recommend the quarterly rollup series to build your business upon.
The codenames for Comet follow a consistent naming pattern, as we voyage from the inner solar system (Comet 17.2.0 "Mercury"), through the inner planets, Earth, Mars, the asteroid belt, Jupiter, and now looking at the moons of Jupiter. "Lysithea" is the tenth moon of Jupiter; it was discovered by Seth Barnes Nicholson in 1938, and is named after the Lysithea of Greek mythology, one of Zeus' lovers.
Our friends at Wasabi have continued to launch new regions, with the latest addition being Australia (launched on May 9th). At our Comet offices in New Zealand, we're particularly pleased with the latency and performance of the new Australia region. The new region is automatically detected in Comet's software, and no region-specific settings are required.
IDrive e2 works very well with Comet, and you can expect to hear more about them in the future. Mention Comet Backup when signing up to get 1TB free storage for 30 days.
Comet Backup supports many different cloud storage providers if you bring your own storage credentials. If you have configured the customer's Comet Backup app to back up directly to a cloud storage provider, you should avoid reusing storage credentials across customers. For each customer, you should either create new cloud storage credentials manually; or proxy the data through Comet Server Storage Role; or ideally, have Comet Server provision new cloud storage credentials automatically. We call this the "Request Storage Vault" or "Requestable" system.
Previous versions of Comet Server supported this "Requestable" provisioning for Backblaze B2, Wasabi Cloud Storage, and custom HTTP integrations. We're very happy to announce that Comet Server extends this support to Amazon AWS and to custom IAM-compatible cloud services.
There are a lot of S3-compatible cloud storage providers on the market, but having "Requestable" support to automatically provision private credentials is a more advanced level of integration than just S3-compatible, and there's not yet an industry standard for providers to use. We're working with individual storage partners to expand our "Requestable" integrations over time.
When configuring a backup job schedule in Comet, you can now tell Comet to back up hourly, but only at certain times of day:
The main two use cases for this feature are
to back up only 9am to 5pm, Monday to Friday, when you know the customer's computer is on and working, to avoid any meaningless Missed backup job reports; and
the exact opposite, to back up from 5pm to 9am when you know the customer isn't interactively using their computer.
It's long since been possible to select an hourly schedule, or a daily schedule for weekdays, or individual backup times - but rolling them all together is a nice improvement that makes this kind of configuration much simpler.
This was a popular suggestion from our Feature Voting page. If you haven't checked out our Feature Voting page, i'd really recommend it. We look at this system often to help guide our priorities, so it's a great way to help shape the future of Comet.
Our Synology .spk package was first publicly released in February this year, as part of Comet 21.12.7. Since then, we've continued to improve the installer and our compatibility.
The platform compatibility has been extended to include more types of ARM CPU, including Synology NAS models based on the Armada, Comcerto, and Monaco platforms. The Synology package has been improved to better understand NAS timezones, provide clearer warnings on login failure, and to calculate device IDs in a more repeatable way. You should find that the installer just works in many more cases.
In the DSM 7 version of the installer, some additional steps are required to grant file permissions to the Comet Backup app. Previously, these steps were only listed in our official documentation, and if you are white-labeling the Comet Backup software for your end-users, then it is difficult to share a link to this information. The latest versions of the installer now include a new built-in help guide explaining how to configure the necessary permission settings for backup.
All of the changes mentioned above are included in our latest quarterly release 22.5.0 "Lysithea".
The tables in the Comet Server web interface now properly remember their state when refreshing the page or using the back button. This may sound like a subtle change, but it has had an immediate impact in making the Comet Server web interface much more intuitive and easy to use.
This was a long-standing request from our Feature Voting system. It's taken a while to get to this point because Comet Server's web interface is an SPA (Single Page App). This has been an excellent technical foundation for us, as our development team reuses the official Comet Server API, ensuring that it is stress-tested and has broad feature coverage, allowing any external API developers to get the same experience we do internally. However, this API-first design has meant we're not technically using the web browser's traditional Back button handling, and that has resulted in minor quirks like this. Thank you all for your patience with us as we developed this feature.
As of Comet Server 22.3.6, and available now in Comet 22.5.0 "Lysithea", when using the browser back button, all table settings will be restored exactly how they were, including rows-per-page, sorting, current page number, search term, and custom column selection. Your rows-per-page setting will also be preserved globally, even when you log out and log in again.
Your custom column selections will be preserved for each individual table, even when you log out and log in again, with your current version of Comet Server. However, if the Comet Server version changes, the custom column selections will be reset, because new versions of Comet Server might have introduced a different set of available columns.
As well as this improvement to the table system, there were many other small improvements to the Comet Server web interface this month. For example, "Internal Error" popup messages can now show you the information directly in more cases, such as when an administrator tries to use the "Request Storage Vault" feature.
Comet Server has a feature called Server Self-Backup to create backup copies of Comet Server's own configuration, such as the cometd.cfg and comet-users.db files.
The Self-Backup feature does not use the full chunking and deduplication infrastructure like a regular Comet Backup job, because if the Comet Server itself experiences an outage to the point where you need to restore from backup, then this chunking and deduplication infrastructure is unavailable. Instead, the Server Self-Backup only creates simple passworded zip files in any supported storage location. This self-contained design is a way to break the "chicken and egg" problem compared to using the full Comet infrastructure.
For providers with very large Comet Servers with thousands of user accounts and millions of job logs, the overhead of performing a Self-Backup might be considerable. The latest version of Comet Server includes two key improvements to the Server Self-Backup feature to reduce the CPU load in these cases.
Firstly, you can use the new slider component to adjust the compression level, to make a trade-off between 'Faster' compression with lower CPU impact but a larger file-size, and 'Smaller file-size' with a higher CPU impact.
If your Comet Server is hosted on a cloud provider where you pay for both CPU usage and for storage usage, you might find that the storage cost of a larger Self-Backup is actually lower than the CPU cost of performing more compression.
In addition, a new option has been added to exclude the job database from the Comet Server Self-Backup.
The job database is almost always the largest component of a Self-Backup, responsible for as much as 90% of the archive size and CPU impact. It's still important to back up this job database. However if it was excluded, then perhaps the other parts of the Comet Server configuration could be backed up more frequently. Excluding the job database also makes the generated zip archives smaller and more accessible when you only want to restore the user-profile settings or the server configuration.
For large partners in this situation, we recommend having two Self-Backup schedules: one frequent schedule that excludes the job database, and another less frequent backup that includes all databases.
When you restore data in Comet, you can restore files and folders directly; you can restore Office 365 emails back to the cloud; you can stream restore data into another program without spooling (great for MySQL); you can restore to nowhere, just to test that Comet is working; and, you have the option to restore as an archive format.
Multiple archive formats are available, including the ubiquitous zip, and we might as well have stopped there - but there is a time and place for other options. In particular, Linux users are better served by a compressed tar archive that can be used with standard system tools, without needing to install a Zip program.
This month, the Restore as Archive feature was expanded to support tar.zst, the latest type of tar format that uses zstd compression instead of gzip. This results in a smaller filesize while also being faster to compress and to decompress. The ordinary Linux untar command (tar xaf file.tar.zst) works with these files since GNU tar 1.31, which can be found in Debian 11 "Bullseye", Ubuntu 21.10 "Impish Indri", Fedora 30, and RHEL 9.
The .tgz and .tzst file extensions are now understood as common aliases for the .tar.gz and .tar.zst extensions, and the target directory for restore is now created automatically, aligning this behavior with how an everyday File and Folder restore works.
Comet Server can be configured for multi-tenancy, to give each of your partners an isolated zone within your Comet Server for their own individual customers. We've seen this feature used for reseller support and for hosted service offerings. Tenants (previously known as Organizations) have been a standard feature of Comet Server for a long time now, and we're continuing to improve the support.
When logged in to the Comet Server web interface as the top-level administrator, looking at a cross-tenant customer, you will find that the available Policy options now more accurately reflect the tenant's policies, instead of showing unusable options from other tenants. The "Request Storage Vault" dropdown option also now correctly finds the tenant's list of "Requestable" storage providers. These changes should make it much more seamless to manage a tenant's customers from the top-level account.
If you're a software developer making use of the Comet Server API to manage your Tenants, you might be interested to know that these improvements come thanks to some new API parameters in our AdminAddUser, AdminPoliciesList, AdminRequestStorageVaultProviders, and related APIs. New features for the API are generally mentioned in the official changelogs, but you can also stay up-to-date by following the changelogs for our PHP SDK and Ruby SDK on GitHub.
Internationalization is a high priority for us at Comet. It enables you to serve your customers in local markets much more effectively.
Comet is available in 13 fully translated languages, and the Comet 22.5.0 release includes updated translations for 10 of those - Danish, German, Spanish, French, Croatian, Italian, Portuguese (Brazil), Portuguese (Europe), Russian, and Hebrew. All of Comet, from the end-user desktop app and customer-facing email reports, through to the admin section and the new user guide from last month, can be used in translation.
We've also found- and fixed- many small gaps where the underlying English was showing through, such as the pagination footer for tables in the Comet Server web interface.
Our staff mostly only speak English, so we do hire translation contractors for the bulk of this work - but over the years we have consistently found that the best-quality translations come from our customers, who have a full understanding of both the software and the IT / MSP backup industry. If you see a typo in our translations, or if you want to help translate Comet into a new language, we'd love your contribution and it couldn't be easier to get started - just head to our GitHub page and follow the instructions.
In particular this month, I'd like to thank one of our partners for getting the Chinese (Traditional) localization started! This will be our 14th language.
If you'd prefer to watch rather than read, I'm hosting a live webinar to discuss the latest 22.5.0 "Lysithea" release and everything in it since our previous quarterly release. Please register for a notification before we go live on June 7th to catch up on all the latest Comet news with me - there will a free live Q&A session after the presentation.
As well as that, we have many more videos available on our YouTube channel, including guides on getting started with Comet, individual features, and webinars for previous quarterly software releases.
"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 April 2022.
In early April, we became aware of a security issue affecting the Tenant feature in the Self-Hosted Comet Server version 22.3.1, 22.2.0 and all earlier versions. A certain API could allow administrators in one Tenant to see user profile details belonging to user accounts from another Tenant.
We discovered this issue internally, and there is no evidence to suggest that any misuse has taken place. All partners known to be using this feature have been notified directly.
Comet 22.3.2 and Comet 22.2.1 were released on April 6, 2022 to fix this issue. We recommend upgrading at your earliest opportunity.
Comet Server allows you to customize the branding for the client software, including changing the branding, logos, text, EULA, and icon for both the installer and the application itself.
When you download Comet Backup from your Comet Server web interface, Comet Server generates a custom installer on-demand. This custom installer contains all your branding as well as the built-in URL for your Comet Server, so no extra configuration is needed by the end-user.
However, newly generated installers are not immediately trusted by operating system security measures such as SmartScreen on Windows or Gatekeeper on macOS. Windows users are likely to be familiar with the blue SmartScreen dialog and practised in clicking the "Run anyway" button, but for macOS users, you may be surprised to learn that there is no such "Run anyway" button:
It's possible to bypass the dialog by right-clicking the *.pkg installer and choosing 'Open'. Then the dialog will include a 'Run anyway' button. However, this is a major user experience roadblock for macOS clients.
A better way to solve this solution is to codesign the installer. You can configure this on both Windows and Linux from inside your Comet Server, in the settings page, on the "Client branding" tab, using the "Codesigning" button at the bottom. For Windows, it's as simple as purchasing a certificate from one of our recommended vendors and uploading it to the "Authenticode" tab.
For macOS, the process was much more complicated. The tools used to perform macOS codesigning could only run on a real Mac machine. Comet Server required you to purchase a certificate from Apple, but in addition – to also to buy a Mac (or rent a cloud Mac), configure it for SSH, and set up some very careful permissions in order to allow Comet Server to remotely SSH into it to sign the installer *.pkg file. This was difficult for our partners (and difficult for our support team!).
Thanks to recent developments, we are pleased to announce that a Mac is no longer required for this process. You can simply purchase the certificate and upload it to this screen; Comet Server will handle all the necessary signing steps internally. We have further details on how to purchase an Apple certificate and register an App Store Connect ID in our full documentation.
This is a significant simplification of how Comet (and other software vendors) will be able to deploy macOS software going forward.
When using a Comet Server for the first time – or giving access to a reseller Tenant for the first time – Comet Server used to show a small text box with instructions on how to download the Comet Backup client app and run your first backup job. To help streamline this process, we've expanded this first-use guide into a larger sidebar that walks you through each step individually:
This guide appears the first time an admin logs into a new server and can be dismissed at any time. It walks you through all the first steps of running a Comet Server, including configuring storage settings, adding a first user account, downloading and installing the Comet Backup desktop client, ensuring the user account has registered a device and a Protected Item, and running a backup job.
The progress through these steps is refreshed automatically using a live connection to the Comet Server.
If you're an established Comet Server administrator, you won't see any changes in this area, but if you onboard new reseller Tenants or if you create a new Comet Server then we hope it helps you walk through the process a little more smoothly.
Once every quarter, we roll up all our Voyager development into a new long-term support release. The current quarterly release series, 22.2 "Elara" was planned for release in late February, and received one dedicated point release to fix issues over its lifetime. We are now closely approaching the end of its patch support period. You should expect to hear from us very soon about what's coming up next!
After each quarterly release gets superseded by another, the old quarterly release will receive ticket and critical support only, with most issues resolved by encouraging users to move to the current series.
"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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
