One of the most noticeable changes in version 7 of BackupAssist is how it looks and feels, so I thought I’d use this first of two preview posts to take an early look at the new interface in a little more detail.
Earlier iterations of BackupAssist have often been praised for their simple interface layout and ease of use, so when I first heard that the developers were looking to improve on this for version 7, I’ll admit to being a little apprehensive!
One trend I’ve noticed since we’ve been supplying BackupAssist is the popularity of RDX and REV drives for image backups, particularly in small and medium-sized businesses. I put this down mainly to how cost-effective they can be in comparison to similar capacity tape devices, and also that they still provide that same familiar multiple cartridge approach that tape device users are used to.
I came across an issue on a support call the other day I thought worth sharing as it’s bound to be something a few of you will see too.
The customer I was talking to was using the Windows imaging engine in BackupAssist to back up both their system drive ‘C:’ and a large data drive ‘D:’ (used for every day document storage etc.).
This was working just as expected and backups were updating quickly to a local USB hard drive when the inevitable happened – they had a local hard drive failure and of course wanted to perform a bare metal recovery from the last good image backup.
We’ve seen a few issues recently where a Windows image backup job has failed due to the destination drive partition being larger than 2TB. Unfortunately the errors generated can differ, so it can be sometimes difficult to spot.
We recommend that if you are using the Windows imaging engine within BackupAssist, you use destination devices that are 2TB or smaller, and the same applies to iSCSI destinations.
If you are trying to backup more data than can fit on a 2TB destination, consider splitting the job up into multiple parts. For example, run one Windows Image job to do a bare metal backup of the system drive and system reserved partition, and a second job to take care of any data partitions.
I recently worked with a customer who had around 3TB of virtual machine data when using Hyper-V. In cases like that it’s advisable to split the jobs even further so BackupAssist backs up half of the VM’s with one job and the rest with another – each job running to a separate destination that is 2TB or less. A third bare metal backup looked after the system volume.
I often get asked about the best way to create off-site image backups.
One logical approach is to use a windows network share for the destination, however because the destination is not accessible at the disk sector level, the incremental imaging feature can’t be used. A full image backup must be taken each time the job runs which can take significantly more time as well as requiring a larger amount of storage if you wish to keep multiple images.
For this reason, we often recommend that customers stick to local destinations for image backups with history, and plug in either a local dedicated USB hard drive or a pool of USB drives. This approach works very well and allows for multiple images a day, typically taking less than an hour to run on an average SBS server.
However the disadvantages of relying on local backups are clear in that they’re still susceptible to loss, theft and damage. An often overlooked solution for image backups that combines the best features from both of these methods is iSCSI.