Written by W. Curtis Preston
Friday, 03 August 2007 01:15
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."
Add comment
Comments
http://www.backupcentral.com/phpBB2
Could u able to send step by step LTO installation and configuration in Redhat Enterprise Linux 4 .
Reg
Kalaiselvan N
This isn't to say it's not copying in tar format (or mpx'd tar format). I'm just saying that it unpacks it and repacks it along the way.
I find it hard to believe that NetVault doesn't do that.
Quote:
Like I said, I find it hard to believe that it's not verifying the copy that it makes, and the only way to do that is to unpack and repack.
Quote:
I'm a big fan of the concept. It's also available in NetBackup, NetWorker, & CommVault.
According to Wikipedia, NBU uses multiplexing to stream data to tape, which comes with its own set of problems.
Quote:
I don't believe NetVault does this; I've been chatting with one of their gurus about VL-to-tape and he said that since it copies in tape format from the VL to tape it streams at maximum speed. This lets you stream as with something like multiplexing. You just need to buy a VL and a VL license. You don't even need a very big VL, just big enough for your biggest incremental. We'll be running them more frequently just-in-case.
But your VL drive array should be fast; LTO-4 drives have a minimum speed of 40MB/sec. We'll use RAID 0 since the data will just be on the drive for mere moments before being dumped to tape, and if there's a failure I can run the job again.
What's everyone's opinion on NetVault's consolidated fulls? They can eliminate fulls entirely.
My initial concern was if there'd be a corruption in the initial full that would then be perpetually copied, but I could do a complete verify the first time to rule that out.
Going to try to talk to one of their customers who is using it in production.
So that there isn't any confusion, the original set of tapes is not perpetually left in the tape library. You are supposed to consolidate off of it with your incrementals to a new, fresh set of tapes which then gets left in the library for next time. The old ones are pulled and sent offsite. So the tapes themselves are always fresh.
So what do you think?
What I meant was that your reclamation thresholds were set for a reason, and your reclamation needs to finish for those reclamation thresholds to have their desired effect: minimizing the number of tape mounts for a restore and maximizing media utilization. While reclamation not finishing one night is no big deal; reclamations not finishing on a regular basis is a big deal:
1. Your restores will end up asking for a lot more tapes
2. Media utilization will hit record low levels.
3. You'll need a bigger tape library or a whole lot of manual tape swapping to continue normal operations.
Can't get your reclamations done? Simply allow more free space on a tape before it is reclaimed. The down sides are, of course, more tape media required and longer restores.
Nota Bene: I haven't used TSM in a few years and so am ignorant on "new" features.
cheers, wayne
Therefore, the number of files in the backup can very much affect the performance of the copy.
Some D2D2T systems, though, can do the copy from disk to tape outside of the backup software. (Integrated VTLs can do this.) When they do it, they just copy bits and bytes and the number of files doesn't affect performance. This is why a friend of mine switched from NBU Vault-based copying to VTL-based copying (in his case, using an EMC CDL) when he was backing up data with many, many files. His copy performance increased several hundred percent.
we're using NBU, AFAIK it transfers the 'tar' files from disk to tape in it's whole. so there are no small files in this case.
RSS feed for comments to this post