Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: Recovering database

2 views
Skip to first unread message

Massimo Rosen

unread,
Jun 9, 2009, 5:53:49 PM6/9/09
to
Hi,

diogo scs wrote:
>
> Hi guys,
>
> I'm a totally newbie in Novell, I do my backup using dbcopy with a
> Debian server. I always backup the domain and the post office, I created
> a script to do this... I believe that everything is ok, but I never
> recovery the backup to prove this, how can I do this?

Personally, I use the standalone gwcheck.exe against the backup
Postoffice to verify everything is ok. That's a bit of a trick, but is
good enough for me. Ohter than that, make sure your got a good copy of
your wpdomain.db.

CU,
--
Massimo Rosen
Novell Product Support Forum Sysop
No emails please!
http://www.cfc-it.de

Massimo Rosen

unread,
Jun 10, 2009, 3:46:09 AM6/10/09
to
HI,

jgrubbs wrote:
>
> To verify that the backup is valid, you could point ConsoleOne to the
> wpdomain.db file under Tools|System Operations|Select Domain (I think
> that is the path in GW 6 but it may be worded differently). If it opens
> the database then you know that it is fine.

Well, actually, the only thing that verifies is one single file, namely
wpdomain.db. That does say nothing about the state of the user data in
the PO. But it's a good way to verify wpdomain.db indeed. But it's
pretty important not to forget switching ConsoleOne back to the real
active one. ;)

> For the whphost.db, running a gwcheck maintenance (structure check)
> against it would prove it is valid.

And you still don't know if there's actually readable and complete
content in the backup. Why not run a full content check? Because it
takes long? Who cares?

> Honestly, that is all likely overkill however. If the files are
> present and the same size then they are likely okay.

There is no such thing as overkill when verifying a backup, short of a
full byte by byte verify. Mr. Murphy is everywhere. BTDTGTT just
recently.

> The only way they
> wouldn't be is if the files were somehow locked and could not be
> copied.

There are about a million real world possibilities how files that *look*
identical end up being corrupted internally, *especially* when dealing
with database type apps like groupwise.

0 new messages