After reading the release notes of NSR 4.2c, I found the following
paragraphs concerning.
NOTE. NSR 4.2c can ONLY be run on DEC UNIX 4.x and above, so those
of us on 3.x lookout!
The following problems and restrictions were resolved in
NetWorker Version 4.2B:
o The NetWorker Version 4.2A installation procedure
corrupted indexes larger than 2 gigabytes during index
conversion. Also, NetWorker Version 4.2A index files,
i.e., /nsr/index/clientname/db, that grow larger than
2
gigabytes may become corrupted. A side effect is that
NetWorker Version 4.2A may report strange or negative
values for size, usage, or utilization of indexes.
>>> o Client indexes will not be inadvertently removed by the
reclaim space function.
o Retention Policies Greater than 26 Years - Retention
policies
greater than 26 years do not work properly. If, going
backward in time, the duration represented by the
retention
policy takes you prior to January 1, 1970, the volumes
will
be incorrectly marked recyclable
The following is worth noting:
o Backup with an AdvFS Root File System - If you are
backing up
a client running DIGITAL UNIX 3.2x that has an AdvFS
root
file system, you may encounter an AdvFS bug that causes
NetWorker to fail to properly back up mount points on
root.
If you encounter this problem, contact the CSC for a
patch to
the AdvFS file system.
o Backup of AdvFS File Systems for DIGITAL UNIX Version
3.2C,
3.2D, and 3.2F - If you are backing up a client running
DIGITAL UNIX Version 3.2C, 3.2D, or 3.2F, the AdvFS file
system may not be saved properly. You can resolve this
AdvFS
problem by either installing the consolidated AdvFS
patch
that corresponds to the version of DIGITAL UNIX you are
running or upgrading your DIGITAL UNIX system to Version
3.2G. Contact the CSC for information about how to
obtain
these patches.
o Labeling Two Volumes Concurrently - Do not attempt to
label
two volumes concurrently if both label operations use
the
same label template.
o Sparse Files - NetWorker determines that files are sparse
(or
"holey") by comparing the allocated blocks with the byte
size
(this can be seen using the ls -ls command). If the
allocated
blocks do not account for the size of the file, the file
is
considered to be sparse and saved using an algorithm
that
replaces long strings of zeroes with "holes" in the
recovered
file.
When AdvFS clone filesets are used, AdvFS reports the
number
of blocks allocated to the clone (which is zero, or the
number of blocks on the real file that have been
modified
since the clone creation). Thus, files in a cloned
fileset
always look sparse to NetWorker.
The problem that may occur is that some files that were
not
sparse when saved may be sparse when recovered. Note
that
Oracle databases are zero-filled, fully allocated files
and,
as such, are not "holey." They are particularly
susceptible
to this problem.
At this time, the workaround for this is to use the cp
command to copy the file after recovery. This will cause
a
sparse file to be converted to a fully-allocated file. A
more
permanent solution is being implemented by AdvFS in a
future
release of DIGITAL UNIX.
.
Regards
Dwight Walker
- application/ms-tnef attachment: stored
Received on Mon Aug 25 1997 - 01:45:30 NZST