Discussion:
wish you could do full files restore but stop after just dm account...
(too old to reply)
Frank Winans
2012-02-08 13:07:23 UTC
Permalink
I had a file-save tape the other day that for various reasons could
__not__ be used to do a full file restore. We had to read the tape
using restore-accounts , having created the problem-bearing account
manually first, to work around this. Sadly it is very tedious to extract
your numerous site-specific customizations to dm account from tape...

It sure would be handy to have an option flag to let you do a full file
restore that stops after the first account on tape
{presumably that is DM account}. I'm sure this feature wouldn't
impress new customers enough to make a business case for the
change, though...
Excalibur21
2012-02-12 04:15:03 UTC
Permalink
Post by Frank Winans
I had a file-save tape the other day that for various reasons could
__not__ be used to do a full file restore.  We had to read the tape
using restore-accounts , having created the problem-bearing account
manually first, to work around this.  Sadly it is very tedious to extract
your numerous site-specific customizations to dm account from tape...
It sure would be handy to have an option flag to let you do a full file
restore that stops after the first account on tape
{presumably that is  DM account}.   I'm sure this feature wouldn't
impress new customers enough to make a business case for the
change, though...
HI
I do set this up on each site so that I can quickly something that has
screwed up the work space such as a big power fail with everyone
logged on. It is a trick Mike Raffaele of TData showed me.
I use D3 Windows but I assume that Linux works the same.
Of course all my work is in the FSI. If for some reason you have work
elsewhere then create your list manually.
My way creates a tape with MDS, DM and Spooler.
dev-make -t tape -a "d:\d3backups\basesys,p"
set-device x
select mds with a1 "d]"
file-save
Then using the Windows D3 Device Manager create the save as a tape
device
When necessary run d3vme.exe in the usual way and select your new
tape.
Peter McMurray
Frank Winans
2012-02-12 22:15:53 UTC
Permalink
Post by Excalibur21
Post by Frank Winans
It sure would be handy to have an option flag to let you do a full file
restore that stops after the first account on tape.
HI
I do set this up on each site so that I can quickly something that has
screwed up the work space such as a big power fail with everyone
logged on. It is a trick Mike Raffaele of TData showed me.
I use D3 Windows but I assume that Linux works the same.
Of course all my work is in the FSI. If for some reason you have work
elsewhere then create your list manually.
My way creates a tape with MDS, DM and Spooler.
dev-make -t tape -a "d:\d3backups\basesys,p"
set-device x
select mds with a1 "d]"
file-save
Then using the Windows D3 Device Manager create the save as
a tape device
When necessary run d3vme.exe in the usual way and select your
new tape.
Peter McMurray
a) I was rather hoping for something in future releases that lets you
get back to work when, in all the excitement of doing a full file-save
followed by full file restore, you _forget_ the simple precaution of
_First_ cutting a file-save tape of just the dm account {OK, dm and
spooler is ok too.} Usually the first part of a tape is just fine, and
dm account gets forced to be first account on tape. It is a royal pain
to nit-pick your site-specific changes to factory-supplied dm account
to merge them into the dm/spooler/sqldemo 'file-save' tape that comes
from the installation of d3 {not to mention if you've got any abs
patches,
that 'tape' will have the wrong checksums in dm,abs, file.} On top of
that you essentially cannot account-restore the tape dm account as
new disk account dm.tape without it ditching all your system files like
USERS and PIBS and DEVICES in favor of simple qpointers to the
disk DM account, so you have to laboriously sel-restore those by file#.
b) Note you need to select mds,dm, "dm" "spooler"
or mds,, "dm""spooler" -- you wrote just mds,dm by
mistake...
c) Also note dev-make will only let you create new pseudo-floppy tapes
on d3/nt, if you are on d3/linux you have to just change some existing
tape to reflect your preferred filename. I think that's the dev-chg
verb.
d) but back to the original problem; aside from any insane intricacies of
d3/nt having an fsi:,
even on d3/linux if, say, your third account on tape has a massive
file,
say 500 items of 3 megabytes each, and as a result your restore does
a segdump there, well at that point your full file restore is dead in
the
water. You have a mostly-empty mds "account" master dictionary,
{ it may only have one item -- a d-pointer in mds,, called "DM"},
but it will be missing
all the account qpointers you had before, like SYSPROG
all the other non-dpointer items like the
attribute-defining
item "SYSPRIV"}
You will need to manually sel-restore all those non-Dpointer items
from mds,, file by file# off your tape, if you decide to try and limp
along without reverting to the factory-supplied
dm/spooler/sqldemo 'file-save' tape. { Say, I just noticed
that
d3/linux 7.5.0 lets you do count mds,md, without having an
"md" item in the mds,, "file." I could have sworn I saw the "md"
item was required in mds,, just like you need it in all account
master dicts, << for example in 'file' dm,, >> on earlier
d3/linux
releases... seems like it is optional now though.}
{even after patching up mds,, that way, you still won't be healthy
enough to be generating file-of-file items during saves until after
you've done yet _another_ file-save of that semi-working
pick filesystem and done a full-file restore. This time, since the
full file restore concluded normally, it will hopefully run whatever
patch-up programs it normally does after having sucked each account
each account from a tape, and that will make fof work ok again.
Erm, before you repopulate mds,, even the create-account verb
is too impaired to work.
Frank Winans
2012-02-12 22:35:41 UTC
Permalink
Post by Frank Winans
b) Note you need to select mds,dm, "dm" "spooler"
Oops! I meant to write
... select mds,md, "md" "spooler"
Frank Winans
2012-02-13 03:02:33 UTC
Permalink
This post might be inappropriate. Click to display it.
Frank Winans
2013-03-01 12:57:45 UTC
Permalink
On top of that you essentially cannot account-restore the tape dm
account as a new disk account dm.tape without it ditching all your
system files like USERS and PIBS and DEVICES in favor of simple
qpointers to the disk DM account
Oooh! D3/linux doesn't do that nasty Q-pointer substition any more on
restores! Now when you do account-restore dm.tape (x
account-name on tape: DM
it does just that -- creates a dx'd account dm.tape on disk,
being a clone of dm account on currently attached file-save tape,
with no funny business.
Nice.
<< Tested it just now on d3/linux 7.5.0 A9 / M1 / D9
sorry, no idea about how far back they had the fix done... >>
Reminder, on really old d3/nt only the USERS file of dm was q'd to fsi:dm
so you only really had to use extraordinary measures to grab mds,, and
users from tape, othewise just suck tape dm acct into disk dm2 and reach
over account walls with full path names like copying from file dm2,pibs,

Create a file Bucket then sel-restore bucket (N
tell it F then tell it 2 {watch it suck mds,, items that are _not_ d
pointers
into the bucket file} Now you've got bucket for items like acct qpointers
and maybe bucket item "logon" if you had a custom version of that in mds,,
and lastly you can create a file bucket2 and t-rew and sel-restore
bucket2
tell it F
tell it account is fsidm {NOT fsi:dm!!!}
tell it file is USERS
tell it n
tell it n again

Other stuff like bp file of sql acct {which lives in fsi, not vme} come off
tape
with no complaints if you just sel-restore myfile then tell it F tell it
sql tell it BP
and yes, ct mds,, fsidm shows fsi:dm {with the colon, this time}
as in
fsidm
001 QS
002 fsi:DM

Similarly, you can sel-restore users from fsidm acct of a d3/nt file-save
tape
even if you move it over to a d3/linux server, but sadly d3/linux will never
ever
be able to access for example the bp file of the sql acct off tape by any
means
because hey, the tape swears up and down the account name is "fsi:sql"
but sel-restore cannot handle the fsi: prefix, at all on d3/linux
platform.
D3/linux can suck file number 2 off the d3/nt file-save into Myfile ok,
though.

Loading...