Comet supports backing up Windows network shares (SMB / CIFS). However, you should prefer to install Comet Backup directly on the network device; this will offer increased backup performance.

On Windows,

The "Choose Items" dialog lets you browse through mapped network drive letters. You can also use the "Options > Browse UNC Path" option to directly browse a UNC path.

Comet 18.6.5 and later support entering custom Windows Network Authentication credentials via the "Log in to network share" option. If you select a network share for backup, you may need to enter custom credentials in order for the service user account to access the network share.

Because mapped network drives are private to a user session, Comet Backup automatically converts mapped network drive letters into their UNC path equivalent, so that it can still be accessed by the service user account.

Filesystem snapshot's (VSS) do not work for network shares, be sure to disable the option 'Take filesystem snapshot' on the protected item.

Comet 18.6.7 supports backing up EFS-encrypted files on Windows. The files will be silently decrypted if possible (e.g. if Comet Backup is running as the encryption user, or if Comet Backup is running as the EFS Recovery Agent user).

If it is not possible to automatically decrypt the file for backup, Comet will back up the file in its encrypted form, and will only be able to restore it in its encrypted form. EFS-encrypted files are displayed with green text in the Restore browser dialog in Comet Backup.

If you have a PC failure, the EFS encryption keys may be lost. In this situation, the EFS-encrypted files may be unusable, even after restoring from backup. Comet warns you about this situation by adding a warning message in the backup job log.

In order to safely prepare for this scenario, you should export the PC's EFS encryption keys, so that the files can be accessed after a PC failure. On Windows, you can do this via certmgr.msc; or on Windows Server, taking a System State backup may be sufficient.

Once you have safely backed up the PC's EFS encryption keys, you can suppress the warning in Comet Backup by enabling the "I confirm EFS keys are exported" option.

Windows Server 2012 and later have a data deduplication feature that is separate- and unrelated- to Comet's own deduplication, that can be used to increase free disk space on NTFS volumes. A scanning process runs in the background to find and merge duplicate file content. By default, the scanning process runs overnight.

Deduplicated files look and behave like normal files; however, they are stored on disk in a special format, that can only be read by Windows Server (and Linux). Non-Server versions of Windows are entirely unable to read these files from disk.

When backing up deduplicated files with Comet, it backs up the full (rehydrated) file content, and then applies its own deduplication to it. This means that Windows Server deduplicated files can be safely restored to non-Server versions of Windows.

When restoring deduplicated files from Comet, the files are restored in their full (rehydrated) format, and are not re-deduplicated until Windows runs its next background scanning pass. This means that you may not have enough free disk space to completely restore a Comet backup to the same source drive.

Comet can exclude files based on a regular expression (regex). Any files matching the regular expression will be excluded from the backup job. The specific syntax flavour is that of the Go regexp library.

The regular expression is tested against the full disk path to the file. This enables filtering by path component, or (on Windows) drive letter.

By default, the regular expression is

case-sensitive. You can perform a case-insensitive match by adding an (?i) expression

non-anchored. You can restrict your regex to the start- or end- of the file path by using the ^, $, \A and/or \z expressions.

Forwardslash (/) is not a special character and does not require escaping with \/.

In a regular "Files and Folders" backup, Comet will skip over files that have the same file size and modification time as the last backup job. If these properties are the same, Comet will refer to previous chunks and not re-chunk the file. This dramatically improves performance.

If you are working with certain types of files that change content without updating their modification time attribute on the filesystem - for instance, applications that use direct disk I/O instead of filesystem functions; some database data files; or VeraCrypt container files - then the above is obviously unsatisfactory for ensuring backup integrity. In this case, you can enable the "Rescan unchanged files" feature to cause Comet to chunk every encountered file. This has some performance penalty but does ensure backup integrity in the presence of such files.

The "Program Output" backup type backs up the stdout (Standard Output) stream of any command execution. This stream data is saved as a virtual file within the backup job. You can choose the virtual file name.

The data is streamed directly to the backup destination and never touches the local disk. This has the consequence that no progress bar or ETA can be calculated or displayed during backup jobs.

If the target application produces any content on stderr (Standard Error), it will be logged in the job report, and the final job status will not be less severe than "Warning".

If the target application exits with a non-zero error code, the error code will be logged in the job report, and the final job status will not be less severe than "Error".

This Protected Item type backs up Microsoft Exchange Server databases. The underlying technology is VSS and is compatible with Microsoft Exchange Server 2007 and later, including Exchange Server 2016 (the latest version at the time of writing).

The appropriate VSS writer must be installed.

As Exchange Server can only be installed on Server SKUs of Windows, this backup type is only applicable when running on Windows Server.

Some forms of Exchange Server backup will cause log truncation to occur on the Exchange Server. For more information, please see the official Exchange Server documentation. If circular logging is enabled on the Exchange Server, the 'Incremental' and 'Differential' backup types have limited effect.

Exchange Server 2010 and newer are supported since Comet 17.1.0 Beta. Comet 17.9.7 extended the support back to Exchange Server 2007.

By default, Exchange 2007 does not enable the VSS writer. The VSS writer may have been enabled by another backup system installed on the PC.

If you encounter error messages like Couldn't find Exchange Server installation on this device or Failed to perform VSS snapshot on a machine running Exchange 2007, the Exchange VSS writer (MSExchangeIS) may not be enabled.

You can confirm whether this is the case by checking for Microsoft Exchange Writer in the output of vssadmin list writers, or, in the Browse dialog for a new "Application Aware Writer" Protected Item.

You can manually activate the Exchange VSS writer by making the following steps:

Open regedit and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Using this Protected Item type may incur a per-hypervisor Booster charge.

This Protected Item type backs up Microsoft Hyper-V virtual machines. The underlying technology is VSS and is compatible with all versions of Hyper-V running on Windows Server, including Windows Server 2016 (the latest version at the time of writing).

This backup type is only applicable when running on Windows Server. Hyper-V on Windows Desktop is not supported by this Protected item type.

Comet integrates with the Hyper-V VSS writer to perform a Hyper-V backup snapshot, including support for in-VM quiescence on supported guest operating systems.

Backing up a Hyper-V virtual machine with Comet includes, but is not limited to:

its configuration file

all attached virtual drives

the contents of memory (if the machine was running)

the full tree of saved checkpoints

You can select individual virtual machines for backup, or choose "All virtual machines".

The following information applies to all products that perform Hyper-V backup.

When backing up a guest VM, it's important to get a consistent state of the VM. There are some different ways this happens.

If the guest OS has all necessary Hyper-V integration services installed, then the host can request for the guest VM to take a VSS snapshot. The snapshot is then exposed to Hyper-V on the host for Comet to back up. It shouldn't interrupt the guest OS. The VM backup is application-consistent.

If the host OS is running Server 2012 R2 or newer, but there are no integration services inside the guest OS, then Hyper-V will take a checkpoint of the VM; Comet will back up the checkpoint; and then the checkpoint will be removed. This kind of checkpoint does not interrupt the guest OS. The VM backup is crash-consistent.

If the host OS is older than Server 2012 R2, and there are no integration services inside the guest OS, then the VM will be paused; Windows will take a VSS snapshot of Hyper-V's files in paused state; the VM will be resumed and Comet will back up from the VSS snapshot. It would cause a short interruption to the guest OS. The VM backup is crash-consistent.

The following information applies to all products that perform Hyper-V backup.

If you are using Hyper-V replication, you can back up your virtual machines from either the primary or replica host.

A backup taken on the primary VM host is application-consistent (if possible), by quiescing a VSS snapshot inside the VM guest; or crash-consistent otherwise. However, a backup taken on the secondary VM host is only ever crash-consistent, because the replica VM is not running in order for guest integration services to take a VSS snapshot.

Current versions of Hyper-V do not allow backing up a VM that is currently replicating. If a VM is found to be currently replicating at the time of backup, Comet will retry the operation a few times. If you repeatedly see errors of the form The virtual machine '...' cannot start a backup operation because it is currently executing a conflicting operation. Try the backup again., and you are running backups from the replica VM host, you could consider

scheduling the backup job to run at a time when it's more likely that the VM replication is up-to-date; or

using Before / After commands in Comet to temporarily stop VM replication while the backup job is running.

The following information applies to all products that perform Hyper-V backup.

Hyper-V supports passthrough disks, to attach a physical disk from the host directly into the guest VM. This unmounts it from the host OS.

Hyper-V itself does not support backing up passthrough disks (nor does it support replicating them). A Hyper-V backup of the guest machines can be taken from the host, but does not include any data from passthrough disks.

You can work around this issue by either

installing Comet Backup inside the guest VM, and backing up the extra data at a file level (this will use an extra Device license); or

changing your passthrough disks to be a real disk containing a large .vhd or .vhdx file. The "New Virtual Disk Wizard" in Hyper-V Manager has an option to convert an existing disk to a .vhd or .vhdx file.

This Protected Item type backs up a Microsoft SQL Server database. The underlying technology is VDI and is compatible with SQL Server 2005 and later, including SQL Server 2016 (the latest version at the time of writing).

No data is spooled to the local disk. As per the "Program Output" type, no progress bar or ETA appears during a Microsoft SQL Server backup.

Databases are backed up one-at-a-time. If you require point-in-time consistency across multiple databases, please use the "Application-Aware Writer" option instead.

Connection details should be supplied before selecting databases. Comet will only connect to SQL Server running on the local machine. You must enter the instance name, or leave the field blank to use the default instance.

The address is always localhost, but Comet does not use TCP addresses or TCP ports to connect to SQL Server instances. Comet uses "Shared Memory" to connect to SQL Server instances.

Comet's use of "Shared Memory" connection does improves performance for some operations, at the expense of only working on the local machine; but Comet's use of VDI requires it to run against the local machine anyway.

If you encounter issues connecting to your SQL Server, you must ensure that "Shared Memory protocol" is enabled in SQL Server Configuration Manager.

Comet allows you to connect to SQL Server using either Windows authentication (running as the backup service account - usually NT SERVICE\backup.delegate or SYSTEM), or native SQL Server authentication.

If you are using Windows Authentication, the connection occurs as the backup service account.

You can assign this Windows user account to have sysadmin rights within SQL Server.

If you are using SQL Server authentication, you must enter a valid username and password to connect to SQL Server.

Impersonation is not currently available for Windows authentication. Future versions of Comet will support impersonation for Windows authentication.

Comet supports backing up multiple instances from SQL Server. You can select an instance for backup, by entering the instance name in the "Instance Name" field. Leave this field blank to use the default instance.

Comet Backup 17.6.3 automatically lists available instances for selection in the drop-down menu.

A future version of Comet will make the instance dropdown list available for remote administration in Comet Server.

You have the option to use SQL Server's own differential/log backup system. This may be more efficient, but it does require additional administrative work, and complicates the process of restoring data.

The SQL Server maintains one single point-in-time reference, from which it can produce differential backups and/or log-based backups. When you take a new "Full (base image)" backup, the point-in-time reference is moved forward, so that any future differential and/or log-based backups are based on the last base-image backup.

To use SQL Server's own differential/log backup system, you must create multiple Protected Items (each with a different schedule) in order to capture both a base image and a differential/log backups. By creating multiple Protected Items, you can individually schedule, report-on, and manage retention policies for both base and differential/log backups.

If you are using Comet alongside another product for SQL server backups, you should ensure that only one product is taking base-image backups. Otherwise, it's possible that a chain of differential/log backups would be incomplete.

Prior to Comet 18.3.3, this option was labelled as "differential base image".

Comet can use SQL Server's own systems for differential backup. In this mode, you can regularly make "differential base" backups, and then a series of small "differential increment" backups, each containing the difference from the last base backup. These operations are equivalent to the BACKUP and BACKUP WITH DIFFERENTIAL T-SQL statements respectively. Comet will still deduplicate multiple base backups that are sent to the same Storage Vault.

You can opt to use SQL Server's own systems for log backup. In this mode, you must periodically take full (base image) backups, and regularly take log backups.

You have the choice of whether to apply log truncation. These operations are equivalent to the BACKUP LOG and BACKUP LOG WITH NO_TRUNCATE T-SQL statements respectively. Comet will still deduplicate all data that is sent to the same Storage Vault.

To use SQL Server's own log system, you must create multiple Protected Items (each with a different schedule) in order to capture both full and log backups.

You can use Comet's "Commands" feature to call osql/sqlcmd to run a T-SQL BACKUP statement against the database, and then back up the resulting spooled file with the "Files and Folders" type. This option requires more temporary disk space than the built-in system above.

You can use the "Application-Aware Writer" type to back up SQL Server using the VSS Writer. Compared to Comet's standard VDI approach, this option enables more detailed progress information, and can take a consistent point-in-time snapshot of multiple databases at once; but offers more limited control over SQL Server features such as log truncation. The resulting files also must be restored in a different way.

You can use the "Files and Folders" type to back up individual database files if the "Take filesystem snapshot" option is selected. However, the "Files and Folders" backup type does not invoke SQL Server's VSS writer, so this would (at best) produce a "crash-consistent" backup and is not recommended.

Comet Backup integrates with Windows Server System State to support backing up System State .vhd files using the wbadmin technology. This feature is only available on certain versions of Windows Server with the "Server Backup Role" feature enabled.

A Windows Server System State backup may include Active Directory, boot files, the COM+ registration, the system Registry hive, and/or other system files.

A local path must be used for spooling temporary data. Spooled temporary data will be removed once the backup job completes. The selected path

must be a bare root drive, and

must support VSS, and

must have at minimum 10GB free space, and

must not reside on a "critical" volume (unless KB944350 has been applied).

For more information about Windows Server System State backups, please see

Note that because wbadmin is used, spool space is required. As an alternative, you can back up System State by using the "Application-Aware Writer" Protected Item type. This produces a similar result, but

no spool space is required; and

the files are not collected in a .vhd file. This may produce better deduplication at the expense of missing bootloader files.

Later versions of the Windows install media are able to recover vhd files of older versions of Windows, and may have better driver support. If you experience problems recovering a .vhd file using the Server 2008 install media, consider trying with install media from a newer version of windows.

Alternatively, the .vhd file can be attached to a virtual machine, or manually written out to a physical volume.

In these situations, because the .vhd is a data-only file, you may need to manually recreate the NTLDR bootloader (using the bootsect and bcdedit commands) before the machine can be booted.

Note that the disk image is not pre-prepared for hardware independence. An operating system image may only mount on identical- or highly-similar hardware. This issue originates from the wbadmin "Windows System Backup" technology and is not specific to Comet's implementation. You may find more information online.

VSS is a technology for taking a consistent point-in-time snapshot of a disk volume. A VSS Writer is an extra software plugin that detects when this action is taking place and ensures that application-specific files are in a safe state on disk. Comet's "Application-Aware Writer" feature allows you to invoke a single VSS Writer, or a sub-component of a single VSS Writer, and back up only the files that it was protecting.

This is also an important third-party integration point for application vendors. If your third-party application includes a VSS Writer, you can use this Protected Item type to back it up using Comet.

Some products that can be backed up with this Protected Item type are:

This feature was added in Comet 17.6.1. In versions of Comet before 18.3.13, the Protected Item type was named "VSS-Aware Component".

NOTE: This Protected Item type is intended for integration with specific custom applications. If you want to back up normal files with a VSS snapshot, use the "Files and Folders" Protected Item type with the "take filesystem snapshot" option enabled.

In Comet Backup, click the Edit button (pencil icon) to browse the available VSS Writers installed on your device.

You can select the top-most checkbox to include all components within the VSS Writer, or you can select individual components within the VSS Writer. For instance, the Microsoft SQL Server VSS Writer allows you to select individual databases for backup.

The VSS Writer itself may mark some components as non-selectable. This is shown in Comet as a grey subcomponent without a checkbox.

You can perform the operation in "VSS Full", "VSS Copy", "VSS Incremental", or "VSS Differential" modes. If a specific VSS Writer does not support the selected backup mode, it will perform the backup in "Full" mode.

The actual behaviour of these modes is specific to each VSS Writer. For more information, consult the documentation for your VSS Writer.