Don't be lulled into a false state of security, though. First, there is a
major performance hit here - you wind up doing at least double I/O - the
server must retrieve the data from disk, then send it to you through the
network, so that you can then send it back through the network to your ADSM
server. Depending on the client this adds significantly - for example, on
Netware V3, not only does the above I/O take place, but the data is
reformatted for presentation to you in a DOS format (since Netware stores data
in a different format). I have been told this is not an insignificant
activity. If it's a NetWare V4 server, the data may be compressed on the
disk, so you would have to decompress it, then send it to you, only to perhaps
have it compressed again. If you backed up straight from teh server, you not
only avoid the extra I/O, but the decompression step can be skipped, and compr
essed data can be handled directly.
And then there is th eissue of rights and permissions. Assuming that the id
that is doing the backup is not a privledged user, then expect that none of
this information will be kept, and thus will be lost when a restore is needed.
And there are other things that you can't backup - for example, the Bindery
in Netware V3, or the NDS in V4. Other platforms would have similar
restrictions, I would expect, such as the registry in NT.
I am very careful when talking to customers about the domain statement, since
if we are not careful, I could have more than one person backing up a network
drive. Now there's an idea that sends shivers down my spine - but the DASD
vendors probably love it. And I have found people doing it too.
If I had to set one of these up, I would also try to limit the use with some
Include/Exclude statements, I do have a couple of managers that need to keep
a backup of files they keep on the server for their own protection - they
don't (or can't) wait for a LAN administrator to do a restore. So I set them
up with a combination that allows them to only backup their own space on a
network drive, which I can live with. BTW, this manager has the computer
knowledge level of the boss in Dilbert, (but fortunately knows it) so we don't
worry about her changing the options file.
Enough Soap box - Is it still Monday?
Jerry Lawson
jlawson AT itthartford DOT com
________________________Forward Header________________________
Author: INTERNET.OWNERAD
Subject: Re: Deleting backup versions on single file.
01-27-97 12:58 PM
Yes, you can explicitly list network drives in the DOMAIN statement in
DSM.OPT, and ADSM backs them up just fine.
>----------
>From: Eric van Loon[SMTP:evanloon AT KLM DOT NL]
>Sent: Monday, January 27, 1997 4:39 AM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Re: Deleting backup versions on single file.
>
>Hi Don,
>> Hi All,,,Looking at the ADSM manuals I read that you cannot delete a
>> single backup version for a file? You have to delete the whole
>> filespace? So if I have a backup that is corrupted, bad data or
>> whatever I have to delete all the backups for that filespace? Please
>> some one tell me I misread something!!
>This requirement has been submitted here before. There is no easy way to
>delete a single backup version. You can only backup the new version a couple
>of time (the amount have set in the copy group properties, 'number of
>versions to keep') but that's a lot of work for just one file.
>
>>
>> Question 2: Can I incrementally backup drives that my machine is not
>> physically connected to? If I NET USE to a different node/domain and
>> my scheduled backup becomes active will it backup the drive I
>> connected to? Or is there a way?
>ADSM doesn't backup network shares by default, however you can select them
>through the GUI. I expect you can back them up by explicitly including them
>in your DSM.OPT file, but I haven't tried it yet.
>Kindest regards,
>Eric van Loon
>
|
