Hi All,

This is Raj from the BackupAssist support team .

As you may already know, the latest release of BackupAssist (Version 4.1) was officially released last week.

While this latest update received the stamp of approval from the majority of our client base, there were 4 clients who encountered some issues.

Looking into their issues, it was basically clear that we had a minor bug in the latest release that affected clients running on 64-bit machines, who were specifically backing up their data to a CD / DVD device or external hard disks.

Jason and Justin from our development team looked into the issue and they found that the cause of this problem was a faulty .dll file.

To address this issue, we uploaded an updated copy of Version 4.1 on our website today that contains the correct .dll.

However, if you are running BackupAssist V4.1 on a 64-bit machine and you encounter any similar issues, please follow the steps below to troubleshoot the error:-

- The easiest step is to email our support team and we’ll reply back with the correct .dll file as an email attachment. You can then copy this .dll to the BackupAssist install directory.

- The other option is to un-install the software completely, ensuring that the BackupAssist install directory (for example:- C:\Program Files\BackupAssist V4) is also deleted from the machine. Once all the traces of BackupAssist have been removed from your machine, you can visit: http://www.backupassist.com/BackupAssist/download.php and download Version 4.1 once again.

I hope the above suggestions help to fix any issues you may encounter.

On behalf of the BackupAssist team, I’d like to apologise to all our clients who encountered this issue.

Until my next post….. Good Bye!!!!!

Yesterday, an unfortunate thing happened. After a reboot of our server (that was combined with the installation of some Windows updates), our Exchange Information Store became corrupt.

(Note: In our company, we use Exchange for internal company emails. All emails that go to our backupassist.com email addresses are hosted externally, so thankfully this Exchange corruption didn’t affect our helpdesk and tech support team.)

To compound matters, our staff member who is also our system administrator has been sick for nearly 3 months, so it was left to me (a developer!) to get our Exchange Server going again.

It took a few attempts, but thankfully having a good backup (made by BackupAssist!) saved the day.

The symptoms were these:

Every minute, this event is logged:

- Event ID 9175, Source MSExchangeSA, Category MAPI Session, Message: The MAPI call ‘OpenMsgStore’ failed with the following error:
The Microsoft Exchange Server computer is not available. Either there are network problems or the Microsoft Exchange Server computer is down for maintenance.

When the Exchange Information Store service is started, this is logged:

- Event ID 9518, Source MSExchangeIS, Gategory General, Message: Error Read verification error starting Storage Group /DC=local/DC=CortexIT/CN=Configuration/CN=Services/CN=Microsoft Exchange/CN=CORTEXIT/CN=Administrative Groups/CN=first administrative group/CN=Servers/CN=GERSHWIN/CN=InformationStore/CN=First Storage Group on the Microsoft Exchange Information Store.
Storage Group - Initialization of Jet failed.
- Event ID 419, Source ESE, Category: Logging/Recovery, Message: Information Store (1220) First Storage Group: Unable to read page 457774 of database G:\ExchSvr\MDBDATA\priv1.edb. Error -1018.
- Event ID 454, Source ESE, Category: Logging/Recovery, Message: Information Store (1220) First Storage Group: Database recovery/restore failed with unexpected error -1018.

[And several more such logs]

And from within Exchange System Manager, the stores simply wouldn’t mount. There was no real error message.

The first thing I did was to make a copy of the MDBDATA directory. When doing any work to the Exchange database files, ALWAYS MAKE A COPY BEFORE YOU START!

Then I found some instructions on using eseutil to repair the databases - and I ran through them and ESEUTIL claimed it had fixed the problem. The instructions are found here: http://www.mike-tech.com/article.php?gif=exchange2k3&article=304

However, the mount of the database still wouldn’t work, with more of the same errors.

After more Googling and trying other things, I found this article: http://support.microsoft.com/kb/264228/en-us

Okay, so it points to missing database files, where the solution is to put them back where they belong. mmmmmm… Or the other solution is to run eseutil /r. Which I did - and it didn’t work either.

A similar article is also found here: http://technet.microsoft.com/en-us/library/bb498209(EXCHG.80).aspx

Then I took another copy of the MDBDATA directory, and decided to do a full restore from the last full backup - which was done the night before. So in the worst case scenario, we’d lose one day of emails - which for us, is fine. I could then look at the log files later.

So after doing a full restore, and following the brilliant instructions in our white paper which I’d written a few years prior (available here http://www.backupassist.com/downloads/whitepapers/ExchangeMailboxBackup_WP.pdf), I was all set! Or so I thought…

The blasted Information Store still wouldn’t mount!

Argh - how could this be??? A full backup wouldn’t mount?

After some thought, I deduced that the problem was that when the Information Store service starts, it automatically tries to use the log files to bring the database “up to date”. And it’s most likely that the log files were corrupt.

So I deleted the two *.log files [E00.log and E00xxxxxx.log] and did another full restore.

And hey presto! The mailbox store mounted successfully!

Now, did we lose any emails, given that we restored from the previous night’s backup? Well, in actual fact, no. We use Outlook in Cached Exchange mode so all the emails sent and received during the day were cached. And to my surprise, when we connected Outlook back to the Exchange Server and it synchronised, it did NOT delete the emails that were only in the OST file but not on Exchange. Having said that, those emails weren’t pushed back to the Exchange Server either. For us, this situation was acceptable.

So the total time taken to do this was about 1 hr 30 mins. Of that time, about 1 hr 15 mins was spent pursuing the eseutil database repair options… another 10 minutes figuring out that I had to delete the *.log files, and 5 minutes actually doing the restore.

The magic is knowing what to do… so I hope this information will be of benefit to other poor souls who suffer the same fate!

And remember – always backup! Thanks BackupAssist!

Hi all,

This is Raj from the BackupAssist Support team with my first post on our blogs - I hope you find my post useful.

Yesterday I had this very interesting task of assisting one of our clients who was looking to backup a remote SQL server, which was on a different domain and a different subnet.

While my initial gut feeling was to tell him ’sorry, not possible’, I thought of giving it a shot just in case.

The scenario was (example):-

Backup Server
Ip address - 192.168.1.x
Domain - Test

SQL server
Ip address - 192.168.4.x
Domain - Sample

Initially the backup server was able to detect the SQL databases, but the backup always failed in the ‘Checking Destination’ phase within our software.

We tried changing the backup destination from being the ‘backup server’ to the ’sql server’, but the same issues persisted.

Finally, with the help of Jason (our SQL expert from the Development team), we got around this issue by using a simple ‘pre-backup’ script within BackupAssist.

Example:- net use \\192.168.4.x\sqlbackup\sql\ /user:admin password,

where,
\\192.168.4.x\sqlbackup\sql\ - is the backup destination where the SQL backups are stored
admin and password - is the user name and password of the administrator user account in the ‘Sample’ domain.

Phew, all’s well that end’s well .

A long time ago, in April 04, we released v3 of BackupAssist. And we have enjoyed providing you support for v3 since then! When we released v4 last year, we said that we would discontinue support for v3 at the end of 2007. But since we love working with our users so much, we continued to answer questions, provide support and facilitate license key changes.

Now that v4 has been out for over a year, and with version 5 planned, we will be officially ceasing support for BackupAssist v3.x at the end of June 2008.

To help spread the word, please inform your system administrators or clients who are using BackupAssist v3.x of this notice.

We strongly encourage you to upgrade your version of BackupAssist as doing so will future-proof your backup system against new operating systems and environments.

If you’d like more information about the pricing for version 4, please visit: http://www.backupassist.com/purchasing/upgrade.php.

For more information about our EOL Policy and Announcement, visit http://www.backupassist.com/support/EndOfLife.html

After receiving many requests from our family of BackupAssist users, we
are pleased to announce that we have officially launched the BackupAssist
US Support office.

The US Support team members, Michael Farqhuar and myself, Sally Chamness, spent
the month of March at our Headquarters in Melbourne, Australia undergoing intense training
to ensure that we could provide our clients with the best support available.

Michael and I are located near Louisville, KY and are available during the
following hours of operation:
Monday - Friday 9am - 5pm (EST).

You can email us at: support@backupassist.com
with any Sales or Support questions you may have.

Additionally you can discuss any questions you have with us and fellow
BackupAssist users at our support forum: http://backupassist.com/phpBB3/

Cheers
Sally Chamness
US Support Team!

The Mailbox add-on in BackupAssist does work for Exchange 2007, but it also requires a little more configuration and there are two “gotchas” to be wary of.

I have set up a simple test environment on some VMs in our test lab, and the set up works first time, every time.

The gotchas

Exchange 2007 is a 64 bit application and needs to be installed on a 64 bit computer. However, the two known ways of extracting email messages to PST format (the Outlook/PowerShell method or ExMerge) are 32 bit applications, and they link to 32 bit DLLs. As it’s not possible to call 32 bit DLLs from 64 bit code, it means that extracting mailboxes to PST cannot be done on the Exchange Server itself.

FIRST GOTCHA: You need to do the mailbox backup on a machine other than your Exchange Server (ie. remotely), and on a 32 bit OS.

Why Microsoft didn’t see that coming is beyond me!

SECOND GOTCHA: you need the Exchange 2003 Server Management tools installed on your backup computer. This is only available on the Exchange 2003 CD. [Note: we are working on a version of our Mailbox add-on that will only require the Exchange 2007 Server Management Tools, which is available as a free download off the Microsoft website. We hope to make this available shortly.]
 
How to set it all up

1. Pick a machine on which to run your mailbox backups – this must be a 32 bit machine
2. Install the Exchange Management Tools for Exchange 2003 on this machine – follow the instructions outlined in the BackupAssist Exchange Mailbox White Paper from page 7 onwards. Or if your machine is an Exchange 2003 Server then you don’t need to install the management tools (they come with Exchange!)
3. On the same machine, install and run BackupAssist, choose to backup Exchange Mailboxes, and let BackupAssist install the ExMerge program (as outlined in the BackupAssist Exchange Mailbox White Paper)

Our test environment

I followed this procedure on the following test environment:

• Windows Server 2003 Standard, 64-bit OS, with Exchange 2007 installed
• Windows XP 32-bit, with Exchange 2003 Management Tools and BackupAssist v4.0.16 installed

After it was all set up, the mailbox backups worked perfectly, with no additional modifications required. There were no warnings or errors.

As always, we expect that although this procedure will work for the vast majority of our clients, there will always be some tricky or unexpected network setups that will cause problems. In that case, it’s best to contact BackupAssist support, and we’ll investigate on a case-by-case basis.

When configuring a File Replication job, the user will be able to select folders and files to be backed up using a tree-like interface, similar to the existing “Files and folders” settings tab of NTBackup jobs.

There are 4 main factors in the design of the File Replication Engine:

1. Envisaged applications — data backup, VM backup, etc.
2. Mapping of the source path to the destination path
3. Backup History
4. Media Rotation (for portable media, like USB HDD)

1. Envisaged Applications

We anticipated that the File Replication Engine will be very useful for:

• Data backup — thanks to the single instance store architecture, it’s possible to store tens or hundreds of revisions on a single medium. For example, if you have 100GB of data and approximately 1GB changes each day, you will be able to store around 60 “snapshots” of your data on one 160GB USB HDD! This feature will far exceed the typical capabilities of VSS snapshots. To get your data back — just copy the entire snapshotted directory back to your server, or individual files if you prefer.

• VM backup — to backup client VMs, simply use the File Replication Engine to replicate the entire VM directories to a USB HDD. If your server goes down, simply plug the USB HDD into a different machine, install your VM software (eg. VMware Server) and run the virtual machines — this reduces your downtime to virtually zero!

• Exchange backup — backup your Exchange database files by a VSS-compliant file-copy operation, enabling you to forklift the database easily

… if you have other scenarios, we’d like to hear about them to make sure we cater for them all!

2. Mapping of the Source Path to the Destination Path

A single destination folder may be selected for each job. The destination folder may be on a local drive, NAS or removeable media. There are two options for how source files and folders are mapped to files and folders within the destination folder. The user interface will allow selection of one of these options, e.g. using a checkbox.

In the discussion below, it is assumed that the destination folder is X:\Backups.

Option 1: Full path

The full path to each source file will be encoded within the destination folder.

Example

Option 2: Relative to common ancestor

Rather than encoding the full path for each file, use only a sub path relative to the lowest common ancestor of all selected files and folders.

Example 1. One source folder selected

Common ancestor is C:\Foo so backup file paths are relative to this folder.

Example 2. Multiple source folders

Common ancestor is C:\Foo so backup file paths are relative to this folder.

Example 3. Multiple source drives

Selections span multiple drives so there is no common ancestor and the full path to each file, including drive letter, is used in the backup.

3. Backup History

A number of backup schemes will be provided to allow historic backup to be retained. Historic backup stored on the same volume will use a single instance store to ensure that only one copy of unchanged files is stored on the disk. When a scheme with backup history is in use, there will be an extra level of folders within the backup destination folder to store historical backups.

Example (assuming “Full path” option chosen)

This scheme has daily backups stored under destination folder\date.

4. Media Rotation

For portable media, such as USB disk drives, the user will be able to set up media rotation schemes to allow regular backups to be rotated among different volumes. Each volume will hold a set of complete (i.e. not incremental) backups. The single instance store architecture will ensure that identical files are shared between backups within a volume, but not across volumes. For example, if a user has 3 USB HDDs and chooses to rotate them one after the other, the list of backups on each drive might be:

• Drive 1:
  • 2008-05-01
  • 2008-05-06
• Drive 2:
  • 2008-05-02
  • 2008-05-07
• Drive 3:
  • 2008-05-05
  • 2008-05-08

Similarly, if the user has 5 drives (one for each day of the week) then each drive would contain backups of data for every week, and the backup history goes back in one week increments.

Feedback

If you have any comments or suggestions about this proposal, or scenarios for which you think the File Replication Engine would be useful, please let us know by leaving a comment.

We’ve already started work on some of the new features in our next major release, which include:

• Centralized monitoring – view the status of all of your clients’ backups in one report
• File Replication Engine – our latest file-based backup engine that uses a VSS-based file copy to backup files (more about this below)
• Windows Block Level Backup (drive imaging) integration

Our planned timeframe for releasing v5 is Q3 this year (most likely August or September).
Drive Imaging Features are to be released with Version 5
We had previously planned to release our support for the Windows 2008 Drive Imaging features with Version 4.1. However, due to a lack of uptake and demand, we’ve decided to release it as part of Version 5, to coincide with our new File Replication Engine. Apart from giving us extra testing time, it also means that v5.0 will be an excellent backup choice for Windows Server 2008, providing both Drive-Image and File-Based backup options.

When you work with anyone over a period of time, you can build a good relationship with them.

This is true even when dealing with people from a technical support team. But have you ever sat down and wondered, Who are these people? Or, Where did this company come from?

Today I’d like to give you a peek into the wonderful world that is BackupAssist - and even enlighten you with a little company history.

BackupAssist started as a hobby project to help one particular system administrator set up a reliable business grade backup system with NTBackup on Windows NT and 2000.
It was designed to address the shortcomings of NTBackup (inadequate scheduling, media rotation, and monitoring). It would also
overcome a number of bugs within Removable Storage Manager on Windows 2000, where tapes were not being detected in the tape drive causing scheduled backups not to run.

As with many other software developers, this lone system administrator wanted to share the software with others who were having the same issues.

So in 2002 the software was released to the public and a basic website was built for software support.

Immediate feedback for BackupAssist was incredible! By mid-2003, enough users had purchased the software, indicating that continued development was warranted and desired.

Over the next 3 years, new and extra features were added, but always with the view to making backups easy for novice system administrators and with enough advanced
features for the veteran system administrator.

When 2006 came, add-ons for Microsoft SQL Server and Microsoft Exchange Server mailboxes had been created and were welcomed by our customers.
The Exchange Server add-on was built to take advantage of Microsoft’s Exmerge tool, which exported mailboxes to PST files.

The main aim of the BackupAssist developers is to provide a software which is “Engine Independent” - platform that can integrate with any back-end engine with ease.

In addition, being able to leverage existing backup engines and open standards mean that Research and Development time is reduced, thereby giving BackupAssist a price advantage.

Here at BackupAssist, we are always exploring new paths to find new ways to improve our product for our customers. In fact, as this is being written (May 2008), a whole suite of engines are being developed, including solutions for file based backups, and Internet based file synchronisation and other application backup. Please keep reading our blogs (both support and developer) and as I get more information, I’ll keep you posted on our progress!

cheers,
Aarthi
BackupAssist Support Team