Video Screencast Help

Scheduled backup didn't run

Created: 20 Jan 2014 | 23 comments

I am a new user to SSR13 (formerly a long time user of Backup Exec).  I scheduled a backup to run last night, and it didn't run.  It is now saying it will run tonight.  Everything seems to be in order.  I can't find any error messages anywhere.

Also - can you tell me what (if anything) I need to do to ensure backups are suitable for a disaster recovery restore?  It is unclear to me as to whether or not these backups are image backups that could do a full restore, or whether or not there might be issues due to open files at the time of the backupi.

Operating Systems:

Comments 23 CommentsJump to latest comment

Chris Riley's picture

Without reviewing the logs, it will be difficult to comment on why the scheduled backup did not run last night.

And yes, SSR does 'image' backups - it will backup everything on the volume(s) that you have selected for backup. The whole idea of SSR is to have the ability to do a full restore of a machine in the event of disaster. Product details can be found here:

http://www.symantec.com/system-recovery-server-edi...

Hope that helps.

Dave T1239's picture

Ok, found the log.  Here's the error:

Error EC8F17B7: Cannot create recovery points for job.  Drive Backup of Win7 (C:\)

Error E4F3000B: PreSnap failed on volume . (UMI:V-281-3215-6071)

 

I found this error listed in another post and they said a reboot fixed it.  I tried rebooting and rescheduling the job to run "now", and it seems to be working.  I had rebooted after installing the product, but it seemed to want another reboot.

Dave T1239's picture

Ok, my backup ran for a while and failed with a different error:

Error E7D1001F: Unable to write to file.

Error EBAB03F1: Following Operating System error occured while performing requested operation: 'The requested operation could not be completed due to a file system limitation." (UMI:V-281-3215-6071).

Any ideas?  There is plenty of space on the destination drive.  I watched what it was doing during the backup, and it did successfully create the backup file on the destination drive, and was writing to it for a while, but after a few hours it terminated with this error.

I am coming from Acronis, and Acronis is able to back up this computer to the same destination drive with no problems.  (There are other things I don't like about Acronis though, which is why I'm switching to SSR).  Acronis is also much faster - this image backs up in about 45 minutes on Acronis, on SSR it was saying it would take 3 hours and died after maybe 2 hours.  Speed is nice but not critical to me however - I'm going to be using SSR for nightly backups.

 

 

Chris Riley's picture

Which volumes are you backing up?

If you are backing up C, D, E etc (for example) in the same job, can you try backing up one at a time (as a test)? This will tell us if there is an issue with one or more specific volumes.

TRaj's picture

Are the backups going on a network location ? If yes , have to tried a copy paste or local backup ?

SSR backs up depending on the data getting backed up , and accordingly it takes time to backup the data , if it is a 1TB data , it will probably take 2 hours for full backup , depending on wheather it is backing up to local destination or netowork destination.

It says : "'The requested operation could not be completed due to a file system limitation."

What OS is it ?

I found Microsoft link on research : http://social.technet.microsoft.com/Forums/windowsserver/en-US/e0d55018-cf06-43ca-8e20-dd2bb8494c96/the-requested-operation-could-not-be-completed-due-to-a-file-system-limitation?forum=winserverfiles

However , go to C:\Program Files\Symantec\SSR\Utility\ double click on partinfo.exe and it will generate a txt file.

Open partinfo.txt and check if gives any Warning messages.

Hope this Helps!!

We are requesting you to mark the forums as Solution , so that is makes easier for the viewer to search and refer the posts with "Solutions"

Dave T1239's picture

No, it's an external drive connected via esata. NTFS partition. No problems at all accessing it. Windows 7 Ultimate, 64 bit. The source drive is 4 250gb SSD drives in RAID 0, giving 1TB of storage, about 400gb of data used on the array. The destination is a 1TB drive with about 600gb free. Acronis backs up the same machine fine to the same drive, a full backup image is about 220gb.

I will try partinfo when I am next on the machine, but I don't think there is anything wrong with the drive. This is an SSR issue.

Dave T1239's picture

And I'm just backing up "C:\", Chris.

In any case, the error I'm getting is a write error on the destination, so I wouldn't think it would matter what the backup source is.

Chris Riley's picture

Can you please attach logs (http://www.symantec.com/docs/TECH54539) to this thread and I will take a look for you.

Dave T1239's picture

Ok, I got it working.  The destination drive had compression turned on (in Windows).  When I turned it off, it worked. 

I can live with this, but I still think it's a bug.  Although the backup files are already compressed and compression doesn't really help, there might be other files on the drive that you do want compressed.  Plus, it's an obscure error that took me two days to fix.  Also - Acronis was able to back up fine to the same drive.

Now that I can do a backup, I tried to do a restore.  That didn't work either.  I'll open a new issue on the forum.

Thanks for your help.

Chris Riley's picture

Ok, I got it working.  The destination drive had compression turned on (in Windows).  When I turned it off, it worked. 

I can live with this, but I still think it's a bug.

For what it's worth, I tend to agree with you. Let me test this here to see if I see same results.

Chris Riley's picture

So I could not reproduce this here. I backed up to another local NTFS volume that had compression enabled and the backup worked fine.

Is there anything else about this volume that is different? I assume it's NTFS..?

Dave T1239's picture

Yes, ntfs. It is an external drive connected via esata. The entire drive had compression turned on. It's windows 7 Ultimate 64 bit. Not sure if any of that matters.

Another one for the obscure error department. I am now trying to do a restore and get the error "Hit the end of something" That's all it says. Ha ha - not very informative! I think some prototype code inadvertently made it into the final build.

Dave T1239's picture

Also, my backup was about 230 gig compressed. Maybe that matters?

Dave T1239's picture

Chris - did you make any progress with this?

Chris Riley's picture

Not really I'm afraid. As I said before, I could not reproduce this here.

If you can easily reproduce this issue again, I would recommend that you open a support case so that this can be investigated further.

Dave T1239's picture

Ok, thanks. I did open a support ticket, but frankly those people are difficult to deal with. The ticket is open, but we are not making progress. Once I got past all the "I would be very happy to help you with this" type of talk, they basically told me that it wasn't a bug, it was a feature - that it won't back up to compressed drives by design, since the backups are already compressed and the drive couldn't compress it any further. 

Now we have moved on to the "reached the end of something" issue, but I'm not too hopeful I will get any resolution on that either. What a wacky error message though!

Chris Riley's picture

Can you provide the case number for the backup issue? I will look into this for you.

Do you have a new case number for the restore issue?

Dave T1239's picture

I think the case number is 05876268. I don't have a seperate case for the restore issue. Thanks!!

Chris Riley's picture

Thanks. I'll get back to you on this...

Dave T1239's picture

I'm attaching a screenshot of the restore error "EA390013: At the end of something"

This happened when the restore almost finished.  At the time the error happened, the progress dialog said "Moving data from unused area.".

SymantecError.png
Dave T1239's picture

I should also say that I am doing this restore into a VMWare VM (running on the same machine as the backup machine).  The drive backed up had 334GB used out of a 1TB disk - so the computer backed up had 334GB of space used.  The VMWare VM was configured with a 500GB drive, set to grow as needed.  When the restore finished, and it was "moving data from unused area", the vmdk file for the VM was 341GB, and there was 171GB left on the physical drive that the VMDK resides on.

So it doesn't seem like it could have run out of space, but I thought this might be relevant.

Chris Riley's picture

Based on the calculations here (http://www.symantec.com/docs/TECH126288), you would need 500GB minimum. I would recommend trying again with a virtual disk of 600GB to see if it helps.

I doubt this is related to lack of space (although the above is worth a try) as you should have received an 'invalid disk' message before the restore started if space was an issue

If this does not help, the restore logs would need to be reviewed. This is not something that can be done via the forums though - it would need a formal support case.