[p4] backup strategy

John-Mason P. Shackelford john-mason at shackelford.org
Fri Mar 18 10:10:17 PST 2005


Paul et al.

 > Why did you use the "v" option if you were going to direct
 > the "verbose" output to null?

Ha! Because I am a numbskull. I always assumed that -v was 'verify' not 
verbose. Why I made that assumption when the meaning of -v nearly always 
either 'verbose' or 'version' is beyond me. It pays to read the man pages.

My 6.5 hour tar explode was entirely due to a misconfigured SAN 
connection. It now runs in 4 mins 37 secs. Whew! Thanks all for 
suggesting that I solve the real problem before being creative.

An interesting point:

The admins made a great point when I went to see them yesterday: a rapid 
recovery plan won't do us any good if we don't have spare disk to 
recover the data to, so we are going to slop some extra disk in each 
node on the cluster so that if the whole SAN tanks (apparently more 
likely than any of us would like believe) we have a ready alternative.

Another question:

Does anyone had experience tailing the journal file to another disk to 
assist rapid recovery? If doing so didn't impose a significant 
performance hit we could combine it with an rysnc or bu against the 
depot files every few hours so as to keep our spare disk primed for 
recovery--and more currently than the nightly TSM back up of the 
checkpoint and depot files.

IMHO on whatever strategy we land, keeping the system tested is most 
important. We are planning on running monthly test restores and 
switching the running node daily so as to be sure that they are both 
operational.

I'd welcome any other advice.

Thanks for all of your feedback thus far.



John-Mason Shackelford

Software Developer
Pearson Educational Measurement

2510 North Dodge St.
Iowa City, IA 52245
ph. 319-354-9200x6214
john-mason.shackelford at pearson.com
http://pearsonedmeasurement.com



More information about the perforce-user mailing list