"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 February 2022.
Synology client installer
Comet Backup now has an SPK package installer available for Synology NAS devices. It supports both DSM 6 and DSM 7 firmware versions. This is a great way to ensure your NAS devices are backed up in a consistent way with all your other Comet infrastructure.
As with the existing Windows, macOS, and Linux Comet Backup client installers, you can get started with Synology by downloading your SPK package from the Comet Server downloads page.
Until now, it has been possible to install the Linux version of Comet Backup on a Synology device if you enabled SSH access to it. This was a complicated process, and upgrades to the DSM firmware would often cause the installed Comet Backup client to get deleted. Using the spk package avoids all these problems - the installation process is much simpler as your branded Comet client can be installed entirely via the Synology web interface through the package manager.
In DSM 6, Comet has full access to the system to back up and restore files. In DSM 7, Synology introduced a sandboxing system for packages to improve security. As a result, you will need to explicitly grant the Comet Backup app access to your storage volumes after installation. Please check the documentation closely when going through this process for the first time.
At this stage the new Synology installer is being released at no additional cost, but please note that we plan to introduce a Booster charge of $1 per Synology device starting April 15th 2022.
This has been one of our top feature requests on our Feature Voting page. We look at this system often to help guide our development priorities - if you've been using Comet Backup for a while and have some ideas about how we could improve the software, we would encourage you to make your voice heard and share any new ideas you have. Often multiple MSPs will rally together around an idea and refine it into something really wonderful.
The next time you look at the Comet Server web interface, you'll see a new search bar at the top of the screen:
This search bar allows you to quickly find user accounts by entering a few characters of their name.
The search bar will also find matching Storage Vaults and Protected Item. This is the first time it's been possible to find all matches of these by name from the Comet Server web interface. There are a few highly interesting scenarios that this enables - if you make good use of the Protected Item name fields, you can find all users backing up a certain product to troubleshoot them in bulk. Likewise if you are migrating storage platforms, finding all Storage Vaults named after your old platform might be very helpful.
For maximum productivity for keyboard users, you can focus the search field with Alt+Q, like Microsoft Outlook - and you can navigate through results with the arrow keys.
This request also came from our Feature Voting system, so I'd like to thank everyone who voted and commented on it for their advocacy and suggestions.
Single file restore from Disk Image
As of Comet 21.12.5, it's now possible to restore single files and folders from a Disk Image backup job. When you select a Disk Image backup job to restore, you'll see a new third option alongside the existing virtual disk (vmdk) and physical disk (partition) restore options:
If you select the new option, you can browse and restore single files and/or folders to restore:
This feature is accessible from either the Comet Backup desktop app or from the Comet Server web interface when remotely controlling a live-connected device.
The Disk Image backup in Comet produces a backup job snapshot containing a VMDK file that is a complete image of the raw partition data. When you restore single files, Comet will attempt to parse the backed-up VMDK files directly from the Storage Vault without spooling. If you intend to restore a large amount of files, the extra indirection makes this process slightly less efficient than restoring the entire disk image - but if you have only a few files to restore it is significantly more convenient, as you do not need to restore the entire disk image first. This reduces the total bandwidth and helps achieve your recovery time objectives.
Because Comet has to parse and process the filesystem within the VMDK file itself without relying on the operating system's filesystem drivers, we don't have exhaustive support for all filesystems. This feature currently only supports parsing the NTFS filesystem, and only regular file types, directories, symlinks, and EFS files. Other exotic NTFS object types, some types of reparse point, and other filesystems such as FAT, exFAT or ReFS are not supported yet by our built-in filesystem parser. However, this independent NTFS implementation does mean that restoring single files from a Windows disk image backup can be done on any Comet device platform, such as a macOS or Linux device logged in to the same account.
As of 21.12.8, this feature also integrates with the other restore options, such as restoring files directly to an archive (zip, tar, tar.gz, and sqfs) and performing test restores with the "download only, do not save" option.
Custom retention pass timing
Comet Backup allows you to configure retention policies to choose how long old backup jobs should be kept for. At some point, your retention policies have to be actually applied to the data in the Storage Vault; this is called a 'retention pass'. At the end of each backup job, Comet automatically considers whether it should run a retention pass.
Because the retention pass takes some additional time and system resources, often Comet will decide to skip running the retention pass until there's a sufficiently worthwhile amount of space that can be saved in your Storage Vault. The exact decision logic for this is more like an art than a science - we've got an excellent set of default settings, but as Comet grows larger we do find many users that are not well suited by our default settings.
If you do feel that the default behavior is not working well for you, then in Comet 21.12.x and later it's now possible to override the retention pass decision logic. You can choose this option as part of the advanced options for the backup job schedule, or, when running a backup job manually. There are four configuration options available:
The default setting is "Automatic" and is the same logic that Comet used in previous versions. When this option is selected, Comet uses a number of heuristics to determine whether to run a retention pass, based on the relative device performance compared to other devices in the account; the number of backup jobs in the Storage Vault that exceed the configured retention policy; and the time since the last retention pass. We have a full explanation of the rules in our documentation.
With the "Immediate" option, a retention pass will be run immediately at the end of every backup job, to completely enforce your retention policy. This is particularly helpful if your data set has a large amount of changes between incremental backup jobs, and you want to save as much space as possible in the Storage Vault at the expense of additional time to complete the operation.
The last two new options are "Run more often" and "Run less often". Like "Automatic", these options generally run retention passes after a few jobs or days have passed, but by explicitly setting "more often" and "less often" on your different devices within the same account, you can gain effective control over which device in the account is generally responsible for running retention passes.
If you have a low-powered laptop that's often put to sleep, and a high-powered always-online server with a lot of RAM both logged in as two devices in the same user account, then you can use these two options to encourage the high-powered device to do the retention pass work. Our "Automatic" logic does generally take uptime and system RAM into account in its decision making, but these options allow you to bias that decision in cases where you have a clearer understanding of the devices than Comet is able to determine automatically.
Two-factor TOTP codes without QR
Comet Server supports two-factor authentication using WebAuthn - such as U2F dongles and fingerprint readers - and also TOTP, the standard and widely-used system of six-digit codes that change every 30 seconds.
Like most other services using TOTP, Comet provides a QR code to scan to enroll for TOTP in your mobile authenticator app. However there are genuine situations where no camera is available to scan the QR code. The most pressing situation is when enrolling the TOTP code into an enterprise security app or password manager, from a desktop PC without a camera available. In this situation, it's possible to enter a text code instead of scanning the QR code.
This text code is now displayed when setting up TOTP in Comet Server 21.12.5 and later. It should make life easier for users of managed TOTP password managers - or just users who have dropped their phone and broken the camera!
Single snapshot identification (Advanced)
Sometimes in Comet, if your underlying storage platform experiences a data loss event, you may find that some of your backup snapshots within a Storage Vault are missing necessary chunks and can no longer be restored. In this case, the job report for a Retention pass normally mentions the exact IDs and filenames of the non-restorable snapshots to delete, in order to acknowledge and resolve the issue.
However when faced with this issue, many administrators might not have convenient access to the Storage Vault's data location in order to delete the affected files - for instance, if you are troubleshooting a customer's external harddrive backup that experienced some disk corruption.
In Comet 21.12.8, there's now a way to do this remotely from the Comet Server web interface. If you enable the "Advanced Options" toggle from your user menu in the top-right, then when going to restore data for an affected user, you'll see snapshot IDs and filenames listed directly alongside the snapshot option. This allows you to use Ctrl+F to find affected snapshots and select them for deletion via the 'Delete' menu option.
This feature has been available via the Comet Server API for some time, but having it as an option in the Comet Server web interface should make it much more accessible to the bulk of our partner base.
There's much more that's been happening in Comet - the admin homepage in the Comet Server web interface now loads faster when you visit it multiple times; the "Checking for free space" phase of backup jobs is now more resilient to network errors; the Thai translation has been significantly updated; the Comet Server web interface now visually shows icons for your Protected Items and Storage Vaults in more places; and many minor bugs and cosmetic bugs have been resolved. For more information, check out the full changelog.
Coming soon: New Quarterly release
Once every quarter, we roll up all our Voyager development into a new long-term support release. The current quarterly release series, 21.11 "Himalia" from late November 2021, received three dedicated point releases to fix minor issues over its lifetime, and 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.
Check back next month for our next regular update summary - you can subscribe by RSS to never miss an article - or check out our YouTube channel.
Mason Giles, CTO