Hi Kit,
Three years ago, I used Symantec v2i (a disk image backup
solution) for my clustered SQL Servers running with
replicating databases (though they were not running JDE).
Once the disaster arrived, I was able to recover the
whole install without a glitch, it was straightforward.
Downtime for a 500 Gb database was about 3 hours, which
is not so bad, by the way I was recovering from an
external storage attached by fibre.
These disk image backup solutions are -in theory- easy to
implement, and in case of trouble you just have to boot
from a CD, point to your server image at some network
location or external disk and wait for the progress bar
to reach 100%.
However, at the time Symantec suggested me to restore
to exactly the same disk hardware configuration, which
I agreed.
Given that v2i was based on low-level disk access, it
seemed reasonable to avoid restoring to a different
storage architecture.
As I said, that was a strong limitation but I never
regretted using v2i.
I never tried restoring a v2i backup to a different
architecture, perhaps you'll have the time to test it.
But, in the case of an emergency, it's better to keep
walking on the safe path...
My caveats for this kind of products are :
1. Check backup : is the product compatible with your
storage, SAN, RAIDs, LAN, etc? You have to test it!
2. Check restore : once you boot from the Recovery CDROM,
it should able to recognize your network and your
storage; if not, it should be able to ask you for the
missing drivers (like the "Press F6..." of Windows 2003).
3. Take your time to actually test these procedures,
it's horrible to learn SQL recovery the hard way!
In fact, I had tested the product (before the disaster)
and found out that it didn't recognize my external
storage, so I took some time to search for the drivers
and added them to the v2i list.
Back to your JDE environment...
A nice advantage of these solutions is that they backup
everything at once : registry, pathcodes, PDFs, logs,
SQL databases, C++ compiler, Windows, installed Service
Packs and settings, etc.
They're also great for a WebSphere server backup. It takes
a lot of time to re-install WebSphere plus the bunch
of Fix Packs, HTTP, JAS, JDBC, etc... and doesn't take
much disk space (<10 Gb) so physical image backup is
an efficient solution.
Deployment restore is also quite boring but it's not as
critical as restoring SQL or WebSphere, so you can
always do it the traditional way (DEPLOYMENT\JDELOCAL
databases, the \e812 share and a bunch of INIs and
Registry keys).
I had to assist my customers in several disaster recovery
interventions (usually at Sunday 3:00 AM or so), and
they didn't always have physical image backup products or
duplicated servers, so in that case I was forced to
restore the hard way :
1. Install Windows
2. Install C++, SQL, Internet Explorer, Service Packs, etc
3. Restore SQL db one by one, including differentials and
transaction logs
4. Restore JDE folders
5. Recreate JDE services
6. Pray to God, cross your fingers, close your eyes,
launch JDE services and ask users to reconnect
The advantage of this strategy is that you can restore
to almost any (Intel) hardware as long as its specs are
adequate.
Learn and practice how to restore the hard way... you
never know!
What went wrong? So many things can go wrong...
I remember a few cases :
1. Backup to a write-protected tape. Nobody cared to
read backup logs, so none of their backups was useful
neither. Fortunately enough, I manually ran full backups
before ESU installation and there has been an ESU a
week before the disaster so I could restore their install.
Morale of this sad story : carefully read backup logs.
2. Master database not backed up. After I restored
JDE_PRODUCTION, all my users on the database were
orphaned so had to recreate them all manually, set them
a new password and retyping on P98OWSEC. Lost 1 hour
doing that for 50 users.
Morale of this story : backup all databases, including
system ones.
3. Customer lost its SQL installation CDs. It's not fun
to start searching for JDE, SQL, C++ or Windows CDs on
Sunday 3:00 AM while in the middle of nowhere. Please,
check that you have them in a safe place.
Finally, there are other alternatives to SQL Disaster
Recovery such as database mirroring, log shipping and
replication.
However, I don't like them to much as a solution for JDE
installations, the fact that JDE relies so much in the
machine name makes them a bit cumbersome to implement.
After you restore your data to a server with a different
name you'll have to manually fix 50 or so tables,
OCM, Data Sources, INIs, etc. Though, I have to admit,
it's a bit easier on a pure Web installation than with
Fat Clients or Terminal Servers.
