| Title: | NetWorker |
| Notice: | kits - 12-14, problem reporting - 41.*, basics 1-100 |
| Moderator: | DECWET::RANDALL .com::lenox |
| Created: | Thu Oct 10 1996 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 750 |
| Total number of notes: | 3361 |
Hi,
I based the backup of a big hospital 8400 ASE cluster on DECnsr where a
crontab script is quieting a big database, is cloning the ADVFS filesystems,
and finally the clones are mounted and saved onto DEcnsr.
I just discover today, in the V4.2A release notes page 7, that all the
files appear to be "sparse" when saved from an ADVFS cloned filesystem.
Our big database is made of 15 big (500Mb->2Gb) MUMPS.DAT ADVFS striped
files that are partially initialized with null codes. So, they are the
perfect candidates to be incorrectly recovered in sparse files instead
of fully allocated files.
The proposed workaround is to copy ("cp") the files to re-create the
fully allocated files. I have now 3 questions:
1) Is it not possible via a special "noholey" asm to force NSR
to backup the file as is?
2) What is happening if the file is restored by overwriting the
one still present on the filesystem? Is it correct? Or do we
have to rename it and then copy it to the original one?
3) I also discover that NSR is not saving the "stripe"
attribute of the ADVFS files. So if a big MUMPS.DAT file is
striped on the 3 volumes of the domain, it is re-created at
the restore time as a normal, non-stripe file.
Is it some work in progress to correct this behaviour?
DU V3.2D-1 NSR V4.2B ASE 1.3
Thanks for your support,
Manu.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 548.1 | DECWET::EVANS | NSR Engineering | Thu Apr 03 1997 10:05 | 23 | |
1) Is it not possible via a special "noholey" asm to force NSR
to backup the file as is?
No. it's automagic
2) What is happening if the file is restored by overwriting the
one still present on the filesystem? Is it correct? Or do we
have to rename it and then copy it to the original one?
rename, copy.
3) I also discover that NSR is not saving the "stripe"
attribute of the ADVFS files. So if a big MUMPS.DAT file is
striped on the 3 volumes of the domain, it is re-created at
the restore time as a normal, non-stripe file.
Is it some work in progress to correct this behaviour?
although I would suspect this to be a bug, I think since this is NetWorker
saving a clone file, not an origianl AdvFS file, this is a side effect of the
clone. If you could try saving a non-clone file that is striped, and found
that a recover made it come back non-striped - that would be a bug, and we
would fix it (if we can... there are only 2 calls we can make to AdvFS, and
we make them now!).
| |||||
| 548.2 | :-( | BACHUS::DEVOS | Manu Devos DEC/SI Brussels 856-7539 | Thu Apr 03 1997 13:06 | 14 |
Thanks for your reply Bruce,
Bad news for me. I wrote a script to crash_recover the big decsafe
service. And now, I have to modify it consequently for the two
problems.
The next time i will go to my customer (University Hospital of Ghent),
I will try the "stripe" file restore from a non-clone filesystem and
come back to you.
May I suggest to find a solution to the "sparse" file restoration by a
specific asm which would invalidate the "hole" file detection?
Manu.
| |||||