I have been testing the backup software on multiple machines running Windows XP/Vista/7 and have noticed that the file and image backups seem to ignore the outlook.pst and a few other files in that folder. On Vista/7 those files are in C:\Users\username\AppData\Local\Microsoft\Outlook. Even if Outlook is closed it never backs up the file.
Okay. This is very serious indeed. Are there any error messages in the Logs?
Which folders did you set it to backup (file backups)?
The image backup is done of the System Volume ©. If this backup is corrupted you should see errors in chkdsk. Otherwise… maybe the user folders are somehow network mounted or use another volume via reparse moints?
For the file backup I am only backing up c:\users or c:\documents and settings (for xp). The logs don’t show any errors. It does seem to backup the archive.pst but just not the main outlook.ost. Everything is stored local and an Exchange server is used by Outlook for mail.
I copied the .vhd file to a Windows 7 machine and then mounted it in Disk Management. This is when I noticed that the outlook.ost was missing in the image backup as well.
I made a copy of the outlook.ost file in the same folder and will see if it gets backed up. Apparently the .ost is an offline folder file cache so not sure if that is causing it to be missed or not.
The copy of the .ost file was missed in the file backup. I then created a test.txt file in that same folder and it did get backed up.
It also seems to miss the .oab (offline address book) files in the same folder.
This should explain that: http://www.tgrmn.com/web/kb/item75.htm
That the .ost files are not present seems to be by design (it’s a feature). It’s weird if you ask me.
Hi,
I face the same issue with Windows 10 systems. Is there any solution to be able to backup these files?
(server version : 2.1.19, clients : 2.1.16)
Leaving out .ost files is a design choice by Microsoft. Even their own backup/imaging tool leaves them out as they’re not included in a VSS snapshot, you’re supposed to regenerate them post-restore.
If you really want an image including them, you’ll have to use a tool that does offline images from a boot cd/usb (Clonezilla PING others) or copy them off the drive from a Linux live session or from WinPE. Though given you can regenerate them, I can’t see a case where you need to.
If you don’t want to be regenerating .ost files post restore, the solution is “Use something other than Outlook for mail”. This also side-steps the world of hurt when a .pst (where the actual mail lives) file becomes corrupt, and you have a real problem trying to recover or extract mail from it.
You can remove the *.ost exclude in the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\BackupRestore\FilesNotToSnapshot. Microsoft added that exclude for a reason, though, and you should read about that reason. From the FAQ ( UrBackup - Frequently asked questions ):
###Microsoft Outlook .ost files aren’t backed up!
Microsoft Outlook adds exceptions to the Microsoft Shadow Copy Service to exclude the .ost files. Several Backup tools (UrBackup included) therefore do not backup them. Here is what seems like an official statement from Microsoft: “Maintaining changes to .ost files within shadow copies is expensive in terms of space and I/O activity. The performance impact doesn’t occur during the image backup itself–the only extra work at backup time is backing up the .ost file as part of the image. Instead, the performance impact occurs during the ongoing, everyday I/O to the .ost file when Outlook is running. If the .ost changes were kept in shadow copies, then every time Outlook writes to the .ost file, the result is a copy-on-write I/O hit (2 writes, 1 read). Although we have worked to reduce the impact of copy-on-writes on shadow copies, a heavily churned file like an .ost file could still cause problems. For these reasons, and the fact that .ost files can be regenerated, we chose to delete .ost files from the shadow copy before the image is created. Even if the performance issues didn’t exist, there are situations where Exchange will, after an .ost is restored, detect a “future” version of the .ost file and force you to delete and then regenerate the local .ost file. Therefore, it’s still preferable to regenerate an .ost file instead of restoring it.”
Basically just backup the Exchange server (which you can do with UrBackup, too) and you are good.
Yes, i didn’t realise this was (almost) useless to keep these files at the moment… Quite better to regenerate it.
Thanks for the information