Contact Us

To help prevent spam, Javascript is required in order for you to use this form.
Or schedule a call


Error "local error: tls: record overflow" 

This message means the connection was corrupted over the network, and Comet aborted the connection.

This can happen because of random network conditions. Retrying the operation should fix the issue.

If the issue keeps happening repeatedly, this message indicates that something is interfering with packets in your network.

  • Failing NIC
  • Bad NIC driver or driver configuration
  • Failing RAM, on either the endpoint machine or any of the intermediate routers
  • Outdated firewall or proxy, performing incorrect SSL interception

For more information, please see the record_overflow section in IETF RFC 5246.

"Paused" state on Windows service 

Comet Server on Windows consists of two parts: cometd.exe and cometd-service.exe. The latter binary is registered as a service with Windows, and is responsible for ensuring that the former binary stays running.

If Comet Server encounters an error and closes, the service binary will restart it. If the Comet Server is repeatedly unable to start - if it closes immediately when launched, several hundred times consecutively - then the service manager will assume the error is permanent and abandon restarting the process. This condition is displayed as the "Paused" state.

You can resolve this issue by resolving the underlying issue with the service. The error message should be recorded in Comet Server's log file.

You can view Comet Server's log files

  • in Comet Server Service Manager, use the Service menu > "Browse log files" option, or
  • by browsing the C:\ProgramData\Comet\logs directory.

Comet Server makes one log file per day. The error should be recorded in the most recent file (highest number in name / latest modification date).

Forgotten administrator password 

If you are locked out of the Comet Server web interface, you can change your administrator password by editing the cometd.cfg file.

  1. Stop the server, and edit the cometd.cfg file
  2. Find the AdminUsers section for the administrator user in question
  3. Set "PasswordFormat" to 0
  4. Set "Password" to e.g. "admin"
  5. Save the file and restart the server.

You should now be able to log in with the reset password. The password will be hashed and/or encrypted after first use.

Storage server "" in use by accounts but not managed by Constellation 

A user account has a bucket on a Storage Role Comet Server at the address, but this address was not selected for management by Constellation. Aside from the standard warnings about managing Constellation, the is a special case.

If Comet Server is configured to listen on all network interfaces, the server will be accessible on both as well as LAN, WAN, or DNS addresses. If you log in to either the Comet Backup application or the Comet Server web interface at, and request a new Storage Vault from a Comet Server configured as "Local" (or $self$ in cometd.cfg), the resulting Storage Vault will be configured using as the remote network address.

However, has a different meaning depending on where it is found. The connection will fail if the Comet Backup client is not running on the same machine. There may also be unintended consequences if the account is replicated to another server.

To avoid this problem, either

  • always use the external DNS name for your Comet Server when requesting new Storage Vaults, or
  • change the Request destination to use "Remote" with an external DNS name instead of "Local" (or $self$ in cometd.cfg).

A similar caveat applies to the software downloads, which can include embedded server address details.

Microsoft SQL Server backup encountered a VDI error 

You should ensure that the necessary VDI .dll files are registered and are the correct version for your SQL Server installation. You can use Microsoft SQL Server Backup Simulator to check the status of the VDI .dll files.

"Access is denied" backing up files and folders on Windows 

An "Access Denied" error message means that the Windows user account running the backup job does not have access to read the file content.

Comet 18.6.0 and later 

Comet automatically creates a service account with all necessary permissions to read local files. If you are experiencing "Access Denied" errors on Comet 18.6.0 or later, you may be trying to back up a network path that has been mounted as a directory. Please see the "Accessing Windows network shares and UNC paths" section below for more information.

If you are experiencing "Access Denied" errors on Comet 18.6.0 or later, and you are certain that you are not backing up a mounted network path, please contact support.

Comet 18.5.x and earlier 

In Comet 18.5.x and earlier:

  • Comet normally runs as the logged-on user session
  • If the Pre-logon service is enabled, Comet runs as a background session for the same user account
  • If the "take filesystem snapshot" option is enabled, Comet runs as LOCAL SYSTEM

You may be able to resolve this issue by:

  1. enabling the "take filesystem snapshot" option in the Protected Item settings, which switches to run the backup as the LOCAL SYSTEM user; or

  2. changing the permissions of the file, to give access rights to the specific Windows user account running the backup job; or

  3. using lusrmgr.msc to add the specific Windows user account to the "Backup Operators" group, which will allow Comet to bypass filesystem permissions (requires Comet 18.3.14 or later); or

  4. excluding the content from the backup job. This may be appropriate for some temporary directories or cache files; or

  5. upgrading to Comet 18.6.0 or later.

Antivirus detects Comet Backup as a virus or malware 

Comet Backup is a safe application. Any such detection is a "false positive".

When Comet Backup is rebranded, it might seem like a new, unknown program. An unknown program that installs system services, accesses files on the disk and uploads them to the network, might be considered to be malware if it was installed without consent. Unfortunately it's understandable for an Antivirus product to detect this.

In this situation, there are some actions you can take:

  • Please ensure your Antivirus product is fully up-to-date.
  • Please contact Comet Support with a screenshot of the error message. In some situations, it may be possible for our developers to resolve the issue.
  • Choose to "allow" or "white-list" the file in the Antivirus software. This may send a signal to the Antivirus software vendor that the software is safe (e.g. ESET LiveGrid, Windows Defender Automatic Sample Submission, Kaspersky KSN, etc).
  • Enable Authenticode signing on Windows. This may provide additional "reputation" to the software installer.

Avast "FileRepMalware" 

You will receive the "FileRepMalware" error message for any file that was

  • downloaded from the internet; and
  • does not have an Authenticode certificate; and
  • has not been seen yet by many Avast users.

Many custom-branded Comet Backup installers do fall into this category.

You can resolve this issue by purchasing and installing an Authenticode certificate.

Error message "backup-tool.exe couldn't be launched. CreateProcess() failed: Access is denied." 

This error message indicates that something on the PC is blocking Comet's main backup-tool.exe program from running. It's likely this is the antivirus. Please follow the above steps to whitelist Comet in your antivirus application.

Network connectivity errors 

Comet Backup uploads files to Comet Server (or to a cloud storage provider) over the internet. Occasionally, you may see errors such as the following:

  • Couldn't save data chunk:
  • HTTP/1.x transport connection broken
  • net/http: request canceled (Client.Timeout exceeded while awaiting headers)
  • wsarecv
  • wsasend
  • An existing connection was forcibly closed by the remote host
  • dial tcp: lookup [...]: no such host
  • connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

Comet Backup retries the upload several times, but eventually gives up. After a failed data chunk upload, you may see several more messages of the form Couldn't save data chunk: context canceled while Comet terminates the other upload threads.

Network errors have many possible causes:

  • Customer's PC
  • Customer's network
  • Customer's ISP
  • Internet-wide outages between customer's ISP and your ISP
  • Your ISP
  • Your network
  • Your Comet Server hardware
  • Comet Server software

To troubleshoot these issues, please check:

  • Does the backup succeed if it is retried?

    • Many network errors are temporary and will only occur rarely. In addition, a repeated second backup job will often run faster because many of the existing data chunks have already been uploaded. (Any unused data chunks in the Storage Vault will be automatically cleaned up by the next retention pass.)
  • Does the error message always happen at a certain time of day?

    • It may be possible to reschedule the backup to avoid times of heavy internet congestion.
  • Are there any corresponding messages for around the same time in your Comet Server logs?

    • This is important to determine the cause of some failures.
    • Some relevant Comet Server log messages take the form Error saving upload stream or Blocking re-upload of preexisting file

Accessing Windows network shares and UNC paths 

This section applies to both Comet Server and Comet Backup.

Comet can back up Windows network paths, and back up to Windows network storage (SMB / CIFS). However, because Comet runs as a service user, there are some issues with authentication to be aware of.

Please note that if you are using Comet Backup to back up data from a network device, you should prefer to install Comet Backup directly on the device instead of backing it up over the network. This will also significantly improve performance, as less data needs to be transferred over the LAN.

Mapped network drives 

On Windows, each logged-on user session has its own set of mapped network drives. The service user account is unlikely to have any mapped drives. If you see error messages like WARNING Missing: 'Z:\', this is probably the reason. You can work around this by using a UNC path instead.

Comet 18.6.5 and later will automatically convert mapped network drives to their UNC path equivalents.

For versions of Comet prior to 18.6.5:

  • In Comet Backup, when choosing items in a Files and Folders Protected Item, you can use the "Options" button > "Add " to browse inside a UNC path. Note that this browsing occurs as your logged-in Windows user, not as the service user, and may have different file access as a result. All backup jobs run as the service user.
  • In Comet Server, when configuring Local Path storage in the First Use Wizard, you can browse to a UNC path directly.


If the UNC share requires authentication, the service user account is probably not logged-in to the UNC share. If you see error messages like WARNING Lstat: CreateFile \\?\UNC\...: Access is denied., this is probably the reason.

Comet 18.6.5 and later have built-in options for setting Windows network authentication credentials.

For versions of Comet prior to 18.6.5, workarounds are available for both Comet Backup and Comet Server. Ranked in order of preference:

  • If you are using Comet Server to store data on a network device, you may be able to install Comet Server on the network device. If the network device is a NAS box (e.g. Synology / QNAP), Comet Server can be installed on Linux x86_64 NAS boxes.

  • If you are storing data on a network share, you can also work around this issue by switching from Windows network shares (SMB) to a network protocol that has built-in credential support. For instance, a S3-compatible server (e.g. the free Minio server) or an SFTP server.

  • In Comet Backup, you can work around this issue by adding net use \\HOST\SHARE /user:USERNAME PASSWORD as a "Before" command to the backup job.

    • If you are storing data on a UNC path, you can add this "Before" command on the Storage Vault instead of on the Protected Item. This will ensure it is run for all backup jobs going to that Storage Vault.
  • You can work around this issue in Comet Backup or in Comet Server by changing the Windows Service to use a different user account.

    • For Comet Server, this is the Comet Server service.
    • For Comet Backup 18.6.0 and later, this is the Comet Backup (delegate service) service.
    • For Comet Backup 18.5.x and earlier, this is the Comet Backup (dispatcher service) after you have enabled the Pre-Logon Service; and this change only affects scheduled, non-VSS backups only. Changing the Comet Backup (elevator service) will affect VSS backup jobs, but would also prevent remote software updates from working.
    • If you are using Comet on a Windows Server machine that is acting as the Domain Controller, you must choose a domain account.

DESlock+ VSS Error: Couldn't take snapshot "The specified object was not found" 

Some individual software, while it is launched from the within the users session, it may elevate itself when running or run under the System user account. If this happens, the encryption keys will not be available to that software's process and access will be denied to the containers.

Example scenarios where the above behaviour may be experienced are when software is running under a different user context within the users session. Comet runs the backup as a service user account (usually "NT SERVICE\backup.delegate" or "LOCAL SYSTEM" in some cases). The DESlock virtual drive is unavailable for other user accounts on the system.

It's possible to mount a virtual disk globally so all users on the system will be able to access its contents. This is done using the [DESlock+] command line tool

Follow DESlock's own instructions to mount the drive for all users.


Jobs left in Running state 

Comet Backup is responsible for closing-off a job log with Comet Server. If the PC is shut down unexpectedly, a job would be left in "Running" / "In progress" state indefinitely.

The old, inactive "Running" jobs will be cleaned up automatically if Comet sees an opportunity to prove that they are no longer running.

As of Comet 18.5.0, the following situations will clean up old, inactive "Running" jobs;

  • Running a retention pass
    • For safety reasons, a retention pass requires Comet to temporarily take exclusive control over a Storage Vault. Comet makes a number of checks to verify this exclusivity, but the practical benefit is that when a retention pass runs, all past backup jobs must no longer be running by definition.

A future version of Comet may automatically clean up Running jobs in additional situations.

Out of memory 

Comet Backup needs RAM to run. The main cause for this is to hold deduplication indexes; therefore the amount of RAM used is proportional to the size of the Storage Vault.

You might see these error messages:

  • runtime: VirtualAlloc of 1048576 bytes failed with errno=1455 on Windows
  • 0x5AF ERROR_COMMITMENT_LIMIT: The paging file is too small for this operation to complete. on Windows
  • fatal error: out of memory on all platforms

On Linux, when the system is out of memory (OOM), the kernel "OOM Killer" subsystem will immediately terminate a process of its choosing, to free up memory. If you see an error message like signal: killed in Comet on Linux, this means the process was terminated by a user or a subsystem, that might possibly be the OOM Killer. You can check for this in dmesg or kern.log.

You can reduce Comet Backup's RAM usage by trying to limit how much data is in each Storage Vault. For instance, instead of having multiple devices backing up into a single Storage Vault, create multiple Storage Vaults for each device. This will reduce the deduplication efficiency, but it will also reduce the necessary memory usage.

A future version of Comet may add options to trade-off memory usage in other ways. For instance, by using more temporary files on disk instead of more memory; or, by using more network bandwidth instead of more memory.

HTTP 500 in Comet Backup logs 

If you see an HTTP 500 error message in the Comet Backup logs, this means the server encountered an error.

If you see this while performing an operation to

  • Comet Server storage, then you should check the Comet Server log file for around the same timestamp, to see if there was a corresponding error on the server.
  • Cloud storage, then the cloud storage provider experienced an error at their end.
    • The error message may contain more detail; or
    • You can contact the cloud provider for more information; or
    • The operation may succeed if you retry it a short time later.

Change of hardware causes registration dialog to appear 

Comet detects the current device based on a hardware ID.

The hardware ID may be changed in some situations:

  • if you replace the motherboard or CPU; or
  • if you upgrade the BIOS / UEFI, without preserving hardware IDs; or
  • if you virtualise a physical server; or
  • if you migrate a VM guest to a different VM host, without preserving hardware IDs; or
  • if you install "sandboxing" software, or install certain PC security software that includes a "sandboxing" feature (e.g. Comodo Containment); or
  • if you make certain specific modifications to the operating system.

In these situations, the device's hardware ID will change, and Comet will recognise the PC as a new device.

Handling a changed device ID 

If your device is recognised as a new device, you should register it again.

The original backup data is still preserved in the Storage Vault, and will be deduplicated against any future backups from this device.

You can move the Protected Item settings from one device to another, by using the Copy/Paste buttons in the Comet Server web interface on the user's page > Protected Items tab.

The backup job log history will be preserved in the customer's account, but, it will be associated with the old device.

  • Once you de-register the original device, it would show as "Unknown device (XXXXX...)" in the job history.

  • The customer can still see these old jobs in the Comet Server web interface.

  • The customer can still see these old jobs in Comet Backup if they use the filter option > "All devices".

Because the device is detected as a new device, the billing period for this device will be restarted.

Storage Vault Locks 

Lock files are an important part of Comet's safety design. Comet uses lock files to ensure data consistency during concurrent operations.

Problem statement 

Comet Backup supports multiple devices backing up into a shared Storage Vault simultaneously. But when Comet runs a retention pass to clean up data, it's very important that no other backup jobs are running simultaneously.

A retention pass (A) looks at what data chunks exist in the Vault, then (B) deletes the unused ones.

A backup job (A) looks at what data chunks exist in the Vault, then (B) uploads new chunks from the local data, and uploads a backup snapshot that relies on both pre-existing and newly-uploaded chunks.

It's perfectly safe for multiple backup jobs to run simultaneously, even from multiple devices.

But, it is not safe for a retention pass to run at the same time as a backup job, because if the steps are interleaved (retention A > backup A > retention B > backup B) then a backup job might write a backup snapshot that refers to unknown chunks, resulting in data loss.

Comet must prevent you from running a backup job and a retention pass simultaneously.

Lock files 

In order to check whether a retention pass is currently running, Comet must communicate between all devices that could potentially be using the Storage Vault.

In order to determine whether any other device is actively using a Storage Vault, Comet writes a temporary text file into the Storage Vault, and deletes it when the job is completed. This is the only mechanism supported across all Storage Vault types (i.e. local disk / SFTP / S3 / etc). Then, any other job can look for these files to see what other operations are taking place concurrently.

Jobs in a Storage Vault are classified into two categories:

  • Exclusive (retention passes)
  • Non-exclusive (backup/restore jobs)

Multiple non-exclusive jobs may run simultaneously from any device. A non-exclusive job will refuse to start if any exclusive jobs are currently running. An exclusive job will refuse to start if any other jobs are running.


  • If a backup job is currently running, Comet will refuse to start a retention pass.
  • If a retention pass is currently running, Comet will refuse to start a backup job.

Downsides of lock file design 

If Comet is stopped suddenly (e.g. PC crash), the lock file would not be removed. All other Comet processes would not realize that the job had stopped. This could prevent proper functioning of backup jobs and/or retention passes.

Comet will alert you to this issue by failing the job. The error message should explain which device and/or job was responsible for originating the now-stale lock file.

You may see error messages of the form:

  • Locked by user '...' on this device (PID #...) since ... (... days ago)
  • Locked by user '...' on computer '...' (PID #...) since ... (... days ago)
  • However, the responsible process might have stopped.
  • If you investigate this process, and are absolutely certain it won't resume, then it's safe to ignore it and continue.

It is possible to delete lock files to recover from this situation. However, it is critical that you manually investigate the issue to ensure that the responsible process really has stopped. Consider that a PC may go to sleep at any time, and wake up days - or weeks - later, and immediately resume from the middle of a backup or retention operation; if the lock files were removed incorrectly, data loss is highly likely.

If you are sure that the responsible process is stopped, you can delete the lock files.

You can initiate this either

  • in Comet Backup, on the "Account" pane > right-click Storage Vault > "Advanced" > "Clean up lock files" option
  • remotely via the Comet Server web interface (when logged in as an administrator). First, enable the "Advanced Options" from the user menu in the top right; then, perform the unlock action via the Connected Devices Actions dialog.

Automatic unlock 

Comet Backup will automatically delete stale lock files when it determines that it is safe to do so.

  • When Comet is running on the same PC as a potentially-stale lock file, it can check the running processes to see if the originator process is still running.

A future version of Comet may be able to automatically detect and remove stale lock files in more situations.

Recovering from unsafe unlock operations 

If you encounter a Packindex '...' for snapshot '...' refers to unknown pack '...', shouldn't happen error, a data file has been erroneously deleted inside the Storage Vault. Data has been lost. This can happen if the "Unlock" feature is used without proper caution as advised above.

In this situation, you can recover the remaining data in the Storage Vault by following the instructions in the "Recovering from file corruption" section above.

Backup process stalled on "Preparing Storage Vault for first use" 

The first step on accessing a new, uninitalised Storage Vault is to generate and store some encryption material.

If a backup to a new Storage Vault seems to hang at this initial step, it's likely that Comet Backup is failing to access the storage location, and repeatedly retrying- and timing-out. An error message may appear after some extended duration.

Some possible causes of this issue are

  • Storage Vault misconfiguration
    • For Storage Vaults located in a Comet Server bucket, check the Storage Vault properties > "Hostname" field, that it points to a valid URL and not e.g.
  • Outdated CA certificates
    • This would prevent Comet Backup from making an HTTPS / SSL connection to the storage location
    • On Windows, run Windows Update
      • For Storage Vaults located in a Comet Server bucket, you can also check if the system Internet Explorer browser is able to load the Comet Server's web interface
    • On Linux, update the ca-certificates package

"Media is write protected" backing up OneDrive with VSS 

To save on disk space, OneDrive (and some other cloud storage providers) now uses a system where some files are only "virtually" stored on the local disk, and are materialized from the cloud storage on-demand.

When you use the "Take filesystem snapshot" option in Comet, Comet takes a VSS snapshot of the disk. This is a read-only snapshot.

When you back up the OneDrive directory with VSS enabled, OneDrive is not able to download files into the snapshot, because the snapshot is read-only. This causes the "Media is write protected" error message.

In this situation, your OneDrive data is not being protected by Comet and is not available for restore.

You can workaround this issue by creating two Protected Items: one with VSS enabled, that excludes the OneDrive directory; and a second one with VSS disabled, that only includes the OneDrive directory.

Note that if OneDrive needs to materialize a lot of data from the cloud, then backing up the OneDrive directory may cause a lot of data to be downloaded.

A future version of Comet may avoid this issue by automatically disabling VSS for the OneDrive directory.

"An attempt was made to access a socket in a way forbidden by its access permissions" in Comet Server 

This error message occurs when configuring Comet Server on Windows to listen on an IP/port combination that is either (A) forbidden by the firewall, or (B) in-use by another application. Usually this affects port 80 or 443.

The following troubleshooting guidance is available:


One possibility is that the system firewall is preventing Comet Server from binding to this IP/Port. Comet Server automatically makes a firewall exception for itself in Windows Firewall.

  • Is a third-party firewall installed, that could be preventing Comet Server from binding to this IP/port?

In use by other application 

  • Is there any website visible when you browse to the IP/port in a web browser?

  • Is IIS installed?

If you open Command Prompt as Administrator and run netstat -o, it shoudl list all the open network connections.

  • Can you check if any process is using the affected port (e.g. :80), and compare the PID in Task Manager to find the process?

If the affected process is "SYSTEM" (PID 4), then the http.sys driver is responsible for binding the port. The network system from IIS (http.sys) is also a necessary component of some other Windows features and may have been installed automatically.

You can run net stop http to stop the driver and all the services that are using it.

Some common services that use this driver are

  • World Wide Web Publishing Service (IIS)
  • "Web Deployment Agent Service" (MsDepSvc service)
  • "SQL Server Reporting Services" services
  • Windows Remote Management (WS-Management service)

If you discover the services are essential, you could work around this issue by

  • configuring Comet Server to listen on a different port; or
  • configuring Comet Server to listen on a different port, and use NAT translation to make it seem like the in-use port to the outside world; or
  • configuring Comet Server to listen on a specific interface or a different IP address.

"too many open files" on macOS 

A file handle is an abstract concept that includes network connections, temporary files, and disk files. macOS has a fixed limit on the number of open file handles for each running process, and also for the whole OS. You can check the current limits via the sysctl kern.maxfiles and sysctl kern.maxfilesperproc commands; at the time of writing, the values were 10240 and 12288 respectively.

If you experience the too many open files error message, this means Comet is either

  • (A) running at the same time as another process with high file-handle usage; or
  • (B) using an excessive number of file handles

You can check the current file-handles currently in use for the whole OS by running: lsof | wc -l.

During a backup job, Comet uses approximately

  • approximately 10-20 handles for files being read from the disk; and
  • approximately 10-20 handles for open network connections; and
  • an unknown number of temporary cache files created during the "Building cache" phase

You may be able to work around this issue by

  • raising the kernel file handle limit; or
  • ensuring no file-intensive processes are running at the same time as the Comet backup; or
  • ensuring multiple Comet backup jobs are not running simultaneously; or
  • for "File and Folder" protected items, by enabling the "Rescan unchanged files" option. This reduces the number of temporary files that Comet uses for local caching.

A future version of Comet may redesign the cache mechanism to use fewer local temporary files.

"Couldn't decrypt Vault contents" error message in job reports 

Comet tried to access the Storage Vault, but it contained data using an unknown encryption key. Probably this Storage Vault is using the same data location as another Storage Vault (from the same- or a different- user account).

Each Storage Vault in a user's profile is automatically encrypted on first use, with a randomly generated key. If you reuse the data storage location that was already used by another user's Storage Vault, Comet would not know the encryption key for the Storage Vault, and would be unable to access it.

If you intended to share the same Storage Vault between multiple users, you should log their devices into the same account. Otherwise, you should use a different physical location for each Storage Vault.

"permission denied" error when restoring from a Local Path Storage Vault on macOS 

In Comet Backup for macOS since 18.6.x, when you create a local path Storage Vault, the files are created by a background service account, using its own file permissions.

However, in current (18.8.x) versions of Comet, restores are performed as the normal user account. Your normal user account may not have the necessary permissions to access the local path folder if it was created by the background service account.

You may see error messages of the form:

  • Couldn't retrieve a list of snapshots from this Storage Vault
  • Couldn't connect to Storage Vault: Can't access Storage Vault: Open: open *YOUR-STORAGE-VAULT-DIRECTORY* : permission denied

To fix this, use "Get Info" on the Storage Vault's folder to change permissions to allow for read/write, and use the cog menu to choose 'Apply to enclosed items...'.

A future version of Comet may solve this problem by automatically setting file permissions.

"A specified logon session does not exist. It may already have been terminated" error message accessing a Windows network share (SMB) 

Some SMB servers don't seem to accept multiple SMB login sessions, if they use the same SMB credentials from the same host from different Windows user accounts.

On Windows, each user session has its own set of network login sessions. Comet performs the backup using a service user account. Therefore, this issue could occur with an affected SMB server if the interactive Windows user was logged in to the network share simultaneously.

Known affected SMB servers 

If you are experiencing this issue, please contact support so that we can document any affected OSes and versions.

This issue is known to affect some Synology NAS devices.

  • Is your Synology DSM version up-to-date?

Verifying the issue 

The "Run as Administrator" session also has its own separate network login sessions.

  • Are you able to browse the network share from both an elevated and unelevated application? (e.g. "File > Open" from notepad and from a notepad launched with "Run as Administrator")

The interactive user account may have an open network session to the affected device.

  • From a command prompt, can you run net use to see if the interactive user is logged in to the network share?

  • From a command prompt, if you run net use \\server_name\share_name /DELETE to log the interactive user out of the network share, does this allow the backup to proceed?

    • Note that this may cause the same error to affect the interactive user. You may have to run this same command as an After command in the backup job, to log the background service account out of the network share, so that the interactive user can log back in.


If you are backing up from the SMB server, you could work around this issue by

  • installing Comet Backup directly on the network device (e.g. for Synology, enabling SSH access and install the command-line Linux version), to back up the files directly. This may have significantly better performance, as less data needs to travel across the LAN and the disk access latency is significantly improved.

Alternatively, by

  • logging the interactive user account out of Windows entirely before the job starts. This will close their network sessions. Comet will successfully log in to the network share; you should add net use /DELETE as an After command in Comet to ensure the service user logs out again after the backup

Alternatively, by

  • logging the interactive user account out of the network share before the job starts, and logging them back in afterward. You may be able to use Windows Task Scheduler for this with the "Run only when user is logged on" option to ensure that the commands run inside the correct logon session:
    • net use /DELETE in Task Scheduler before the backup window, to log the interactive user out
    • Enter network credentials in Comet, so the service user logs in
    • net use /DELETE as an After command in Comet, so the service user logs out
    • net use in Task Scheduler after the backup window, to log the interactive user back in again

If you are backing up to the SMB server, you could work around this issue by

  • enabling the SFTP system, or the Minio S3-compatible app, and configuring your Storage Vault to use that instead. These protocols support explicitly entering credentials, that should avoid this issue.

"The term Get-VM is not recognized" error message or "Please install 'Hyper-V Module for Windows PowerShell'" in Hyper-V backups 

The Hyper-V Module for Windows PowerShell must be installed to use this feature. You can install this module from PowerShell or from Windows Server Manager.

You can install the module from PowerShell by running Install-WindowsFeature -Name Hyper-V-PowerShell.

You can install the module from Windows Server Manager, in "Add Roles and Features", in "Features".

For Windows Server 2016, the feature checkbox is located under "Remote Server Administration Tools" > "Role Administration Tools" > "Hyper-V Management Tools" > "Hyper-V Module for Windows PowerShell".

Multiple devices are detected as being the same device 

Comet tells machines apart by their "device ID". This is automatically determined from a mix of hardware and software identifiers.

One possible cause of this issue is if the two VMs were originally clones of each other. If you have cloned a VM in the past, it might have the same hardware and software identifiers, and so appear to Comet as the same device.

If multiple devices appear to Comet as the same device, they will share the same Protected Items and job scheduling. This causes follow-on issues for logging and reporting.

You can resolve this issue by changing the hardware or software ID for the affected VM. This will influence Comet's device ID to force the devices to be detected as different devices.

On Linux, the SSH host keys are one signal that influences the generated device IDs. Installing SSH, or regenerating the SSH host keys, will cause the device ID to change.

On Windows (with Comet 18.9.9 or later), you can add extra data to influence the generated device ID by creating a registry key.

  1. Open Registry Editor (regedit.exe)
  2. Browse to the HKEY_LOCAL_MACHINE\Software\cometbackup folder key, creating it if it does not already exist
    • The HKEY_LOCAL_MACHINE\Software\backup-tool folder key is also recognized (with Comet 18.12.2 or later)
  3. Create a "String Value" with name DeviceIdentificationEntropy
  4. Set any random text as the Data value. This value will influence the generated device ID.
  5. Restart all Comet services (e.g. backup.delegate and backup.elevator)

"ciphertext verification failed" error when using a Storage Vault 

This error message can occur either immediately, when running any backup or restore operation; or, it can occur part-way through a job.

Error occurs immediately 

If this error message occurs immediately, it means Comet was unable to connect to the Storage Vault at all, because the encryption key in the user's Storage Vault settings does not match the files in the /keys/ subdirectory in the data storage location.

When a Storage Vault is used for the first time, Comet generates a random encryption key, and stores it in an encrypted form in both (A) the user's profile, and (B) in the /keys/ subdirectory in the data storage location. It's important that these match at all times. If they do not match, Comet will be unable to use the data inside the Storage Vault.

You may potentially encounter this issue in the following situations:

  • If the first time this Storage Vault was used, multiple backup jobs ran simultaneously

    • The first-time initialization make take a few seconds. If multiple initialization jobs were running simultaneously, this may have caused a conflict when saving the encryption key into the user profile
  • If you were performing a Seed Load, but...

    • created a new Storage Vault in the client instead of reusing the existing one; or
    • did not copy the /keys/ subdirectory or the top-level config file; or
    • misconfigured the "subdirectory" or "path" option in the Storage Vault settings
  • If you change the Storage Vault location to point to another user account's Storage Vault

    • Data locations cannot be simply reused by multiple user accounts - the other user account would have a different encryption key. If you want to share a single data storage location between multiple customers, you should have both customers log in to the same account as devices, so that they can share the Storage Vault settings including the encryption material.

Error occurs part-way through a running job 

This indicates that a file inside the Storage Vault is corrupted. Please run a "Deep Verify" action on the Storage Vault, and see the "Data validation" section in the Appendix for more information.

Low performance when backing up to an external USB drive on Windows 

Please use a benchmarking tool to determine the expected performance of the USB drive independently of Comet, as a baseline to compare against Comet's performance.

Performance mode in Comet 

There is an option in Windows to control whether USB drives are configured for "Quick removal" (default) or "Better performance". Switching to the latter mode can significantly improve performance, but requires you to safely eject the drive.

To change this setting

  • Open Device Manager > Disk drives > Properties > Policies tab
  • If the "Quick removal" / "Better performance" radio option is available, ensure it is set to "Better performance"
  • If the "Enable write caching" checkbox option is available, ensure that it is enabled

Error "not a supported backup storage location" backing up System State to a USB flash drive 

The "Windows Server System State" and "Windows System Backup" Protected Item types in Comet inherit some restrictions from the underlying technology (wbadmin).

It's not officially possible to spool the backup job to a USB flash drive:

"You cannot store backups on USB flash drives or pen drives." -

This is a preventative measure in case the drive is removed mid-backup.

The following workarounds are available:

  1. Modify the flash drive to appear as a non-removable disk

For more information, please see

  1. Create a shared network directory on the flash drive, and tell Comet to use the UNC network path as the spool directory instead

For more information, please see