You actually cannot restore any kind of Traditional Volume files to NSS
(compressed or not). Even when going from TV's to TV's, or NSS to NSS, if the
source volume was compressed, the target volume also has to be compressed.
There is not, unfortunately, any TSM way to uncompress the files as you restore
them.
Be careful to apply all NSS patches to the servers before attempting to copy
the TV files to NSS also. There have been some bugs in the past that would
cause data corruption during moves across different volume types.
Troy Frank
Network Services
University of Wisconsin Medical Foundation
608.829.5384
>>> Deborah_Bassler AT PAPAJOHNS DOT COM 8/8/2005 1:56:51 PM >>>
Over Labor Day weekend, we are going to upgrade the Netware OS on one of
our servers. This is a critical server, and there is 280G of data. In the
event a restore is necessary, you can see my concern. At 6G an hour, it
will take approx 47 hours to restore (there will be a 100Gb ethernet card,
so it may not take quite 47 hours, but it will still take a while).
Between now and then I'm trying to get some disk space to put all the
backed up data to disk then try testing different restore senarios to a
test server, i.e. restore the directories first.
I don't know if anyone has Novell experience, my expertise are in unix,
but I'm told you cannot restore compressed files from a traditional drive
to nss drives. We have to allocate space for traditional drives on the
server, restore to the traditional drives, uncompress the files, then copy
them to the nss drives (We're trying to get off the traditional drives). I
don't think there is, but does anyone know if there is an option in TSM
that will let us uncompress files when we restore them if they were
compressed before they were backed up?
Also, does anyone have an idea about the speed for a normal restore on a
Novell box using a 100Gb ethernet card?
Thanks for the advice below,,,I am going to try the suggestion when
testing my restore.
Debbie
Maurice van 't Loo < tsm AT COMPARECOMPUTERS DOT NL >
Sent by: "ADSM: Dist Stor Manager" < ADSM-L AT VM.MARIST DOT EDU >
08/04/2005 09:57 AM
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: [ADSM-L] Technote 1200328
Hi Debbie,
If your diskpool is big enoufh, you can try a "move nodedata <nodename>
from=<tapepool> to=<diskpool>" first, so you can restore from disk. Than
you know if the problem is in the library or not.
I also know that Netware is not so fast in building big directory
structures, so you can also win alot with dirmc, than TSM restores the
directory stucture first, and than the files. If posible you can even use
a small diskpool for dirmc's only, what you don't migrate to tape, this is
also a big winner when restoring "slow" FS's as Netware and NTFS.
Regards,
Maurice
----- Original Message -----
From: Debbie Bassler
To: ADSM-L AT VM.MARIST DOT EDU
Sent: Wednesday, August 03, 2005 10:19 PM
Subject: Re: [ADSM-L] Technote 1200328
Oops, I meant to include that in the email. The bottom of this doc shows
the transfer rates..
Lawrence Clark < Larry_Clark AT THRUWAY.STATE.NY DOT US >
Sent by: "ADSM: Dist Stor Manager" < ADSM-L AT VM.MARIST DOT EDU >
08/03/2005 04:10 PM
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: [ADSM-L] Technote 1200328
What did the tranfer rate show as?
1024 x 6.24 = 6389MB (megabyte)
Network is usually in Megabit, yes?
6389MB x 8 = 51112 (megabit)
>>> Deborah_Bassler AT PAPAJOHNS DOT COM 08/03/2005 3:49:17 PM >>>
This doc offers alot of information about improving performance. I'm
especially interested in this because it took 56 minutes to restore
6.24G
of data, from Novell server to Novell server, over a 100MB pipe.
Our TSM version is 5.1.1 ( I know,,,we need to upgrade)...and the
client
version is 5.2.
In the dsmserv.opt file the MIRRORWRITE DB = SEQUENTIAL. According to
this
doc, we'll get better performance is we change MIRRORWRITE DB to
PARALLEL.
I thought I would do this then add the DBPAGESHADOW = YES parameter.
(the
MIRRORWRITE LOG = PARALLEL)
My plan is to make small changes to see if there is an impact, positive
or
negative. We have 2G of virtual memory, so I changed the bufpoolsize
from
262144 to 524288 and thought I'd make the MIRRORWRITE DB change also.
Has anyone made these changes and seen any performance
improvements/degredations? Any experiences or advice is welcome.....
Thanks for any input,
Debbie
Confidentiality Notice follows:
The information in this message (and the documents attached to it, if any)
is confidential and may be legally privileged. It is intended solely for
the addressee. Access to this message by anyone else is unauthorized. If
you are not the intended recipient, any disclosure, copying, distribution
or any action taken, or omitted to be taken in reliance on it is
prohibited and may be unlawful. If you have received this message in
error, please delete all electronic copies of this message (and the
documents attached to it, if any), destroy any hard copies you may have
created and notify me immediately by replying to this email. Thank you.
|
