Cloud Backup FAQ

The following restore and recovery options are supported:

• Local and Network Files
• Files inside Hyper-V Guests
• Exchange Server (entire databases)
• Exchange Granular Restore (.edb)
• SQL Server (entire databases)
• Full VM Recovery (from the Recovery tab)

Cloud backup does NOT support:

• Rapid VM Recovery
• Bare-metal backup and recovery
• SQL point-in-time

All data is encrypted on the local machine that BackupAssist is installed on prior to it being transferred over a secure connection to the cloud provider you’ve chosen as your destination. Because this is BackupAssist's own encryption, the cloud provider cannot access the backup, or even see what data you backed up. In addition to this, the cloud service provider will apply its own encryption to the cloud container to further protect the backup.

In addition to this, your files are also password protected and there is no way to access your data without this password. It is recommended you do not share this password.

Warning: We also recommend that you store a copy of your password somewhere secure, as BackupAssist Technical Support cannot recover lost passwords.

If you use the cloud provider's portal, or another tool, to look inside the backup container (Azure) or bucket (AWS), you will see:

• File CRYPT – this file is a critical component in securing your backups.
• File ROOT – this is the entry point allowing BackupAssist to find the backups in the container.
• Directory chunks – this is where all of the backup data is located.

Yes, all the data that you back up is deduplicated and also compressed.

To learn more, see our deduplication article.

Nothing. Making any changes to the contents of the Cloud Backup's container could cause your backups to be corrupted and unusable in a restore scenario.

Warning: The data inside a container is NOT intended to be used directly by users, and is not human-readable. BackupAssist tools must be used to restore or recover from Cloud Backups

BackupAssist automatically removes data that is no longer needed (from old backups) from the provider, to reduce storage costs.

The process does not yet support concurrent backups or concurrent backup and restore, meaning that if you try to have more than one backup running to a container then one or both backups may become corrupted.

Note: In future, BackupAssist will support the re-use of containers, but for now it is important that a single container be dedicated to a single job on a single BackupAssist installation.

Cloud Backup is designed to make full use of the available bandwidth, and we have seen utilization exceeding 20Mbps.

Cloud Backup uses deduplication and compression to give effective speeds that are even greater. We have seen a Hyper-V VM that contained over 100GB in VHD files take only 4 hours to complete. This is effectively more than 50Mbps.

Note: As always, actual throughput will vary depending on network setup, current network utilization, machine loading, etc.

Cloud Backup has been designed to be extensible. For initial release Azure and AWS providers are supported.

Please email support@backupassist.com if you have a cloud provider with a block or object level storage facility that you would like to have supported.

No, Amazon Glacier is not currently supported.

No, CSV is not currently supported for Cloud Backup.

To back up guests on a CSV, use System Protection, File Protection, File Archiving.

To learn more, see Hyper-V in a CSV environment

Cloud containers are managed by the cloud service providers, Amazon Web Services and Microsoft Azure. We do not currently have the ability to manage how the container is managed, as this is controlled by the providers own consoles and features. However, we are investigating what options we have to restrict the size of Cloud Backups.

It is worth noting that you can use BackupAssist to set how many backups are kept in the cloud destination using Cloud Backup’s Schedule options. There are two schemes available: The Grandfather-Father-Son scheme keeps 23 backups but the Basic scheme stores just 1 backup for each day of the week, so a maximum of 7.