CPS Retention Policy

[Jason_Stewart_2]

I am using the BE CPS on a Windows 2003 SP1 server.

I would like to keep the versioning / snapshots for longer than 24 hours. I would like to keep each snapshot that is taken during the week. If the limitation of VSS is 64 and I only do 9 snapshots a day then I should be able to keep all 45 for one week (drive space permitting). However the settings in CPS only allow me to keep the last 24 hours and then one a day.

Here is my issue and this happens a lot, if I have a file created on Monday and then it is changed on Tuesday and on Friday I want to go back to Monday's version, I am out of luck.

I have spoken to technical support but was disappointed at their response. So here is my question, even if it is not supported is there a registry hack or an .ini file that I can modify to keep CPS from deleting the snapshots for more than 24 hours? Any help is appreciated.

[perry_baker]

There is no registry change that will allow snapshots to be kept longer. This is a function of hard coded time limits.

[Jason_Stewart_2]

Thanks for the information, although it's not what I was hoping to hear. I would submit this change as a suggestion in the next revision or version.

[Roger_Sager]

Hi Jason...

When I installed 11d of CPS I wanted a snapshot hourly from 7am to 7 pm Mon to Fri...but like you I ran into the same issue...after 64 snapshots (which I understand is for version control/recovery)..the snapshots are removed.
.
So I was trying to be a smart ass...we use Netbackup on our Solaris box that had a L25 tape library ...20 x 360GB tapes. But unfortunately, Netbackup can not see the snapshots...but BackupExec (BE) can...ho ho.. I thought.... I would get BE to backup the snapshots to disk (in the form of ntbackup files)..then config a job in Netbackup to backup these backup files.

Surprise...Surprise...the BE backup of snapshots filled the disk and never finished, even after 422 GB....and the Netbackup job (to backup the CPS backed up snapshots) filled every available L25 tape!

It appears that each snapshot is a complete copy of the backup destination directory structure, not jsut the changes at that snapshot time. So if you have 10 snapshots that's 10 full copies of the target backup destination area. Weird? I thought the snapshot would be just a copy of those files that changed...but no...its the whole 10 yards!!!

If you have BE 11d installed on the CPS server...have a look...you can drill down on any snapshot directory and see a file with a last modified date over 2 or 3 years old? In the wizard to do a Backup...you'll see a selection directory called "Continuous Protection Server", open that up and you'll see "Snapshots", then drill down and you'll see each backup Destination dir..and then each dated snaphot..and so on...
.
So in the end I gave up...I either have a bad understanding of snapshots..or the CPS software needs some work (fixes) with regard to snapshots.

Roger

[perry_baker]

CPS will not keep 64 snapshots; 64 is the maximum possible VSS snapshots. THe reason 64 is relevant is because if you are using VSS for snapshots of the same volume where the CPS Backup Destination resides you could exceed the maximum number of snapshots due to taking snapshots with CPS and scheduled VSS snapshots via the OS.

The snapshots are not complete backups of the Backup Destination Volume. But when viewing a snapshot in BE it displays the full Backup Destination directory structure. the design is that when you backup a snapshot you are backing up a snapshot of the entire Backup Destination directory that existed at that point in time.

But as I read Jason's post he was interested in retaining more snapshots than is possible with CPS.

Jason when you contacted support were you told that you could use BE to backup the snapshots?

[Jason_Stewart_2]

Yes technical support told me I could use BE to backup the snapshots.

I was trying to avoid this for a couple of reasons. First, I wanted to have versioning available in Backup Exec Retrieve for two weeks, for easy restores. Second, the amount of media consumed to backup these snapshots would be substantial.

Before we purchased BE 11d, we were doing full backups every night. This was not working for us because of the time the operation took and the amount of media it required.

With this system I was hoping to do a full backup every weekend for DR and regulation purposes and rely on CPS for the day to day restores.

[perry_baker]

Jason,

Thank you for your response; that is precisely the information I was wanting to know including the aspect that you desire to use BERetrieve to restore "other" file versions beyond what the current snapshots allow.

I have already contact our Product Management team and let them know of your desired enhancement as I have seen this same request in other forum posts. Obviously I can't make any promises as to future features but I can assure you that your request has been noted by the appropriate decision makers.

[Aidan_Finley]

Hello Jason -

From a functional perspective, I am rephrasing what I think you would like to see:

- Keep X snapshots each day
- Keep All snapshots for N days
- Roll snapshots off the system such that the last N days of snapshots are available through BE Retrieve
- Snapshots past N days are protected to tape, or, full system backups are created every N days.

At the end of two weeks you could potentially have (24 per day x 14 days) or 336 snapshots. In the spirit of brutal honesty, this may not be possible with the current level of snapshot retention available through VSS.

Jason, would the requirements listed above match the functionality you would like to see?

Thanks

Aidan Finley
Backup Exec Product Management

[Roger_Sager]

Hi Perry...

Could you please clear up my obvious misunderstanding of what a snapshot is...

I our case we have 4 remote servers that backup to the CPS target server and 2ot the backup destinations each have a separte, physical dik drive allocated to a specific source (remote) server. However, 2 of the remote server share the same backup destination. This is because of the maximum HDD in the CPS server. Anyways, ...I will paint a picture by way of an example to help me understand....

In the case of 1 remote server (call it SYD) the actual file server selected for protection had a total size of all files of 72GB on Monday, Tue it increased to 73GB, then on Wed it increased to 76GB, then 74GB on Thru, and on Fri it was reduced to 70GB...all by way of users saving and deleting files.

If there was only 1 snapshot at the end of day for each day thru the week above..does that mean that the associated snapshots are that same size to reflect the backup destination (BD) at the end of day? Or does it link the file within a specific snapshot to the file in the backup destination and the snapshot's reference (as you can drill down using BE to see the actual files) just holding the changes for version control? So the file as it is in BD, plus any changes from Mon, Tue, Wed, Thur and Fri are used to rebuilt a version of the file as it was on Fri (end of day)?

Cheers Roger

[Jason_Stewart_2]

Aidan,

Thanks for your comments. Here is what I am looking to do; I have the snapshots being taken every two hours, from 9 to 5. This gives me a total of 5 snapshots per day. We have no / very little activity on the weekend so there would be no snapshots for Saturday or Sunday. So for the week, I would have a total of 25 snapshots. Times that by 2 weeks would only put me to 50 total snapshots, well below the OS limitation of 64. I hope this clears up any confusion.

[perry_baker]

Roger,

What you're looking for is more of how VSS maintains snapshots for a volume rather than how CPS works. The best way to visualize what you are asking is to literally watch the VSS snapshot files in the System Volume Information directory on the drive where the snapshots are maintained.

This technote shows how you can locate the snapshots for your Backup Destination.

Document ID: 281173
http://support.veritas.com/docs/281173
Backup Exec Continuous Protection Server (CPS) Snapshots are being deleted by Windows 2003 before reaching the age at which CPS will automatically delete them.

[Aidan_Finley]

Jason - thanks for the clarification. Much appreciated!

As Perry said, he's communicated the need to us in the PM side of the world, and I'll see what I can do to make this proposal a reality in a future release.

Thanks,

Aidan

[Aidan_Finley]

Roger -

Short answer, your statement of "So the file as it is in BD, plus any changes from Mon, Tue, Wed, Thur and Fri are used to rebuilt a version of the file as it was on Fri (end of day)?" is pretty accurate.

Long answer below... :)

In addition to what Perry has said, here's some additional information about VSS and the snapshots it creates.

http://technet2.microsoft.com/WindowsServer/en/library/2b0d2457-b7d8-42c3-b6c9-59c145b7765f1033.mspx?mfr=true

CPS uses the "copy-on-write" aspect of VSS. If it helps, you can think of a snapshot as a "differential" backup. For example, if snapshots were scheduled for 1:00PM and 2:00 PM, that specific snapshot would only contain the differences/changes to that volume made between 1:00 PM and 2:00 PM. The unchanged files on the volume are not in the snapshot; however, they are "linked" via filesystem magic into the snapshot.

So, while the "physical" snapshot contains only the changes between 2 specific times, the entire volume is presented logically to Backup Exec when you do some operation like backup the snapshot.

Going back to your original post, when you backed up *all* snaps to tape, you were effectively doing N *full backups*, because of the logical presentation of the volume that VSS provides us.

Regardless of the amount of differences between a volume at two given times, we've seen that the minimum snapshot size is somewhere arond 300MB. So if one part of a 1MB file changed, the snapshot size will be many times larger than the actual change, because of files sytem overhead.

From a best practices persective, use the "Most Recent Snapshot" or the "Oldest Snapshot" to create Backup Exec Jobs that protect CPS snapshots.

Hope this helps...

Thanks,

Aidan