Hi Everybody,

This is a quick post to let everyone know that our Australian office will be unavailable from Friday 12th – Monday 15th March, 2010.
This means that there will be no phone support and minimal e-mail support available during these times from our Australian office. The reason for this is due to relocation of the office and also major server maintenance.

Our US office will be available from 9am – 5pm US Eastern time as usual and can be reached on 812-206-4265.

We apologise for any inconvenience caused by this downtime.

Kind Regards,
Stuart
Lead Help Desk Engineer – Australian Office

Hi everyone,

I’ve just wound up a tour around Australia of the SMBiT Groups – Sydney, Adelaide, Brisbane and Melbourne. Needless to say, I was absolutely exhausted by the end of it – getting up at 4:45am to catch a flight from Brisbane, or sitting for an hour on the runway at Sydney airport is very taxing!

I spoke about various topics, but the major one was about correctly backing up Hyper-V.

It was absolutely fantastic to meet you all, and I hope that you all got a lot out of the meetings. The feedback has been tremendous, and the questions I was asked during the meetings were highly intelligent.

Over the next few weeks, I’m going to blog about the major questions that were raised during the presentations so that we can share the knowledge.

A big collective thanks to everyone who attended, everyone who asked quetsions, the group leaders for welcoming me to your respective groups, and of course, the many resellers who I met. Your continued support of BackupAssist is really appreciated. And I received a lot of excellent feedback and feature requests – thank you so much!

Regards,

Linus

Due to some unfortunate networking issues, the UK and US Support teams are experiencing difficulties with their Email servers, and it has created a delay in response times for emails.

We are attempting to resolve this issue as swiftly as possible, and you should receive a response to your emails before Start of Business on Tuesday February 16th.

In the meantime, our support staff are still available via phone for any critical issues that need to be addressed, they can be reached on + 1 (812) 206-4265

How does Hard Links work with Single Instance Store (SIS)?

This is a question we get quite often because it is so different than traditional backups.

When doing either a File Replication or an Rsync for Windows job, using a schedule other than Mirror 1:1, you will be using the SIS.

The SIS uses Hard Links to allow a never ending incremental backup.
This means for any file that has not been changed, it will be marked so that it is not backed up.
The confusion comes in because in the past, an incremental backup would be smaller than the full backup, and you would need to have every backup made, since the last full backup, to do the restore.  Because of Hard Links each folder is really linked back to the unchanged data, so every folder appears to be the size of a full backup.  This allows you to restore all your data from the newest backup, even if older backups had been deleted.

Hard Links have the drawback that when you select all of your folders, your unchanged data will be reported for each folder, even though it was only backed up one time.  A 1MB file will show as 3MB if you are looking at 3 folders.  You will need to check the properties of the hard drive to see how much data has actually been written.  This also means if you copy the backup directories to another location,  the hard link be broken, but your data will be copied for each folder you have.
(more…)

Recently we  had a situation where a customer was only permitted to backup to a folder on the local hard drive of their SQL server..  If the job was written to another backup device/location, the job would generate a BA1505 error (Cannot open the specified destination directory from the server – it may not exist or the SQL server may not have the correct authorization).

After a little brainstorming,  we changed  the user account the SQL service was running to a domain administrator account instead of the local system account. Then it was time to test out the backup again (with fingers and toes crossed).
The result: The SQL server was successfully backed up to removable drives and other locations!

The explanation:
The trick with SQL is to remember that the “Use SQL authentication or Use Backup User Identity” option is simply to get access to *run* an SQL backup,  it does not give any privileges for the SQL server to *write* the backup anywhere.

The privilege for writing comes from the user account that is running the SQL service. By default this will be the computers Local System account (or similar).This account has high privileges on the local computer, with zero privilege on other computers,  therefore the UNC shares on remote computers will need to be writable by everyone *AND* the remote computer must have “simple sharing” *disabled*.  This is why we temporarily create a share on the BackupAssist machine with writeable-by-everyone privileges (if the SQL server is remote and the destination is a non-UNC path).

If the SQL service user account is changed to a domain account (not necessarily the backup user, but makes the most sense) then the UNC share needs to be writable by that account. Note that running the SQL service as a domain administrator is a security risk, as it  could permit any hacker that can connect to the SQL server the ability to  access domain admin privileges on the network.  Also, database applications running on the SQL server (eg. a website using the SQL server as datastore) may be affected if the SQL service user changes; e.g. a domain administrator contains a greater amount of permissions overall, however a local system account is given more specific permissions when running application services on a particular machine.

This is why we recommend setting up a share on the SQL server, that is *readable* by the Backup User Identity, and backing up to that share using a UNC path. This avoids changing the SQL server account and the potentially risks, and avoids permanently having a share writable by everyone. Another BA job can easily pick up the .bak files from that share, or the post-backup script could do the same.

For more information on the SQL add-on available with BackupAssist, please take the time to look over our white paper located at http://www.backupassist.com/downloads/whitepapers/SQL_WP.pdf.

Hopefully this information helps out when having permission issues such as we were!

With the advent of the Windows 7 release, we were recently made aware that the recommended Rsync server we listed on our downloads page does not support Windows 7.
After working with one of our customers, Mike Hoyle , he let us know that he has discovered an update to the cwRsync solution which functions in the Windows 7 environment.
I have included his correspondence below:

I may have found a solution to my problem as follows: -

I removed the original installation including services which was installed from the download on your website.

(cwRsyncServer_3.0.1_Installer.exe)

I went to the following site http://www.itefix.no/i2/download

Downloaded the latest cwRsync – cwRsyncServer_4.0.3_Installer.zip

and downloaded the latest Copssh – Copssh_3.0.3_Installer.zip

Installed cwRsync and then Copssh

Activated a new Copssh user – running the command ’ssh localhost’ in the Unix shell now works.

I have managed 4 successful backups now to the Win 7 RSync Host. from backup assist v5.4.2

We would like to take the time to thank Mike for providing us with this information, and allowing us to share it so that this issue can be addressed.

Finally – we’ve found a nice, fast, cost effective solution for encrypted image backups.

One of the limitations of the Microsoft Block Level Backup (a.k.a. drive imaging) features in Server 2008 is that all backups will be unencrypted. For businesses like medical clinics, legal firms or law enforcement, this can compromise client information.

I’ve been working with the CRU DataPort 10 Secure device (http://www.cru-dataport.com/) as a possible solution to this problem… and the result is good!

I’ve been playing with the internal version. The device consists of a “frame” (or “dock”), where you insert the hard drive caddy. The actual frame connects via SATA to the motherboard or SATA controller, and contains the encryption electronics. You can then insert the hard drive caddy, and all information on that disk is encrypted. If you try to plug the disk into a normal SATA port, it appears as an uninitialized disk.

An external version is also available, which connects via USB or eSATA.

The encryption features make the units perfect for backup! And they’re more cost effective than other solutions, like the RDX drive.

When I first played with the CRU system (and when it’s used unassisted by BackupAssist), I found some “gotchas” – that swapping disks causes drive letters to change, and that it was not possible safely remove the disk on a non-hot-swap SATA controller.

So last week, I spent some time handling these problems in BackupAssist, and these new features have made it into v5.4. In summary, BackupAssist integrates with the CRU DataPort devices by:

• Safely ejecting the disk after the backup so it can be removed without data loss
• Changing the drive letter of the disk before the backup so the backup will work
• Doing a hardware rescan before the backup so that any newly attached hardware will reappear, or if the drive was ejected from the night before but not replaced, the ejected drive will reappear, and the backup will happen.

[These features have been in BackupAssist for USB drives for over a year, but before these changes, we were having some problems ejecting SATA disks on non-hot-swap controllers and reassigning drive letters.]

On the plus side, because the CRU DataPort 10 Secure unit encrypts the entire hard drive, you can place other data onto the disk as well – such as SQL Backups, Exchange Mailbox backups (PST), File backups – and they’re automatically encrypted too.

I’ll be running some trials and case studies with some partners of ours, and I’ll keep everyone updated on progress. These new case studies will also be backups of Hyper-V systems, so the package of BackupAssist + CRU gives encrypted Hyper-V Backups with granular restore – Yippie!

Availability: these features were released in the v5.4 beta last week, and are also in the full release of v5.4 – which is going to be released this week.

Big thanks to Hilton Travis for sending a rocket my way and making me work long hours to get this feature in!

Enjoy!

Last Tuesday morning was not good for me. As the title of this blog suggests, a lot went wrong, and it happened all by itself. It never ceases to amaze me how Microsoft systems can break all by themselves.

We have a SBS 2003 network, fairly small (about 15 workstations) with a very standard configuration of just Exchange, file sharing and RWW. You’d think that not much could go wrong…

Upon logging into my workstation last Tuesday morning, I was presented with a black screen and a 10 minute wait accompanied by a flurry of hard drive activity. I wasn’t the only person this was happening to but I put it down to an automatic update installing from the previous day. I began my day by checking Outlook and was very pleased to find that nothing had arrived since I had logged out the previous day. I sent a few internal emails, and then followed them up in person only to find that none had arrived. About now my other colleagues were starting to notice the same thing.

I strolled down to the server room to see what was causing the mail backlog. I opened the Exchange System Manager and after a lengthy pause I was greeted with “The Specified Domain Either Does Not Exist or Could Not Be Contacted”. From here, it quickly became apparent that the issues were much more widespread. During the course of the night Active Directory had become corrupt and was unable to identify our server as the DC, instead, looking for a backup DC that had been decommissioned more than 12 months earlier!

How can something like this happen? Everything was working just fine until last Tuesday.

We began by trying to rebuild the Active Directory database. We spent over two hours attempting this process, but to no avail; we were unable to point Active Directory back to the correct server. As all of our applications were functional and we had lost no data, we decided to take a different tack and perform a System State restore. Our DC is running Windows 2003 SBS, so we had been using BackupAssist to create a System State backup each night through the NTBackup Engine. We attached the USB HDD with a backup of the System State from the previous week and began the restore process.

Fortunately, the restore was a very straightforward process and we were running again in about 15 minutes.

The first step was to launch BackupAssist, navigate to the restore tab and select “NTBackup restore”. Then it was a simply matter of selecting the date of the backup we wanted to restore, choosing the System State item from that backup and beginning the restore process by completing the restore wizard. This process was fully automated and only required a quick reboot to update the files and registry information. Our server rebooted successfully, now with Active Directory up, running and correctly identifying our server as the Domain Controller. From here we were able to fully remove the items that were still pointing to our decommissioned server, ensuring this issue didn’t reoccur.

The important thing that came out of this nightmarish situation is how much faster and easier it is to solve these types of issues when you have a comprehensive backup plan. Without the System State backup that we had been performing nightly, we probably still would have been rebuilding our primary server!

Although this was performed in a Windows Server 2003 environment, however it could just as easily been done on a Windows Server 2008 environment through the BackupAssist Windows Imaging engine. It just so easy to tick that extra option to perform your system state backup, there is no reason why you shouldn’t.

The moral is: I, like many others, under value the importance of a stand-alone System State backup. The real value of this backup isn’t seen until you a faced with an issue within Active Directory, or the registry, that doesn’t extend to your applications or data. Without a System State backup that can be restored independently, you would be faced with having to perform a full restore of your server to a previous day; losing data and wasting time.

Hi all,

We’ve been asked a few questions about pass-through disks.

At the moment, our Hyper-V backup solution only works when the Guest HDDs are VHD files, not physical volumes. (A pass-through disk is where the disk is connected to the host, marked as “offline” on the host, and passed through to the Guest where it is “online”.)

This is a limitation in the Microsoft Hyper-V VSS Writer, and also our Hyper-V Granular Restore Console only works on VHD guest HDDs as well.

The good news is that there’s no compelling reason to use pass-through disks anyway, so this limitation is almost a moot point. There is very little performance difference between a Fixed size VHD virtual disk and a physical volume, as explained in the MS blog: Working around the pass through limitations of the hyper-v vss writer.aspx

Happy Hyper-V Backups!

Hi all,

You might have seen our solution for Hyper-V Backups – which involves imaging the host, and using the BackupAssist Granular Restore console to be able to “dig down” into the backups and into the guests to retrieve individual files and folders.

However, I have been asked the question, “what if I only want to protect one or two VMs”?
Another client even posed the scenario – “I have a standby server, and want to copy the VMs from my main server to standby server every day, so should something go wrong, I can flick a switch and run the VMs on the standby.”

The important file to copy across is the VHD file – the virtual hard disk of the Guest VM. If you copy that across to another location – either your backup device or a standby server – then you will have a valid backup and snapshot of the Guest VM.

However, a normal copy program won’t do, because it isn’t VSS aware, and won’t tell Hyper-V to commit itself. However, the BackupAssist File Replication Engine is VSS aware and Hyper-V aware, and can certainly be used to protect individual VMs by copying the VHD files.

1. Set up a File Replication job
2. Use the Mirror scheme if you only want to keep the last copy, or a scheme with history
3. Select the appropriate VHDs to replicate.
4. In the Open Files tab, you need to enable the VSS writers (so Hyper-V is properly committed for backup)

Additionally if you are backing up to a standby server:

5. The destination path of the VHDs will be important. In the Replication options, you need to uncheck the “use full path” option so that we don’t put the VHD into a special path based on the source directory.

When setting up the destination, then you need to be careful to specify the destination directory accurately so that the VHD goes into the correct location. Our File Replication Engine will use the common “root” path – for example, if there are the source files:
C:\one\two\three.txt
c:\one\apple\banana.txt

Then on the destination, you’ll get:
….destination path\two\three.txt
….destination path\apple\banana.txt

6. Now, on the standby Hyper-V server, you’ll need to create another copy of the virtual machine with identical settings. This is because it’s not possible to copy the VM settings from the original Hyper-V Host to the secondary host – it’s only possible to copy the VHD. I wrote more about this here: http://www.backupassist.com/blog/support/granular-individual-vm-restore-of-hyper-v-virtual-machine-from-backup/

If you are backing up to a backup device, then you need to be aware of your restore options:
- Restore to the same Host – copy the VHD back
- Restore to a different Host – copy the VHD to new host and create a new VM, using the existing VHD as the hard disk
- Please see http://www.backupassist.com/blog/support/granular-individual-vm-restore-of-hyper-v-virtual-machine-from-backup/

Note: These instructions assume that Hyper-V Snapshots are not used! We recommend against using Hyper-V Snapshots as they can impact performance, and they are not a real backup. However, if you do have snapshots, you need to back up and restore all the VHD files (and the AVHD files, which are differencing hard disks).

I hope this helps!