LSTSRV-L Archives

LISTSERV Site Administrators' Forum

LSTSRV-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"Steven P. Roder" <[log in to unmask]>
Fri, 10 May 1996 18:10:34 EDT
text/plain (47 lines)
On Fri, 10 May 1996 17:16:10 EDT Paul M. Karagianis said:
>On Fri, 10 May 1996 14:51:37 EDT Stan Horwitz said:
>>Hello;
>>
>>A problem  with backups  on the  Listserv here  has just  been brought  to my
>>attention. Apparantly, our backup procedure  isn't reliable where Listserv is
>>
>I thought I was reading about SJU.  We're similar except we run *-TCP.
>
>What's the problem?  In our case, if I try to get a FILE back from VMBackup
>I get told that the disk isn't a cms mini-disk, which is news to me.  So
>far I've been able to get what I need by keeping an extra (big!) mini-disk
>around and telling VMBackup to recover the entire disk with the file I need
>to the spare disk.  Ugly, but it works.  Operations says that VMBackup does
>spend a lot of time when it hits those notebook disks (500, 1000 and 1500
>cylinders) so your estimates sound plausible.  Our users don't like us to
>go offline for hours, and if we do then the system is bogged down for hours
>more until we catch up.  So, yeah, I'd say we have a sub-optimal situation,
>but we've gotten by.  So far.
>                                                 -Kary
 
The problem here is that VM:backup detects changes to the data as it is
being dumped, so it rewinds the tapes, and even remounts tapes, if needed,
and trys again, for a configurable number of times, after which the disk
or filespace is either skipped, or dumped physically, which is your case,
Kary.  The only way to get a CMS backup would be to "tell listserv offline"
(or send it email, if -TCP does not accept tell commands) for the dump, and
then "tell listserv online" when it is complete.  In your senario above,
make sure the file that you get back is OK.  Since the disk is changing
while VM:Backup is dumping it, it's conceivable that the physical image
contains "corrupted" files after restoring it.
 
If your lucky, you might backup listserv during a period of "no" activity,
and get a clean CMS dump without taking it offline.  In my case, UBVM
is almost never that idle, so I am now taking it offline on Monday AM,
at 12:05AM, for our FULL dumps.  Our filestores are in SFS, which
exacerbates the problem, since the dumps are a bit slower.  That, and
the fact that LISTSERV occupies 400,000 blocks (about 2700 3380 cylinders,
or just under 2GB) on my system, in addition to a 160 cylinder 191 disk
(about another 112 MB, at 80% used).
 
Hope this helps,
 
Steve
([log in to unmask] | [log in to unmask] | (716)645-3564 ,
   | http://ubvm.cc.buffalo.edu/~tkssteve)

ATOM RSS1 RSS2