I have several sites with 'slow' WAN links (PTP T1 slow). I'd like to do a full backup to an external USB drive and then have the remote site ship it to the datacenter and import it. I found something that says I require a 'Gridstore' license to make this work, but it is only 2 sites!! What is the best way to get my first full imported so I can begin synthetics??? FYI v7.x
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
'Import' first full backup from other media
- Thread starter mansley
- Start date
CraigMcGill
Technical User
You don't need a Gridstor license for this! What you do need is faith! Faith that forever running incrementals and combining them with synthetic fulls will produce backups that accurately reflect the state of your remote server!
Here's what you need to do. After that, I'll explain what I mean about having faith!
Send your drive to the remote site. You'll need a spare Media Agent license there. If you already have the MA software installed there, great. If not, you'll need to install it and configure it using Library & Drive Config to have a mag library using your external drive. Then you'll need to configure the new storage policy (by default one is created for you when you use Library & Drive Config).
Alternatively, what some sites do is ship a small server there that has the MA software and some disk storage already in it, hook it up to the local network, and point the remote server to it via a storage policy.
Do the full backup. You might also like to keep the temporary disk or server there for a few days and run incrementals every night to get a feel for how big they'll be every day.
When you're ready, bring the disk/server back and plug it in to your home network. The next question is: how do you get the data off the temporary storage onto your main storage? This question is essentially: how do I get data off one storage policy onto another? Sadly CV don't provide a mechanism for doing an Aux Copy from one storage policy to another, so you'll need to find another way. It's this: go to the properties of the remote server's sub-client, and change the storage policy from the temporary one that you did the full backup to, to your permanent one. WARNING: WHEN YOU GET A POP-UP ASKING YOU IF YOU WANT TO CONVERT THE NEXT BACKUP TO A FULL, YOU *MUST* SELECT *NO*. Otherwise you will have to repeat this whole exercise (send the disk/server out to the remote site again) because, as you said, you can't do a full over the WAN.
Save that, then right click the sub-client again and select Backup. Change the backup type to Synthetic Full, and UNTICK the option for doing an incremental as well. This will then run a synthetic full, combining the full backup you did to your temporary storage with all of the subsequent incrementals, and write the merged backups to the new storage policy. Voila! Data moved from one SP to another! Once this synthetic has completed successfully, you can disconnect/erase your temporary storage.
Only ever schedule incrementals for your remote server, and run them regularly to keep their size down (if you don't run one for a long time, there might be too much to ship over the WAN in a night). Most sites can only run these at night because they will flood the WAN for the duration of the backup and probably negatively impact on normal user traffic. Most sites find this impact unacceptable so you should only run the incro backups in the wee small hours. You might like to setup an operation window to prevent backup activity during business hours, so that if the thing is still running in the morning, it automatically gets put on hold.
Schedule the occasional synthetic full, perhaps once a week. You might like to do these during the day. As long as you don't also include an incremental backup with them, they'll generate no WAN traffic at all.
Now the faith bit: because you're never running full backups of your remote server (only incros combined with synthetic fulls), there is always the chance that your backups get out of line with your server. Why? Well, because your original full is combined with (say) 7 incrementals (one for each day of the week, if that's how you do things) and made into another full. Then that's combined with another 7 incros and made into a full. Then that's combined with another 7 incros and made into aanother full. Etc, etc, etc. Maybe there'll be no problem, but for me, I've just got concerns that doing this week after week, month after month, year after year, without drawing a line in the sand and doing another proper full backup, well, it might start to skew.
It might. Mightn't it?
Here's what you need to do. After that, I'll explain what I mean about having faith!
Send your drive to the remote site. You'll need a spare Media Agent license there. If you already have the MA software installed there, great. If not, you'll need to install it and configure it using Library & Drive Config to have a mag library using your external drive. Then you'll need to configure the new storage policy (by default one is created for you when you use Library & Drive Config).
Alternatively, what some sites do is ship a small server there that has the MA software and some disk storage already in it, hook it up to the local network, and point the remote server to it via a storage policy.
Do the full backup. You might also like to keep the temporary disk or server there for a few days and run incrementals every night to get a feel for how big they'll be every day.
When you're ready, bring the disk/server back and plug it in to your home network. The next question is: how do you get the data off the temporary storage onto your main storage? This question is essentially: how do I get data off one storage policy onto another? Sadly CV don't provide a mechanism for doing an Aux Copy from one storage policy to another, so you'll need to find another way. It's this: go to the properties of the remote server's sub-client, and change the storage policy from the temporary one that you did the full backup to, to your permanent one. WARNING: WHEN YOU GET A POP-UP ASKING YOU IF YOU WANT TO CONVERT THE NEXT BACKUP TO A FULL, YOU *MUST* SELECT *NO*. Otherwise you will have to repeat this whole exercise (send the disk/server out to the remote site again) because, as you said, you can't do a full over the WAN.
Save that, then right click the sub-client again and select Backup. Change the backup type to Synthetic Full, and UNTICK the option for doing an incremental as well. This will then run a synthetic full, combining the full backup you did to your temporary storage with all of the subsequent incrementals, and write the merged backups to the new storage policy. Voila! Data moved from one SP to another! Once this synthetic has completed successfully, you can disconnect/erase your temporary storage.
Only ever schedule incrementals for your remote server, and run them regularly to keep their size down (if you don't run one for a long time, there might be too much to ship over the WAN in a night). Most sites can only run these at night because they will flood the WAN for the duration of the backup and probably negatively impact on normal user traffic. Most sites find this impact unacceptable so you should only run the incro backups in the wee small hours. You might like to setup an operation window to prevent backup activity during business hours, so that if the thing is still running in the morning, it automatically gets put on hold.
Schedule the occasional synthetic full, perhaps once a week. You might like to do these during the day. As long as you don't also include an incremental backup with them, they'll generate no WAN traffic at all.
Now the faith bit: because you're never running full backups of your remote server (only incros combined with synthetic fulls), there is always the chance that your backups get out of line with your server. Why? Well, because your original full is combined with (say) 7 incrementals (one for each day of the week, if that's how you do things) and made into another full. Then that's combined with another 7 incros and made into a full. Then that's combined with another 7 incros and made into aanother full. Etc, etc, etc. Maybe there'll be no problem, but for me, I've just got concerns that doing this week after week, month after month, year after year, without drawing a line in the sand and doing another proper full backup, well, it might start to skew.
It might. Mightn't it?
I've just got concerns that doing this week after week, month after month, year after year, without drawing a line in the sand and doing another proper full backup, well, it might start to skew.
It might. Mightn't it? "
Well, no! I've got nearly 3 years of just that running and never had a problem. A synthetic full *IS* a full as far as I'm concerned.
The only time I've had hassle was what looked like a corruption due to some maglib bug creeping in in an update and I wrecked the data so had to ship out a drive to get a fresh full, but that wasn't an issue with synths etc.
It might. Mightn't it? "
Well, no! I've got nearly 3 years of just that running and never had a problem. A synthetic full *IS* a full as far as I'm concerned.
The only time I've had hassle was what looked like a corruption due to some maglib bug creeping in in an update and I wrecked the data so had to ship out a drive to get a fresh full, but that wasn't an issue with synths etc.
Speaking from experience, I wouldn't recommend anyone rely soley on Synthetic Fulls.
A few months ago, I had to do a restore of my own data from a Synthetic Full. Everything seemed fine however, I was missing a fair chunk of old data. I went through roughly 6 months of Sythentic Fulls just to find it. I think this is why Commvault recommends that Fulls still be run occasionally.
Commvault seems to be doing great things in the Remote Office space with CDR and DDR which will hopefully mean that people don't need to rely on the traditional Synthetic Fulls for WAN backups.
A few months ago, I had to do a restore of my own data from a Synthetic Full. Everything seemed fine however, I was missing a fair chunk of old data. I went through roughly 6 months of Sythentic Fulls just to find it. I think this is why Commvault recommends that Fulls still be run occasionally.
Commvault seems to be doing great things in the Remote Office space with CDR and DDR which will hopefully mean that people don't need to rely on the traditional Synthetic Fulls for WAN backups.
- Status
Similar threads
- Locked
- Question
- Locked
- Question