Tony Gravagno
Feb 12, 2012, 4:19:23 PM2/12/12
to Pick and MultiValue Databases
I pulled this note by Frank Winans from the "Library Functions" thread
as I think it deserves its own discussion...
Frank wrote:
> {Put this on your checklist when planning a weekend file-save / full file
> restore -- start by cutting yourself a spare 'tape' with a file-save on it
> that had just mds,, "dm" selected, in case the restore fails on one of
> your accounts.
That's a good suggestion. D3 Win & Linux have base systems in a
pseudo-floppy ready for restore but those don't have your
customizations. I haven't done this in a while but I believe a Select
statement just prior to the file-save will get mds and dm as above.
You don't need to DX everything but dm in order to accomplish this.
Note that this is different from getting a t-dump of mds and then an
account-save of dm - the idea is to create a base system that includes
your latest updates.
Also, D3 does something different from R83 and AP. It puts the dm
account into the first position on the tape. This was done
specifically in case a restore blows up in a user account. ( Take a
look at the code for the file-save program if you're interested. ) We
used to start a restore, get some user accounts in, and if it blew up
we'd be challenged with somehow recreating sysprog or dm from pieces.
( I even wrote a program that would scan overflow for an old dm
account and poke back all the d-pointers into a new system *gasp* ).
Now (since late 90's?) the dm account is always the first account
restored. If the restore aborts from a user account, you still have a
working system.
It seems many people attempt to restore dm components using sel-
restore. Try restoring the dm account into another account like dm.
120212 (date stamped) and then just copy out of that account. Delete
when done. For D3 Windows, I don't recall doing this for fsi:dm but
that account has data of value as well (Users file!) so you'll want to
include that in your base system save as well.
I think Frank has other good suggestions below. I'll add that it
helps to save a copy of the files used to install the base system
(v9.0) _plus_ the latest installers for the patch set (9.1) which
includes abs, monitor, sql, and other patches. With this you won't
need to download from the TigerLogic FTP site where there is a chance
that the M6 (for example) that you downloaded yesterday isn't the same
as the one there today (usually for good reason). For a restore
you'll need to install the base, then install the update, then restore
all the stuff Frank suggests.
HTH
T
> Put that on your offsite backup media, with an easily-found
> memo telling what the pick release and abs patch level is, and which server
> it belongs to. You probably have a lot more customizations to your dm
> account than your first casual estimate. Suck a copy of
> /user/lib/pick/pick0 in there somewhere, too, and what amount of physical
> ram that server had, and what !who -r and !cat /etc/redhat-release
> showed you. Maybe a copy of the files passwd, shadow, group from linux
> /etc/ if you're feeling especially "mad-eyed"... Oh, and what the D3
> System ID is. Apparently block-printed "Do not discard" at the top of a
> sheet of paper is a subliminal message to 'please shred me now.'}
as I think it deserves its own discussion...
Frank wrote:
> {Put this on your checklist when planning a weekend file-save / full file
> restore -- start by cutting yourself a spare 'tape' with a file-save on it
> that had just mds,, "dm" selected, in case the restore fails on one of
> your accounts.
That's a good suggestion. D3 Win & Linux have base systems in a
pseudo-floppy ready for restore but those don't have your
customizations. I haven't done this in a while but I believe a Select
statement just prior to the file-save will get mds and dm as above.
You don't need to DX everything but dm in order to accomplish this.
Note that this is different from getting a t-dump of mds and then an
account-save of dm - the idea is to create a base system that includes
your latest updates.
Also, D3 does something different from R83 and AP. It puts the dm
account into the first position on the tape. This was done
specifically in case a restore blows up in a user account. ( Take a
look at the code for the file-save program if you're interested. ) We
used to start a restore, get some user accounts in, and if it blew up
we'd be challenged with somehow recreating sysprog or dm from pieces.
( I even wrote a program that would scan overflow for an old dm
account and poke back all the d-pointers into a new system *gasp* ).
Now (since late 90's?) the dm account is always the first account
restored. If the restore aborts from a user account, you still have a
working system.
It seems many people attempt to restore dm components using sel-
restore. Try restoring the dm account into another account like dm.
120212 (date stamped) and then just copy out of that account. Delete
when done. For D3 Windows, I don't recall doing this for fsi:dm but
that account has data of value as well (Users file!) so you'll want to
include that in your base system save as well.
I think Frank has other good suggestions below. I'll add that it
helps to save a copy of the files used to install the base system
(v9.0) _plus_ the latest installers for the patch set (9.1) which
includes abs, monitor, sql, and other patches. With this you won't
need to download from the TigerLogic FTP site where there is a chance
that the M6 (for example) that you downloaded yesterday isn't the same
as the one there today (usually for good reason). For a restore
you'll need to install the base, then install the update, then restore
all the stuff Frank suggests.
HTH
T
> Put that on your offsite backup media, with an easily-found
> memo telling what the pick release and abs patch level is, and which server
> it belongs to. You probably have a lot more customizations to your dm
> account than your first casual estimate. Suck a copy of
> /user/lib/pick/pick0 in there somewhere, too, and what amount of physical
> ram that server had, and what !who -r and !cat /etc/redhat-release
> showed you. Maybe a copy of the files passwd, shadow, group from linux
> /etc/ if you're feeling especially "mad-eyed"... Oh, and what the D3
> System ID is. Apparently block-printed "Do not discard" at the top of a
> sheet of paper is a subliminal message to 'please shred me now.'}
Kevin Powick
Feb 12, 2012, 4:34:15 PM2/12/12
to mvd...@googlegroups.com
On Sunday, 12 February 2012 16:19:23 UTC-5, Tony Gravagno wrote:
D3 Win & Linux have base systems in a
pseudo-floppy ready for restore but those don't have your
customizations. I haven't done this in a while but I believe a Select
statement just prior to the file-save will get mds and dm as above.
On D3/NT, I often save the base system to the default pseudo0 but, admittedly, not part of a regular process .
SELECT MDS WITH *A1 EQ "D]"
> n items selected
SAVE (FDT
With D3/NT, you inevitably lose VME space over time and must restore the VME to get it back. Always do the above just prior to "d3vme.exe /restore" to ensure you have the most up-to-date information.
--
Kevin Powick
Tony Gravagno
Feb 12, 2012, 7:10:21 PM2/12/12
to mvd...@googlegroups.com
Anyone have a feel for how the very latest v9 does with
VME frame loss? I thought they nipped that one in early 9.0. People don't
ask me about this so I haven't seen anything recently.
T
fwinans
Feb 12, 2012, 10:33:20 PM2/12/12
to mvd...@googlegroups.com
> Try restoring the dm account into another account like
> dm.120212 (date stamped) and then just copy > out of that account.
Oooh! Thanks for pointing that out.
But on a crufty old server at a shop that is on an old release
of d3, see if it works before you rely on it.
That is, if doing ct dm.120212,users,
shows you a q pointer to dm account Users file,
instead of a d pointer, then you've been slimed.
Three tweaks come to mind;
a) account-restore verb honors the (x flag for dx-ing it
b) sselect mds,, before your file-save will put the accounts
on a tape in alphabetical order {but dm moves to be first}
c) file-save verb on modern releases of d3 honor (xy option
flags, pass them on to the Save verb instead of dropping 'em.
d) if you have a known enormous file and not much ram, see if
you have problems restoring that account, before you go and
commit to a full file restore. Or cut the tape with that data
section marked DX or DY, and put the actual file data on a
different tape for manual seperate handling. 'Enormous' as in
many hundreds of items averaging over 2 mbytes each, say.
fwinans
Nov 9, 2012, 8:56:15 PM11/9/12
to mvd...@googlegroups.com
Some of the key things you'd like to know when recreating a linux server
'just like the one that died' are
a) fdisk -l # lowercase L
b) cat e/tc/redhat-release # shows if is rhel4 or rhel5 or ...
c) free # shows ram / swap usage
d) getconf | more # masses of trivial settings
# esp getconf LONG_BIT will say 32 or 64
so you know which of the two supplied install media
to use in recreating the server
e) df -h ; cat /etc/fstab ; cat /usr/lib/pick0
# shows how the disk has been sliced, thus far.
# maybe cat /boot/grub/menu.lst which is a link
# {think pick q-pointer} to grub.conf file.
e2) grep processor /proc/cpuinfo shows how many
cpu cores your system has; or run top command
and toggle the per-core display by punching digit 1
{ q will end the top command when you're done.}
f) SYSID from DO NOT DISCARD sheet, or
look at CT MESSAGES CONFIG for same info.
g) what did which (cad say your d3 version(s) are?
h) what is in user-coldstart? what procs/files/verbs are
local tweaks that live in the DM account? You're
gonna migrate to a later release of D3 some day,
so keep a log of what you'll have to fuss with then.
i) cat /etc/inittab to see how many system consoles
are running mingetty to provide linux logins, and how
many d3 printer / serial / console d3 screens are there,
and what the runlevel {3 for nongraphic, 5 for X} is at
boot linux time. Erm, cat /etc/dgrp.backing.store
to see what your lan-attached serial { digi portserverII}
box(es} were set to as ip addresses and /dev/tty* names
cat /etc/resolv.conf to see if you had a nameserver or
gateway line there, and ifconfig -a to show ip address
of server. Oh, cat /etc/hosts, since minor tweaks of
the entries for your own server, localhost can bog down
your recreated system if you get them just slightly wrong.
Erm, cat /etc/*mod* {modules.conf, conf.modules, I dunno}
to show any custom drivers / dvd / tape drive tweaks.
or /root/.bashrc if you've tweaked that, or etc. Ooh!, and
lpstat -s shows what ip addresses and ports {like 9100
for jetdirect} your various linux-side printers were set to.
I like to keep a shell script named cups.recreate.printers
to rapidly remake the cups printers. I almost never use a
web browser to administer the linux printers, it can all be
done with lpadmin commands instead.
j) It bears repeating, you'd really like a file-save tape of just
the bare minimum accounts, so like select mds,, dm
before the file-save. I used to tout having a freshly cut
'abs' image to load, so the patches there match what's
in your tweaked dm,abs, but honestly, it is easier just
to load the factory-supplied dm, as a start, then apply the
patches to same abs-patch level as during the crash, then
do a full files restore to that dm - account - only file-save.
Is your dm account password - protected? Write it down
somewhere and stick that with the tape. Remember
gpg or pgp are effective and simple encryption tools, so
you can document secret stuff for long-range planning.
k) And yes, keep those d3 install files to reuse when you rebuild
the server after disaster. I make /u/d3 and /u/ark folders
on all our client boxes for the install files and 'must have'
copies of small linux tweak files/reports as discussed here,
I've been admiring the clever one-line bash commands
at commandlinefu dot com, but the echo !(pattern)
form {files NOT matching pattern} needs the arcane
bash command shopt -s extglob # extended globbing
to use, or else bash just thinks ! is a "h"istory reference.
Googling to "Bare Metal Restore" describes recreating
a running server from backups, with the implication you
were on a shoestring budget when you cut the backups.
I could have enjoyed that in the last decade, though now
we've moved to 64 bit systems, much of the info is obs.
Frank
On Sunday, February 12, 2012 3:19:23 PM UTC-6, Tony Gravagno wrote:
'just like the one that died' are
a) fdisk -l # lowercase L
b) cat e/tc/redhat-release # shows if is rhel4 or rhel5 or ...
c) free # shows ram / swap usage
d) getconf | more # masses of trivial settings
# esp getconf LONG_BIT will say 32 or 64
so you know which of the two supplied install media
to use in recreating the server
e) df -h ; cat /etc/fstab ; cat /usr/lib/pick0
# shows how the disk has been sliced, thus far.
# maybe cat /boot/grub/menu.lst which is a link
# {think pick q-pointer} to grub.conf file.
e2) grep processor /proc/cpuinfo shows how many
cpu cores your system has; or run top command
and toggle the per-core display by punching digit 1
{ q will end the top command when you're done.}
f) SYSID from DO NOT DISCARD sheet, or
look at CT MESSAGES CONFIG for same info.
g) what did which (cad say your d3 version(s) are?
h) what is in user-coldstart? what procs/files/verbs are
local tweaks that live in the DM account? You're
gonna migrate to a later release of D3 some day,
so keep a log of what you'll have to fuss with then.
i) cat /etc/inittab to see how many system consoles
are running mingetty to provide linux logins, and how
many d3 printer / serial / console d3 screens are there,
and what the runlevel {3 for nongraphic, 5 for X} is at
boot linux time. Erm, cat /etc/dgrp.backing.store
to see what your lan-attached serial { digi portserverII}
box(es} were set to as ip addresses and /dev/tty* names
cat /etc/resolv.conf to see if you had a nameserver or
gateway line there, and ifconfig -a to show ip address
of server. Oh, cat /etc/hosts, since minor tweaks of
the entries for your own server, localhost can bog down
your recreated system if you get them just slightly wrong.
Erm, cat /etc/*mod* {modules.conf, conf.modules, I dunno}
to show any custom drivers / dvd / tape drive tweaks.
or /root/.bashrc if you've tweaked that, or etc. Ooh!, and
lpstat -s shows what ip addresses and ports {like 9100
for jetdirect} your various linux-side printers were set to.
I like to keep a shell script named cups.recreate.printers
to rapidly remake the cups printers. I almost never use a
web browser to administer the linux printers, it can all be
done with lpadmin commands instead.
j) It bears repeating, you'd really like a file-save tape of just
the bare minimum accounts, so like select mds,, dm
before the file-save. I used to tout having a freshly cut
'abs' image to load, so the patches there match what's
in your tweaked dm,abs, but honestly, it is easier just
to load the factory-supplied dm, as a start, then apply the
patches to same abs-patch level as during the crash, then
do a full files restore to that dm - account - only file-save.
Is your dm account password - protected? Write it down
somewhere and stick that with the tape. Remember
gpg or pgp are effective and simple encryption tools, so
you can document secret stuff for long-range planning.
k) And yes, keep those d3 install files to reuse when you rebuild
the server after disaster. I make /u/d3 and /u/ark folders
on all our client boxes for the install files and 'must have'
copies of small linux tweak files/reports as discussed here,
I've been admiring the clever one-line bash commands
at commandlinefu dot com, but the echo !(pattern)
form {files NOT matching pattern} needs the arcane
bash command shopt -s extglob # extended globbing
to use, or else bash just thinks ! is a "h"istory reference.
Googling to "Bare Metal Restore" describes recreating
a running server from backups, with the implication you
were on a shoestring budget when you cut the backups.
I could have enjoyed that in the last decade, though now
we've moved to 64 bit systems, much of the info is obs.
Frank
On Sunday, February 12, 2012 3:19:23 PM UTC-6, Tony Gravagno wrote:
I pulled this from the "Library Functions" thread
as I think it deserves its own discussion...
Frank wrote:
> {Put this on your checklist when planning a weekend file-save / full file
> restore --
<<snip>> }
I {TonyG} will add that it
I {TonyG} will add that it
Reply all
Reply to author
Forward
0 new messages