Video Screencast Help
Symantec Appoints Michael A. Brown CEO. Learn more.

Symantec Backup Exec 12.5 - Restore Issue of VHDX

Created: 03 Dec 2013 • Updated: 15 Dec 2013 | 24 comments
This issue has been solved. See solution.

Hi Guys,

I read many blogs, however I haven’t come across an article that could solve my issue.

 Initial Overview of what’s happening:

Server A with 2012 OS does/dumps an incremental Windows Backup (built-in feature) on Disk Storage connected to Server B with 2012 OS.

Symantec Backup Exec 12.5  Server is Windows 2003 Server with 32-bit app instance. Backup Server further backs up the dumped files (on Server B) onto Tape Media.

The files are dumped as standard Windows Image file (VHDX) on Server B.

Now my issue is I’m unable to restore the files either to a locally connected storage or on Same Server B (different Drive).

Initial series of failures made me realize that I can’t restore only one drive’s backup from whole set of WindowsImageBackup. So I had to restore the whole thing to get the VHDX in question.

The Sizes of VHDX files in WindowsImageBackup dump are lesser than 1.6TB. Anti-Virus on Both Server B and Backup Server is disabled. Admin privledges to Service Account used for Backup & Restore has been granted on Restore location, Folder & Drive.

Please HELP!!

Br,

Khurram

Operating Systems:

Comments 24 CommentsJump to latest comment

KhurramNaim's picture

Sorry, Forgot to add. Job failed after some 71 hours and it was running on 20-30 MB/min.

The error is belw:

Completed status: Failed
Final error: 0xe0008488 - Access is denied.
Final error category: Security Errors

For additional information regarding this error refer to link V-79-57344-33928

Access denied to file WindowsImageBackup\ServerName\Backup 2013-11-07\ABC.vhdx.
Error writing file data.
Access denied to file WindowsImageBackup\ServerName\Backup 2013-11-07\DEF.vhdx.
Error writing file data.
Access denied to file WindowsImageBackup\ServerName\Backup 2013-11-07GHI.vhdx.
Error writing file data.

 

Colin Weaver's picture

Are you really on BackupExec 12.5 and NOT 2012 SP2 or SP3? As if you are then nothing in Windows 2012 is supported by that old version and you may therefore have somehow managed to back something up using a method that is invalid, resulting in inability to restore.

 

As such please confirm the BE version

KhurramNaim's picture

Hi Colin,

Actually Server A is a deduped File Server. Since BE 12.5 Rev 2213 version doesnt support that so I'm doing it this way. The same is being done for SQL 2008 R2 as well and that works perfectly fine, had done couple of restores earlier. With this logic I'm just collecting files from symantec

pkh's picture

VDHX is a new kind of file introduced in Server 2012. They may not be compatible with older versions of Windows Server. Have you check with Microsoft whether they are compatible?

KhurramNaim's picture

Hi PKH,

Logically it shouldn't matter for Symantec to pick files as raw data/files on a storage. The Windows Bakcup Utility dumps backed up data in VHDX format with few XML files. Like mentioned above 2012 Server A dumps the backup image files on 2012 Server B (Anotehr storage is connected to this to reduce load on Server A while Symantec Backups are running). From Server B those files are backed up to Tapes directly. Its HP library MSL 6000 series.

This scenario helped me reduce the file sizes by few TBs across fileshare servers and Backup time reduced from 8-10 days to 1-2 days.

Please Please correct me where ever I'm wrong and guide me.

Br,

Khurram

Colin Weaver's picture

The problem Tech Support have with your 'solution' is that we have never tested that combination of products (and never will as BE 12.5 will not be updated to specifically support VHDX or Windows 2012)

As such your configuration is classified as an "Alternate Configuration" and not officially supported. (Please see the General Information Section  at the start of our Software Compatibility List for the definition of Alternate Configuration)

 

KhurramNaim's picture

btw, is there any limitation of file size for restore. As in, the file I'm trying to restore is about 1.6 TB and total about 5.8TB.

KhurramNaim's picture

Dear Colin,

Please advice if there is any file size limitation on restore on Backup Exec 12.5.

Br,

Khurram

Colin Weaver's picture

The only file size limiations I am aware of relate to the formats of the disks/tapes and not Backup Exec itself.

As Windows 2012 R2 is involved with an old version of Backup Exec if you are using any of the advanced file systems that are part of Windows 2012 this might be the reason for your problems (ReFS, Dedup etc)

For us to research it though you would have to show us that a version of Backup Exec that does support Windows 2012 (and vhdx) has the same problem.

 

Out of interest exactly how are you backing up vhdx files held on a WIndows 2012 server, are you just opening a file share and browsing in via the share or are you manually copying the files off to a volume owned by Windows 2008 or 2003?

KhurramNaim's picture

Hi Colin,

Would like to share an update. I've performed successful tests, in question to this forum. However, like i was suspecting the size is an issue as of now. I can restore files (VHDX, XML - pertaining to same backup job even selective, not necessarily full) that are smaller in size, i.e., lesser than a GB. I've yet to perform some tests for the various sizes; will take me time as I'm doing this on production environment.

Back to your query; I'm happy to see you are interested to know how this workaround is working. As mentioned above server A & B are both 2012. Windows server 2012 gives me an option to have LUNs bigger than 2TB. This way I've assigned reasonably good storage for file share and disk backup. This disk backup is being done by Windows built-in back-up utility. Once my first level of backup (windows Image Backup) is done, the files are then simply backed-up as flat files from disk to tape. As mentioned earlier logically it should work as for Symantec be it any extension (doc, xml, csv, vhd or VHDX for that matter) should NOT be an issue while backing up, here I'm not refereeing to SQL or SharePoint file type. However, I'm stuck with restoring large file sizes; anything that goes in loads of GBs or TBs.

I can understand your point above in terms of support; frankly i felt it as washing hands off an issue. I do understand to invest time in a support query needs to be justified where "SUPPORTED" app/OS criteria comes first. If you have understood how all this is happening, I'm pretty sure VHDX or 2012 OS won’t be pointed as a reason. As generally speaking either it should work or it should not. It can’t be yes or no both at the same time.

May I ask one more time; have you or anyone from your team has performed a recovery of a file larger than a TB? If yes, what specifications of Symantec Backup Exec server were you having? I'm currently running this on 4GB RAM which has served me well for years by now.

If you feel you need more clarification then please let me know, I will write it down in more detail.

I'll be awaiting your advice.

Br,

Khurram

Colin Weaver's picture

In BE 2012 SP2 and SP3 tests will have been done for the Hyper-V agent and restoring larger VHDX (but still below 2TB) However I doubt we have tested file system backups of these files as you are meant to back them up with the Hyper-V agent. If you are asking about non vhdx files them I believe tested from standard NTFS would have been performed for all sorts of file sizes (within the limits of the file supported files systems and taking into account that 4K sector size support only came in with Windows 2012) Sorry I have no details on machine specifications, although to be honests CPU and Memory are unlikely to affect your issue (other than affecting speed)

Categorically NO TESTS will have been done with be BE 12.5 and VHDX/Windows 2012 and as the last possible release date for updates to 12.5 was in calendar year 2012 if 12.5 does not work, as you seem to require, then we will not be making changes to make it work.

If you can show that either version 2010 R3 or 2012 experiences the same problems then feel free to log a formal support case - at this current time there is little more I can contribute against you issue with BE 12.5

 

 

 

 

SOLUTION
KhurramNaim's picture

Dear Colin,

Sorry for late resposne. I really appreciated you taking out time for my issue. Thanks for your advice as always.

Br,

Khurram

pkh's picture

It is better for you to upgrade to BE 2012 SP3 which supports both BE 2012 and VHDX.  You can upgrade directly from BE 12.5 to BE 2012.  You would need a new set of licence keys for BE 2012.  The upgrade is free if you are on a current maintenance contract.

KhurramNaim's picture

Hi PKH,

Upgrade is always the best option. However in my case it is not yet agreed by my management and we are out of support too. Nevermind will try to figure out something.

Thanks for the advice.

KhurramNaim's picture

btw, is there any limitation of file size for restore. As in, the file I'm trying to restore is about 1.6 TB and total about 5.8TB.

CraigV's picture

Hi,

Decided to weigh in here a bit. Firstly I am NOT a Symantec employee, and I have/do work with other vendor software so I am going to approach this from multiple angles too. I've yet to see a limit on the amount of data you are limited to restore. This would make no sense, especially considering the amount of data that gets restored, be it a physical server, or a full VM environment. I've backed up a 4.8TB SQL database using BE 2010 R3 (in a speed test against CA ARCserve r16) and restored a partial amount of that database using BE 2010 R3 as well. No hassles...

Secondly...ALL software vendors have a lifespan on their software. In the case of BE 12.5, it was released in 2008, and went EoL in 2010. 5 years (nearly 6!) is a lot of time during which there have been 3 versions of BE 2010 (R1/R2/R3), BE 2012 (BE 2012 R2 is in Beta in the new year), and we've gone from Windows 2008, to Windows Server 2008 R2, to Windows Server 2012, and now Windows Server 2012 R2. This excludes the various versions of SQL and Exchange as well.

To say that Symantec are basically washing their hands of your situation is a bit of a cheap shot. It is an old version, and engineering work also ended a couple of years ago. BE 2010 introduced support for newer OS's (of which Windows 2012 is the latest), along with dedupe. Same with BE 2012. Symantec wouldn't be obliged to support any older versions by introducing new features or support, basically because the IT world has moved on.

As an example, CA ARCserve 11.5 (which was out at the same time as BE 12.5) only supports up to Windows Server 2003. CA ARCserve r16 (out at the same time as BE 2010 R3) only supports up to Windows Server 2008 R2. To get support for later versions of Windows, you need to upgrade to ARCserve r16.5.

Again...this is all in my personal capacity. If you don't have support anymore, pkh's advice to upgrade to BE 2010 R3 at a minimum is still sound. If this is urgent (and ALL backups are) considering that you might be able to backup/restore now but might not do so when you really need it, you should find the budget.

But to chastise the company for not supporting your environment with an older version of BE and an OS that isn't supported on it isn't correct.

Thanks!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

KhurramNaim's picture

Hi CraigV,

Thanks for your input. Its easy to upgrade and always hard to troubleshoot issues like we can see from everyone's comments here.

You seem to have picked very well on the conversation above but tell me something I don't know; What specifications have worked for you with the 4.8TB test of yours. If you would like to add on it will be good else anyways I have to await Colin's advice.
Br,
Khurram

CraigV's picture

It was a stock-standard installation of BE 2010 R3 on a SAP QAS box with BE 2010 R3 fully patched. Further than that, as it was a test, I'm not prepared to provide any more information as the server OS was different and I installed a supported version of BE on a supported version of Windows.

The only troubleshooting here is this...BE 12.5 is unsupported for a media server or RAWS installation on Windows Server 2012 (the last OS being Server 2008/R2). You would need to upgrade, but wait for the confirmation.

Thanks!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

KhurramNaim's picture

Hi,

Thanks for your input. To add I've not done Raws installation in my setup for 2012 environment, and BE 12.5 is on W2K3 SP2. I'm picking up files from a shared Drive/Folder. Apologies if my earlier comments/responses been giving wrong idea of scenario.

Br,

Khurram

CraigV's picture

...it has, yes.

However, I trust you have 2 RAWS agent licenses for those 2 servers anyways?

Thanks!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

KhurramNaim's picture

Hi,

Have alot more. Few weeks back decommissioned few servers, so have extra now.

Br,

Khurram

pkh's picture

While I applaud your tenacity in trying to make BE 12.5 work with Server 2012 and VHDX, I hope that you realise that, even if you manage to make this configuration work, it is still unsupported.  As such, Symantec is not obliged to help when there is a problem and you are solely responsible for the success/failure of this unsupported configuration.  Since there is no help forthcoming, have you thought about what you are going to do should your restore fails at a critical moment?

KhurramNaim's picture

Hi PKH,

I turely understand that my workarounds are not supported by Symantec for many reasons as observed in earlier posts. My purpose was to make things work as long as I can; which now has come to the point of revamp eventually.

I'm in paralell backing up my environment with SCDPM as well but since I like the ease of use with Symantec, I was sticking with it.

Anyways, I once again thank to Colin, yourself and Craig for your time and advice.

Br,

Khurram