Forum Discussion

Hactar40's avatar
Hactar40
Level 2
10 years ago

SSR Backups constantly fail

I am running SSR2013 on a Windows2012R2 server trying to back up the two local drives to a NAS device with a shadow copy to a USB drive but it costantly fails with the following:


--Unable to write to file.
---Error EBAB03F1: Following Operating System error occurred while performing requested operation: 'An unexpected network error occurred.'
---Unable to set file size.
----Error EBAB03F1: Following Operating System error occurred while performing requested operation: 'An unexpected network error occurred.'

(UMI:V-281-2001-31)

 

I have checked the following:

There is enough hard drive space on the NAS

All of the permissions are correct

There are no obviously associated event log entries

 

The job starts and creates three ".tmp" files for the bakup of C: and up to 4 ".tmp" file for X: and then it fails. There were about 21 ".tmp" files for the X: drive the one and only time it worked and the system is set to split the files at 9.4GB in size.

The server is hosting two Hyper-V guests and the VHDX files are on the X: drive.

The annoying thing is that the backup worked once last week (running a base backup) and then we had two differentials as well but this week absolutely nothing will work. I have set it up to create a new base backup each week with Diffs every other day (mon-fri)

 

If anyone has any ideas please let me know.

Backup and Recovery
SSR 2013
System Recovery
System Recovery File and Folder Backup
System Recovery Manager
Windows Server (2003-2008)
  • criley's avatar
    criley
    Moderator
    10 years ago

    As a test, can you try the following:

    Backup volume C to a temporary location on X (assuming you have enough free space). How big is the v2i file? Can you then do a file copy of the v2i file from X to the NAS using Windows Explorer? Or does this fail?

  • Hactar40's avatar
    Hactar40
    Level 2
    10 years ago

    Hi Chris,

    This worked OK. I ran a new job (configured as closely to the original as possible) to the X:\TEMP folder which created the following:

     Volume in drive X is data
     Volume Serial Number is C6C6-5EE0

     Directory of X:\TEMP

    08/07/2015  15:17    <DIR>          .
    08/07/2015  15:17    <DIR>          ..
    08/07/2015  15:01             5,330 BGLOW-HOST-A.sv2i
    08/07/2015  15:01     9,625,822,269 bglow-host-a_C_Drive001.v2i
    08/07/2015  15:01     9,625,840,753 bglow-host-a_C_Drive001_s01.v2i
    08/07/2015  15:01       992,973,011 bglow-host-a_C_Drive001_s02.v2i
    08/07/2015  15:17                 0 dir.txt
    08/07/2015  15:01            56,320 RPAM_Store.dat
                   6 File(s) 20,244,697,683 bytes
                   2 Dir(s)  2,759,851,106,304 bytes free

     

    I then copied the folder to the NAS and this all copied across fine.

     

    as an aside - we do seem to be having this problem with a number of systems we look after so it would be good to nail this down if we can.

  • Hactar40's avatar
    Hactar40
    Level 2
    10 years ago

    I have tried to backup just the C: to the NAS and this also appears to have worked. other than the file names being "_C_Drive002." instead of 001 they are all the same.

    does this imply a problem backing ud the drive that has VHDX files on it? do we need to be doing something specific to get this to work or should it work "out of the box?"

  • criley's avatar
    criley
    Moderator
    10 years ago

    So can you do the same test with the volume that hosts the virtual machines (VHDX files)? That may prove your theory.

    I say 'may' because the problem might be intermittent (you mentioned it was working previously).

    • TeleFragger's avatar
      TeleFragger
      Level 5
      6 years ago

      I know this is old.. but im hitting this issue too and looking to see back from the OP..

      for my testing..

      i backed up 4 machines with 20gb and backed up fine.
      Pushed drive space to 80gb and 110gb and cant get one to backup ... fails with this exact error code.

      i am wondering if it is the size of the end v2i file that is limited on the storage end...