I have to agree. We've had some pretty upset users here.
Waiting hours to restore one small file is ridiculous to them!!
Rick Smith
Maritz, Inc.
Storage & Security Administration
smithrr AT maritz DOT com
(314) 827-1584
> ----------
> From: Francis Maes[SMTP:fr.maes AT CGER DOT BE]
> Sent: Thursday, April 23, 1998 7:23 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Large ADSM Restores
>
> Taylor,
>
> We are asking ourselves the same question:
> is ADSM really a backup product designed for clients with big disks
> (more
> than 10GB)?
>
> We are facing exactly the same problems plus one: the restore of ONE
> file
> coming from a large disk.
> In 95% of the cases, the "client" need the -1 backup version:
> User mistake occurs in file-a on a large disk of an NT file server on
> day-one,
> incremental backup occurs during night day-one to day-two,
> the client understand his mistake on day-two and ask Help-desk to
> restore a
> backup version of day-one
> Help-desk try to : RESTORE -INACTIVE -TODATE=day-one file-a
> ....... and he waits 2 TO 6 hours to receive an answer from the
> server.
>
> The solution we intent to install:
> Put all the large NT-servers disks on EMC,
> Use FDRSOS on MVS to backup directly those disks to robot cartridges.
> And use ADSM for the "small" disks (<10GB).
>
> Server: ADSM 2.1 L 0,6 on MVS
> DB: 28GB, 18.000.000 entries in the DB, 2 TB backup data on 3490
> cartridges
> Disk backuppool: 14GB will extend to 17GB
> CPU consumption: HUGE (more than DFhsm)
> Clients: NT (55), AIX(10), DecAlpha(8) all ADSM 2,1
>
> V3 will sure be better, V4 more better, V5 more more .......... is not
> a
> good answer for the final user that is waiting on the restore of the
> version -1 of ONE file.
>
>
> Francis.
>
>
> -----Message d'origine-----
> De : Taylor Mitchell <taylor_mitchell AT MSN DOT COM>
> @ : ADSM-L AT VM.MARIST DOT EDU <ADSM-L AT VM.MARIST DOT EDU>
> Date : jeudi 23 avr. 1998 4:13
> Objet : Large ADSM Restores
>
>
> >While much of the discussion in this forum has focused on backup
> performance
> >issues, another issue that is perhaps even more important is restore
> >performance. In particular, as servers have become more powerful,
> have
> >become consolidated, and larger amounts of disk media are attached,
> the
> >implications of a media failure become more serious. For example,
> depending
> >on the average file size, the cpu speed of the client, and the
> network
> >connectivity, the time to restore a larger(e.g. 24 GB) RAID storage
> device
> >could be several hours or even more than one day. If you have never
> gone
> >through the exercise, I would encourage you to restore the contents
> of a
> >entire raid storage unit to a test server. You may be surprised how
> long
> >this can take, especially if there are lots of small files.
> >
> >I'd be interested in hearing from on others on the methods others
> have used
> >to mitigate the risk of an extended outage due to long restore times
> that
> >could be encountered if an entire raid storage unit failed.
> >
> >For example, limit the amount of storage that can be attached to a
> single
> >server?
> >
> >Create prioritized plans to restore "important" data first?
> >
> >Limit use of ADSM to clients below a certain size?
> >
> >Thanks in advance,
> >
> >Taylor
> >
>
|
