Date: Fri, 13 Feb 1998 09:32:01 -0500 From: sbabkin@dcn.att.com To: hackers@FreeBSD.ORG, matthew@netsol.net Subject: RE: Large system backups; recommendations for devices & strategie s? Message-ID: <C50B6FBA632FD111AF0F0000C0AD71EE413293@dcn71.dcn.att.com>
next in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
The most I did was 6 systems (3 pairs) and 20G of data :-) The idea
was the following:
there is one backup system. Once a week a full backup is done
manually (in meaning that it's necessary to manually insert tapes,
kick off the backup scripts and check their results for errors,
after that manually put tapes into safe). During the week
this system has a tape with ongoing data. We changed this tape
once a day (manually, with storing all the tapes unused at
the moment in a fireproof safe) by two reasons:
1. In the worst case (like total destruction by fire) we can tolerate
loss of one day of data, but better not more.
2. The tape is big enough (DDS-2 120m) to store all data for one day,
so we don't need to change it more often.
Application explicitly stores the data into a separate hierarchy
of directories (the same as the main one). A particular case of
that is Oracle archived logs. This second hierarchy gets polled,
data transferred as cpio archive to backup server, saved in 2 copies.
The backup servers restores this data into its main directory hierarchy,
after what passes the cpio archive with server ID added to tape server
and initiates removal of backed up data in the backup hierarchy on main
server. After that backup server does any necessary additional
things to newly received data, like applying Oracle archived logs.
The tape servers pours everything it receives into the tape.
The reason for explicit second hierarchy is an attempt to reduce
overhead of searching for new data and reduce the period of polling.
In case when restoration is needed, search the backup log for the
latest occurrence of given file name, get its cpio archive name
and date of copy, take the tape, restore archive from it (mt fsf
is useful with it), and finally restore file from archive.
And there was a like but separate technology for archived data that
has to be stored for several years.
Now I see that they have nothing like in AT&T :-) Although [mostly]
batch
processing of billing data has different requirements than online
operation of a bank.
-SB
> ----------
> From: matthew@netsol.net[SMTP:matthew@netsol.net]
> Sent: Thursday, February 12, 1998 8:05 PM
> To: 'hackers@FreeBSD.ORG'
> Subject: RE: Large system backups; recommendations for devices &
> strategies?
>
> As many times as you can if all this data may e modified from minutes
> ro minutes
> matt at Future Lab
>
> ----------
> From: Mike Smith
> Sent: Monday, February 09, 1998 7:56 PM
> To: hackers@FreeBSD.ORG
> Subject: Large system backups; recommendations for
> devices & strategies?
>
>
> (Please pardon the crosspost to -isp; I'm looking for comments
> from
> people with experience administering backup strategies for
> largish
> networks, and I suspect some of you lurk there.)
>
> I'm looking for recommendations for both backup devices and
> backup
> strategies for a network of about six systems and perhaps 50GB
> of
> data. Ultimately, I'd like something that can run more or less
> unattended, modulo media changes, etc. (ie. I expect using
> Amanda or
> similar.)
>
> I'd be interested in hearing from anyone that's been involved in
>
> setting up and/or operating such a backup system, as well as
> perhaps
> being interested in doing something similar for the FreeBSD
> project.
>
> --
> \\ Sometimes you're ahead, \\ Mike Smith
> \\ sometimes you're behind. \\ mike@smith.net.au
> \\ The race is long, and in the \\ msmith@freebsd.org
> \\ end it's only with yourself. \\ msmith@cdrom.com
>
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe hackers" in the body of the message
>
>
[-- Attachment #2 --]
x>" IPM.Microsoft Mail.Note 1
! D41F388339A4D111AF200000C0AD71EE D RE: Large system backups; recommendations for devices & strategies?
! & 6 p D RE: Large system backups; recommendations for devices & strategies? q 8~ jѳDEST F1 .
LZFu 5
PT ch
setn2 2 prq"stemn3453 _f6Fs1 0ER KsOI8-R}
; 255
`ng103
+ c @
Th e ` I d id wa 6 Fs (3
i9) p"G of"pa :-w$ !"e%
"t!l :
& % !b kup#. Onc!% w k*fu' )F(d)
u@ly# " ?% &% %t'? ) *`
-0to, &ap,
ki)p$$&)V $B*&# s+02`0a.y,pu0e0/Q/ fe)* Dq-!*((#$ 20s".`h)go-$* W! 90
*c$-1,,; --&74u,"% ("00*#eo$7)@/1^w/` " s'1* I85@c"С!(lik@o
ructi DC$ *FF!% ,F $)>rk$?@b7b 5nG" .'2* !s:(bi- `gA;P(DDS- 1m$ 7?*q+A$4K%0DI2,'@) </`<.QM$nMmAp P1`% HrexV.`-!P&$7%
J:`
y=$C!HP?(&/ $0& -a)8!A# 1`+0
_F$(.2 OIcgI$0ZAiv< gsNb9$QY <2p' 0$H q8 4AR cpHp`6/B)V`r?@/ `-a eMf!f 4X+X.` \[&-0Y5<w."
_X5e ?df"PD$0d
T:o5F$Q .`0i`vG$)R<)X1aH\ft]5f , p-0.pr @9H &/`) w-![A3`KGC0 Py-_`'Ni6bp efy{#T|%7u@v* ODu4WUa(% 1/Q H@=f!p$`C-4{$$Bt&0p$b'aMmFFm iV(Sc!1`4&J6r@oc^d*R$g`a!z?@bk#e q$g?1Gb@?@ieGRT>@^(A1+!;.`)?@$BCz{PS`EU$Q("% GCL2YgL`H`Gc.!
:re\QߝfGy.N'@"Q.1&lA gLҁGC-aAT&T%3A4PhO["- ])At
CQ.-s2$:r"
(B quC!Br& 1=aV$% )PnkMm-SB'#
G@180i-x144
е Y1CQQ@-
k 06Fa:6 ,@!w@) 2.[SMTP:t]_m`0!ЁQRb@ebH0/P`?@1998 8:05 PM/ٹmToo't
@P BSD.0ORG'>ubNj[QǟRE0L
T:)Ts;|pBq$Hq4t
v1`&?I0?ü367 'AkRyAH`"y`Ic@%jf -0!bm 7 s/at17'Aq@7 p!Pb_@-2 O
/6MGRS`&??Jaë09ĕ7:5# _zAɏʐA_oҏӟ-(PIF Hn_`b"1/Q- pI':P o1Pu4bb
Qg~1;#WAqpa5-)V4^10sf.DArk0$3!A00D\Q$ג P
P(t.) p;A)U$B)UR<%
ix#$Ba:p` 5$B$cY* U4PJ?" `GR .H0-qUJ.A$Pbف+0/a@r<u
qpcQ-P"`"A0-A,$R@ QA7(g3?㞄y@)..Lp0vIgRL-)
/Qt-4022DѠ*+ALp"KSp' UA#-w0 Sב'Q"?@2001zLp{1dQ2`G`@sRR.au0[sNJTt67c@$bÀ.g0[$D 7בF)fQ:cda. UpsiLp0
kqa ajSpـw<("Bw"tِK\yT?^Wo} L @ 9 `w%8 ? 1@ SBABKIN @ 0@ SBABKIN @ ? G + c=US;a= ;p=ATT;l=DCN71-980213143201Z-14015 ? G ܧ@B +/ /O=ATT/OU=DCNEXCH/CN=RECIPIENTS/CN=SBABKIN ? Babkin, Serge 8@ SBABKIN ? G ܧ@B +/ /O=ATT/OU=DCNEXCH/CN=RECIPIENTS/CN=SBABKIN ? Babkin, Serge 9@ SBABKIN @ 07݈8@ 0Я
&8 = RE: @ Large system backups; recommendations for devices & strategies? 5 ; <C50B6FBA632FD111AF0F0000C0AD71EE413293@dcn71.dcn.att.com> ) # DC " e THEMOSTIDIDWAS6SYSTEMS(3PAIRS)AND20GOFDATA:-)THEIDEAWASTHEFOLLOWING:THEREISONEBACKUPSYSTEMONCEAWEEKA ; <C50B6FBA632FD111AF0F0000C0AD71EE413293@dcn71.dcn.att.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C50B6FBA632FD111AF0F0000C0AD71EE413293>