SSR 2011 fails to cleanup .v2i recovery points after a backup

[PCJunky]

We have Symantedc System Recovery 2010/2011 across several sights, and we have noticed a common problem occurs where previous recovery points do not get cleaned up post backup as per the rules in the backup job.

Is there anything else we can do to make this more robust without resorting to post backup scripts deleteing files as this will mess up SSR's recovery point history and run the risk of deleting the last good backup if the current backup fails.

Currently we are aware of only 2 places we can automate this process, in the backup job you can set the amount of recovery points to keep, and in the manage backup destination/settings you can set a threshhold based on capacity.

So for example if I am creating a backup files that is 350 gb (final compressed .v2i files), and I have set "Limit the number of recovery points for this backup" to 1, and set the "manage destination settings" to "monitor disk space usage for the backup storage" and set the threshold to 360 gb, also set to "auto matically optomise storage"

Have I missed something here or is there a better way we should be doing this?

From what I can see in the logs, at the point the process should be purging the previous days .v2i files SSR seems to think the backup device is unavailable (when it fails), however the backup device in this specific example is an Iomega NAS drive on a 1GB lan...

Thanks

[criley]

Yes, that pretty much sums it up well.

[PCJunky]

Where we are at so far:

After working through all of the above and finally upgrading to SSR 2011 we were unable to get SSR to run reliably, I am using this very specific customer example to focus on but this is an issue that is affecting us across many customer sites, but it has only become a major issues recently, in this specific case the backup worked very reliably with SSR 2010 for over 2 years.

So whats changed, well apart from patches from Symantec, then other changes would be updates from Microsoft for the OS.

And the size of the data being backed up as it steadily grows, indeed when you look at the example here, of the two servers the small backup (60gb) works reasonably reliably but the larger (285gb) is very unrealiable.

This has lead us to the conclusion that SSR has issues with 150gb+ backups - well certainly when trying to perform a full image on a daily basis.

So with this in mind (and its been very useful to put this down and track it here) we have revisited how we expect SSR to work and have switched the customer above to Incrmental - its early days yet as it has taken us a week or two to work out the kinks (as we havn't used incremental in SSR before) but things are settling down and the prospects look good.

Big backups to entry level network storage does not seem to be a good combination for SSR, but incremental could be the answer, I'll update as we know more...

Andrew

[PCJunky · Accepted solution]

Incremental fixes this, I guess by working round the main issues of a big single backup - you still have to get that initial snapshot image but once thats done your set and the backups are far more reliable.

Thoughts:

SSR has issues creating large single backup images to a network device, so ideally you want to be using SSR with a locally attached device - although further evidence suggests its more of a speed issue so a large backup to a slow local device say USB1 hard disk will have simliar issues, SSR reporting the network connection dropping is a red herring as seperate diagnostics show no network drop outs at the time SSR says there were, its more likey a timeout issue SSR then interperits as a network dropout.

When it starts to go wrong it goes wrong quite quickly over the space of one maybe two weeks as SSR slowly fills the drive, this is due in the majority to the old backup cleanup never taking place when a jobs crashes/fails, compounded by SSR not properly managing the backup location and being able to inteligently groom it - see http://www.symantec.com/docs/TECH167758 a known issues with SSR not grooming old backups, as it works ok for incremental and only affects single image backups - its another reason to go with incremental.

SSR was meant to be a low cost setup and forget backup solution for our small business customers who have no internal IT skills who wanted single image 'snapshot' backups, and while I cannot sing the praises enough for BE, and both Symantecs telephone phone and forum support is without equal in our experiance, sadley SSR has missed the mark for us.

Here's hopeing SSR 2012 continues to build on this and overcomes these issues...