Hi!
We have to make a full copy of our production server running D3/Linux
7.1.5. We plan using it as a hot backup because of production server
unstability and system availibility requirements.
It's two-disk configuration on it presented by two raw partitions.
What's the simplest way to do a full copy?

Hi Penguin,

Simplest way is "FILE-SAVE". This doesn't cover some of the implied
issues:

You will likely have difficulty with your idea of an HA system however
due to license and software activation issues.

You might want to talk with Ashley Chapman of Billabong Services, he
has a replication server that may work or be made to work with D3.

Another approach would be to dd the D3 partitions but that's going to
be pretty slow and wouldn't work well in an HA environment.
-Tom

And how can I just copy /usr/lib/pick directory to another computer
without data files? Then 'file-save' and restore on the second
computer. Will it work on it?

"Penguin" wrote:
D3 has built-in hot-backup capabilities which send file updates from
the primary box to a secondary. Just copying your data from one
server to another doesn't get you live, "to the second" data updates
from one system to the other - that's why "hot" backup is "hot" rather
than being near-line data replication. A backup server must be
licensed since D3 is actually running on two different systems, but
the backup server licensing cost is only about 15% of the full cost.
Contact your VAR for info, or Raining Data if you don't have a VAR who
knows anything about this.

When planning your disaster recovery consider these questions:
- How long will it take to get completely operational after a failure
of the primary environment?
- Are you sharing any resources that create a critical point of
failure which would preclude getting a backup system running?

Be sure you don't use a cheap scratch box for your backup server. It
won't be able to keep up with updates coming from the primary,
transactions will get backlogged, and if the primary server goes down
you will have a chain of transactions that didn't make it to the
secondary. The backup server should be at least as fast
(CPU/disk/memory) as the primary.

Has anyone actually tried setting up the transaction logging to a unix
file (NFS mount) so that in the even of a system failure, a full
restore and then transaction log restore results in a system that was
as it was just prior to the outage.

We can't justify another D3 licence for redundancy but if I can get all
transactions logged to a unix file I could have a recovered backup
system in 1/2 hour that has updated date up and until the point of the
crash, not just as of last night.

M

I would say you would be much better off addressing why your server is
unstable. Can't this situation be resolved? Servers in this day and
age should run and run. I am hoping you have a good reason why it is
OK that the server is unstable. Isn't that the real problem.

Next question... You say you can't afford the backup server licensing
but how much does this downtime cost in lost manpower and business?

Dick

"Matt Hyne" wrote:
Unfortunately, the answer to whether txlog is stable is subject to
re-evaluation with each D3 release. At least it used to be that way,
just check the Enhancements and Resolutions docs (E&R). At some point
they hat it pretty rock stable, but I don't know if that's still the
case. So my answer is to not trust what anyone here says, make up
your own mind after some testing.

The best way to prepare for using a critical feature like this is to
have your VAR beat the blanks out of it when RD announces each new
beta or patch release - that's what Value-Add Resellers are supposed
to do for you before you load the software and everything goes boom.
Having end-users load patches right after they're issued is just
silly, patching up for one issue might just break something else that
you need more. Ever notice all of the patches that are superceded by
other patches? Those are the fixes that had to be re-fixed after they
went production and got the real testing. So for things like indexing
or txlogging, beta early and beta often.

If you don't have a VAR then you could schedule some downtime and do
your own testing. Get a full save, start the logger, crash the box,
then go through the restore process. When you're all done restore
from the initial save, start the txlog, and let your users back on.

Or to test while users are still on, you can install another D3
virtual machine on the same system. Do this testing before loading
any new patches to your production environment. You can't do this
with monitor patches, only ABS patches. Patch a test environment, do
your save and txlog testing there with lots of restores, and when
you're satisfied that it "should" work, apply the latest patches to
your production environment. Check with RD about licensing I have no
clue how they'd manage that. If this sounds like a plan, call Support
and ask them for the VitMach document.

If you feel more daring, then sure, txlogging is fine, just turn it on
and use it!

T