cancel
Showing results for 
Search instead for 
Did you mean: 

Recovery sets are not being cleaned up

JKisner
Level 4

I have SSR 2013 ver 11.0.1.47662 set to preform a new recovery point every Sunday and incremental backups Mon-Sat.

I've set it to only keep 1 recovery set...however, once Sunday comes, the recovery set isn't cleaned up...instead incremental backups just continue.

This is a problem for me because I have mulitple servers experiencing this and the backup location's disk space runs low resulting in backups failing.

 

I've also googled around and found no real solutions other than it's a known issue:

http://www.symantec.com/connect/issues/automatic-cleanup-recovery-points-not-working-consistently-wh...

 

Is this still a known issue that i just have to manually keep fixing in System Recovery 2013????  Never had this problem in the previous versions.

 

I've tried deleting the backup jobs and creating new, re-installing SSR...no joy.

1 ACCEPTED SOLUTION

Accepted Solutions

JKisner
Level 4

Appears my problems are due to the storage space becoming too low.  More specifically, offsite storage space.

This morning all recovery sets have been created correctly and last weeks removed.  No changes to schedules...only change was to storage location.

 

View solution in original post

20 REPLIES 20

criley
Moderator
Moderator
Employee Accredited

The issue you mention was seen before SSR 2013:

http://www.symantec.com/docs/TECH198360

For this reason, I'm not convinced that issue you describe is the same.

Can you please provide more detail on the following comment you made as this will help us to better understand your issue:

I've set it to only keep 1 recovery set...however, once Sunday comes, the recovery set isn't cleaned up...instead incremental backups just continue.

JKisner
Level 4

I create a new backup job with this criteria:

All Drives
Backing up to a network share with offsite copy to an external harddrive.
Limit the number of recovery point sets saved for this backup...Maximum: 1
Advanced: Divide into smaller files to simpilify archiving: 3857MB
Security: Use password, use AES 128bit encryption
Schedule: 7AM on MON, TUES, WED, THURS, FRI, SAT
Start a new recovery point set (base): Custom Weekly.....7AM on SUNDAY

Initially, I run the backup job manually...after that, the incremental backups work fine.  EXCEPT when Sunday occurs --- the recovery point set is not cleaned up and started new...instead, the incremental backups continue adding to the inital backup.

So what I have weeks of incrementals instead of a fresh recovery point created SUNDAY and incrementals created MON-SAT.

This backup job works fine on 2 servers (2003R2 and 2008R2)...two other servers (2003R2 and 2008R2) it exhibits the above issue.

 

 

criley
Moderator
Moderator
Employee Accredited

This may be an issue with the custom weekly setting then.

Could you please provide a screenshot (from windows explorer) of the contents of the backup destination folder? I would like to see the full filenames for each recovery point file including the date/timestamp.

Do all 4 servers use the EXACT same schedule settings? If yes, are they all running the exact same version of SSR?

JKisner
Level 4

I cleaned up the recovery set by using the recommended method (keeping first and last incremental) yesterday.   I'll post a screen-shot Monday next week of the filenames...

It also seems like this happens more frequently when I request a manual incremental be run off schedule -  I right-click on the icon in the taskbar and run backup....I would typically do this prior to making any system changes or installing updates.

All 4 servers use the exact settings....however, the only difference between all four are the time at which the backups run.  Servers all start their backups about 2 hours a part.....7AM, 9AM, 11AM...etc...etc.  This is typically enough time for a full backup to complete so no more than one server is sending data to the storage location.

JKisner
Level 4

Screenshot of filenames....

Here's what took place...On Tuesday 10/29, we noticed that a complete backup had not been done on Sunday night.  So the backup location was cleaned up through SSR and the backup was run again manually --- creating a new recovery set on Tuesday.

 For some reason the software does want to follow the schedule with a fresh set every Sunday night and incrementals thereafter.  Storing only 1 recovery set...

JKisner
Level 4

No idea at all?   Getting a little bit frustrating coming in each week seeing that the recovery point sets just keep doing incrementals intead of what is scheduled....

JKisner
Level 4

This week I'm trying the following on the servers exibiting the problem:

On the schedule option select:
Sun, Mon, Tues, Wed, Thurs, Fri, Sat

On the when to create new recovery set, select:
Weekly  (prior to this it was a custom weekly - set to Sunday and the above schedule option was unchecked for Sunday)

criley
Moderator
Moderator
Employee Accredited

Sorry for the delay in getting back to you on this.

Let us know how things go since making this change then.

The screenshot you posted earlier shows a full backup on the Tuesday (29th Oct) and then an incremental the following Monday (4th Nov). It seems the previous 4 incrementals in the chain (_i001 to _i004) are missing from the disk. Any reason for this?

JKisner
Level 4

I'm going to assume those incrementals were missing due to consolidating the recovery set (keeping first and last).

JKisner
Level 4

So things remain the same despite the changes made to the schedule.

 

JKisner
Level 4

Did a complete uninstall and removed files and data.  

Reinstalled and set the schedule to run every day of the week and a new set at the beginning of the new week.  Keep only 1 recovery set....

 

 

What is Symantec recommended scheduling setting?  Do you leave the day of the week unchecked or checked if that's the day of the week you want the new recovery point set to run on?

JKisner
Level 4

Here's a schedule of a server that's NOT giving me any problems...

 

Schedule.jpg

JKisner
Level 4

New Schedule I created after uninstalling and reinstalling...I'm assuming that a new recovery point set would be created on Sunday - is this the day that's defined as the start of a new week?

 

Schedule_0.jpg

criley
Moderator
Moderator
Employee Accredited

I'm going to test this schedule here to see what results I get. I will get back to you on this...

JKisner
Level 4

Two servers are still having the same problems.

On 11/26 I uninstalled SSR and rebooted, reinstalled and rebooted, new schedule...

See attached for files and scheduled used.  I'm also splitting the files up at 3.6GB each, password protecting and encrypting with AES 128bit.  Also, copying to USB drive for offsite.

Obviously it didn't run on Sunday 12/1...

pcdata_0.jpg

 

pcdataschedule.jpg

JKisner
Level 4

I've provisioned a new storage drive on another server and am giving that a go.

Is it possible that the new recovery point sets will not delete themselves and start a fresh one when the backup location is near\at capacity?

criley
Moderator
Moderator
Employee Accredited

I don't see this working as you have set the custom weekly option (new set) for a Sunday but excluded Sunday from the schedule.

I think what you need to do is include Sunday in the schedule and set the custom weekly option to a different time on the Sunday. For example, leave the schedule to do an incremental at 6am on Sunday and then set the custom weekly (new set) to 8am. I assume the incremental will have finished long before 8am. If yes, using this schedule will ensure there is no 'clash' between the incremental and the new set (base).

JKisner
Level 4

Appears my problems are due to the storage space becoming too low.  More specifically, offsite storage space.

This morning all recovery sets have been created correctly and last weeks removed.  No changes to schedules...only change was to storage location.

 

TRaj
Level 6
Employee Accredited

Well I just wanted to know what is "Limit the number of recovery points" being set

If this weekend backups run successfully , hopefully this is a storage space issue.