01 Feb

Since the introduction of Microsoft’s Volume Shadow Copy Service in Server 2003 it is common to backup the Exchange database in its entirety as part of a bare-metal backup job. This is a great way to deal with a disaster such as a hard drive failure where you want to recover a whole server, or even if you need to recover the whole Exchange database back to a point in time.  The difficulty comes when you want to recover, for example just a single mailbox, or even specific emails.  With a full backup, you are backing up the entire database which means you’ll need to recover the full database first to a temporary location, mount this as a recovery database, connect to it with a client and then extract the data.  With a large database this could take quite a lot of time and resources to complete. BackupAssist has a much easier, more convenient way.
10:23 / BackupAssist
18 Jan

If you've ever used BackupAssist to run an rsync job to a remote NAS device, you may be familiar with the built in 'seed' function. This bypasses the need to run a large backup for the first time over the network and instead uses a USB hard drive to move the data manually. After the seed job has completed, the drive is disconnected from the BackupAssist server and plugged directly into whatever is performing the role of the rsync server. Often it's a NAS device, but I also talk to customers who choose to run either a Linux server which has native rsync support or even a Windows box using the free open source CWRsync service.
13:42 / BackupAssist
25 Oct

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.
12:35 / BackupAssist
29 Sep

We were recently asked if you could recover a Windows Image Backup of a 2008 R2 server taken with BackupAssist directly to a newly created Hyper-V Virtual Machine.  This was something that should work in theory as part of the 'recover to dissimilar hardware' function of Windows image backups, but there are a few considerations that have to be met for a clean restore process. So here is the best way we have found to achieve this.
09:00 / BackupAssist
14 Sep

Those of you familiar with using BackupAssist's Rsync plug-in to send data to an off-site location, may well have toyed with the idea of building your own Windows server as the destination, as we do here. CopSSH4.1.0copssh4.1.0 Currently you need two components to achieve this, there's "cwRsync" which enables the server to talk to BackupAssist and there's the optional "CopSSH" which  allows you to do so securely over SSH. The developer (Cortex Labs) currently package these for you so that one installation follows the next as part of the same installation wizard.
16:23 / BackupAssist