[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.
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
I'd welcome any other advice.
Thanks for all of your feedback thus far.
Pearson Educational Measurement
2510 North Dodge St.
Iowa City, IA 52245
john-mason.shackelford at pearson.com
More information about the perforce-user