Help/Suggestions with my Backup Plan

[will.daw]

I recently changed my backups from forward incremental with weekly synthetic fulls (30 day retention) to a forever incremental with a 30 day retention. As far as recovery, I have only been able to recover within that 30 day retention with no archives or anything. I have been reading blogs, watching videos, and looking up topics to better my configuration (thanks to everyone who publishes material on the internet). Anyways, I moved my backups away from the synthetics and I have seen a great decrease in my storage space. I now want to use the storage space efficiently and keep more retention days. I am not tied to any company policies that say to keep an x amount of restores. The environment is small with 60 VMs, about 8TB of total backup space, and on the latest V8 build. I have three iSCSI SAN RAID6 servers that I use as my repositories. Since the move to forever incremental, I have narrowed my usage to two SAN servers with plenty of growth. I have the third SAN server to utilize to hold more restore points, but not big enough for archiving.

After researching, I am thinking about reconfiguring the two SAN servers to a RAID10 and changing my retention to 14 days. I have calculated my projection and I am able to do so with room for growth. I am running nightly Surebackups as well, so I want those two SANs to be able to perform on the front line. My thought is to create a Backup Copy job to the third SAN (RAID6) and keep 120 restore points. My question, is 120 restore points on a Backup Copy job too many to keep or will I be hurting the integrity of my data? What would a safe number be? I want to ensure I have the right idea and plan, before I start making the changes. If 120 restore points is okay, then how do I move my 30 day retention to a 14 day retention without losing half the restore points? Would I create the Backup Copy job first and let it catch up on restore points, then change it from 30 to a 14 day retention?

Any help, suggestions, or related links will be greatly appreciated. Thank you.

[foggy]

Hi Will, welcome to the forums.

First of all, you've made the right step when switched to RAID10 for the repository, since it has less I/O penalty and is recommended for backup methods utilizing synthetic activity.

Overall, your plan looks good and here's a handy tool for estimating disk space required for backup repository that will probably help you in more precise planning.

120 restore points long backup chain should not pose consistency issues. However, if you have space, you can cover yourself by enabling weekly retention as well, to have some points in between. Btw, here's a good topic on this matter.

To cut the job retention, you just need to change the number of restore points to keep in the backup job and after the next successful run it will adjust the number of backup files in accordance with the new setting. Backup copy job will copy just the latest VMs state anyway, creating just a single restore point during its first cycle, it does not copy all the restore points available on the source repository.

[will.daw]

Awesome. Next year I will be able to add another repository for GFS purposes. With this plan above and the scale-out repositories coming out in V9. I should be able to group this new repository into my existing backup copy repository, correct? That way, I would only need to edit the backup copy job to include monthly and yearly, right? I think that would save me from having to create a another backup copy job for monthly and yearly restore points.

[foggy]

Yes, your considerations are correct.