30 Day Free Trial
Free Managed Service Webinars

Backup and Disaster Recovery (BUDR) 3.0 Frequently Asked Questions

Installation

How Do I?

BUDR Functionality

Applications

Best Practices

Assistance

Installation

Q Is there anything I need to do before the upgrading the BUDR software?

A. All of your Kaseya agents will need to be upgraded to the latest Kaseya Agent (5.1.0.1). Each client must have at least 750MB free space for the upgrade.

Q BUDR comes with a new version of the Kaseya Agent (5.1.0.1). Do I need to install this on all my backup endpoints?

A We recommend that you deploy the new agent to all systems that have the new BUDR client software.

Q Am I required to upgrade all my backup clients once BUDR 3.0 is installed?

A You are not required to install the new backup client in order to keep using backup. BUDR will work with a mix of backup versions 9.1 and 9.5 (the new client version) clients. However, in order for the endpoint to take advantage of the new features including encryption, synthetic backup and image conversion, the endpoint must be updated to the new version of the client software.

Q Are there other changes necessary to take advantage of synthetic backup with an offsite server?

A The offsite configuration page will deploy the backup client software to the offsite server. As a result, the offsite server must be a system that is capable of running the client software for doing the synthetic backup. The system requirements for this are described here: http://www.kaseya.com/support/system-requirements.aspx.

Q Does the client component download follow the patch source settings, so that the client installer will only be required to be downloaded once per network correct?

A Yes.

How Do I?

Q Is there a way to copy the initial full backup to an external drive and bring it onsite to our remote location?

A Yes, after you have completed the initial full backup, you should copy the entire directory structure to the external drive. Next, start replication, and you should be able to find the path where the backups will be create. Overwrite the partial file with the initial full backup. Offsite Replication will then recognize that the files are the same, and not retransfer the backup. If you are using Synthetic Full backups, then the synthetic process will take over, only copying incremental backups to the offsite server at your remote location.

Q How do other administrators manage large amounts of data? For instance we have a 70GB Full with 2GB incrementals, stored on a NAS. Do I have to physically take the NAS offsite to copy the first full?

A One option is to bring the NAS offsite to copy the full. Or, as mentioned in the previous question, you can transfer the files manually by bringing an external hard drive to the local NAS. Finally, if you have the available bandwidth, you may be able to wait for the full to transfer by itself. If you use Synthetic Full backups, the old backups will not be deleted from the local NAS until it has been transferred to the offsite location.

Q Is it possible to create a different file name for the backup?

A No. The file and directory naming structure is required for BUDR to operate correctly.

BUDR Functionality

Q What is a Synthetic Backup?

 A Synthetic backup is an alternative method of creating full backups. Instead of reading and backing up data directly from the disk, it will synthesize the data from the previous full backup (either a regular full backup for the first backup, or the previous synthetic full backup) and the periodic incremental backups. As only the incremental backups read data from the disk, these are the only files that need to be transferred during Offsite Replication. This greatly reduces the bandwidth needed for Offsite Replication.

Q With the use of the Synthetic Full, would it be expected that the offsite storage requirements will decrease?

 A When using Synthetic Full backups, the required offsite will slightly increase as there will be one additional incremental associated with each Synthetic Full backup.

Q Will the offsite Synthetic Full backup function make use of the existing offsite full backup that was created prior to the upgrade to BUDR 3.0?

 A No. After upgrading the backup client to version 9.5, a new full backup is required.

Q How many Synthetic Full backups can be run on the offsite server at a time?

 A Only one Synthetic Full backup can be run at any given time on the offsite server, regardless of how many machines or customers are copying data to that offsite server. The offsite server will queue up the other backups and will complete the in the order they are completed on the local server.

Q Is there a "cache" or "temp" file that the synthetic backup is using? Or is it directly writing to the NAS as it reads the other incrementals? (ie. Do we need additional storage to account for the synthetic creation process)?

 A Creation of the Synthetic Full backup is similar to creation of a regular full backup. The backup client uses a complicated heuristic to determine whether to write the file directly to the NAS or to cache the file locally and then transfer the file.

Q In the example of using Incrementals Forever, can BUDR recover if one of the incremental becomes corrupt? Or will a new Full be required?

 A If one of the incremental becomes corrupt you will need to create a new full.

Q Does the Synthetic Full require us to keep all of the old Backup files?

 A No.

Q If the offsite Synthetic gets disconnected or fails, once the connection is re-established, will the replication pick up where is left off, or will it have to start over?

 A: The BUDR 3.0 offsite server components have the intelligence to pick up where it left off, once the connection is re-established.

Q Can the replication of backup files take place while the synthetic full is running?

 A Yes.

Q How do you recover a machine from using the Synthetic Full Backup process? Does the recovery essentially pull data from an incremental backup and the synthetic full? What if the synthetic full no longer works?

 A Recovering a machine works the same for a Synthetic Full and a non-Synthetic Full. In either case if the backup is corrupt the restore will not work.

Q Can the VMs be created on the off-site server instead of the local client BUDR target?

 A 3.0 allows you to create VMs locally. If you wish to do this, you can use the Acronis GUI which is installed on the offsite server.

Q Is it possible to perform a reverse VM conversion (VM to BUDR backup set)? If not possible in BUDR, is it possible in the standalone Acronis Recovery CD?

 A BUDR 3.0 does not support VM to .TIB conversion. If you want to do this, boot up your VM and create a backup with BUDR 3.0, thus creating a .TIB

Q Will the previous version of BUDR continue to work until I do the upgrade?

 A Yes.

Q Does the encryption process slow the backup process down?

A No, it increases the CPU usage but does not slow the backup down.

Q If backups are encrypted, what happens if the encryption key is changed? Do we need to track both old and new encryption keys?

A The encryption key is the backup password. Kaseya tracks the password for you on the Image Password page. You can see old passwords by clicking on the Password Log link.

Q Is it possible to unstitch and go back in time?

A There is no unstitching, if you need to go back in time, you should use one of your point-in-time backups and restore from that.

Q Can you make a workstation backup to the secure zone?

A No, this is not supported in BUDR 3.0

Q Can you schedule a backup to NOT occur on certain days? For example not on weekends?

A You cannot create an exclusion in a backup schedule.

Q Is Tape Backup supported?

A No.

Applications

Q How do I handle Exchange Mailboxes and their restores?

A BUDR 3.0 provides backup and restore of the entire Exchange server. It does not provide brick level restore of individual mailboxes or individual emails.

Q How do we handle SQL Databases?

A BUDR 3.0 provides backup and restore of an entire SQL Server Database. It does not provide the restoration of individual databases or components.

Q Do the VSS fixes enable live backups of Exchange/DBs (right now they are currently being stopped for 3 minutes at the beginning of the backup)?

A When using VSS, a complete snapshot of the file system is created at the point in time when the backup starts, and that snapshot is backed up. As such, VSS provides what is called "crashlevel consistency", where the files will be stored in a state similar to as if the machine were to power down immediately due to a crash. Any application which can recover from a power down at any point in time will work correctly with this level of VSS support, and Exchange and SQL Server both can recover. However, the recovery process does take some time to run, and would be a necessary part of the restore process if they were backed up using this method. If Exchange and/or SQL Server are stopped before the snapshot is made, and then started a few minutes later, then the backups will be in a completely clean state, and the restore process will run more smoothly. As such, we still recommend stopped Exchange or SQL Server for 3 minutes at the beginning of the backup, but it is not necessarily required to have a successful backup.

Best Practices

Q Do you recommend turning off VSS?

A VSS is a powerful tool which provides two main features. In both volume and folder backup, it allows for backing up a consistent view of files from a particular point in time. And in folder backup it allows for reading open files (the Acronis driver used in volume backups provides the functionality of backing up open files without using VSS). If you are performing a folder backup, and some files may be locked (such as an Outlook PST file), then VSS is required to back that file up successfully. If you are backing up (using folder or volume backup) data files from an application that requires multiple files be kept in a consistent state (such as Exchange or SQL Server), then VSS is required to have a consistent backup. If neither of these two situations are relevant, then using VSS will make the backup process take longer and provide no benefit to the backup.

Q What are the default retention periods? If I deleted from say five weeks ago or three months, what are best practices in terms of being able to recover a specific file?

A There are no specific defaults or recommended values. The retention period should be determined based on your backup needs. You will need to balance how long you need to retain files (configured by how many backup sets to keep) with how granular your backups need to be (configured by how often to run incremental backups) with how fast full backups need to be run (configured by how often to run a full backup in between incremental backups) and with how much space you have (which is, of course, determined by your available hard drive space).

Q Is it ok to have the offsite schedule overlap the backup schedule?

A Yes.

Q Do you have any recommendations for NAS devices?

A Kaseya does not typically provide hardware recommendations; however, we do recommend that you verify that the device has enough storage to accommodate your requirements for at least the next year so and that connectivity is not an issue. You don't want this device to be the bottleneck.

Assistance

Q What should I do if I have additional questions?

A Contact your Cloud Services Depot account manager or the Support Team at support@cloudservicesdepot.com.