I know it may sound like an obvious statement, but I think all your backups should fit in one night. Not just 24 hours, but 12 hours or less. Besides the obvious RTO/RPO problems, it just messes up so many parts other parts of the design when backups go over 24 hours. A related issue is that I think it's a bad idea to push all your full backups to the weekend.
What's that, you say? You have backups that go over 12 or 24 hours? Your product does full backups and they run all weekend long, and sometimes into Monday? I think you should look at your design.
- You'll never have time to copy those full backups if they don't finish until Sunday night/monday morning. (I know, you're not doing that either, but that's another blog entry.)
- It masks problems. There's usually nothing that's looking to see if any single backup is running all weekend long, so some of your backups might stop you from meeting any reasonable recovery time objective (RTO)
- It usually means no incrementals when your full backups are running for multiple days, so you've got recovery point objective (RPO) issues as well.
- For TSM customers, instead of full backups, think about expiration and reclamation activities. They'd better finish completely before your next backup cycle, or you've got problems too.
If you do full backups, I'd rather see you spread your full backups out across the week or even across the month. Every night, do a full backup of 1/28th of your environment, do a cumulative incremental or level 1 backup of 1/7th of your environment, and an incremental of the rest. That creates a predictable amount of data backed up each night that you can engineer for — including making copies.
And if you STILL can't get your backups done within 12/24 hours, then we've got more to talk about. Chances are my answer will not be "you need more drives."
----- Signature and Disclaimer -----
Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Architect at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.