how can we safely backup the ghost server?

[Migration User]

for norton ghost, how can we safely backup the ghost server?it has database inside it.Is ther a way export the catalog if there is, or export the database so we can backup it on file level.

Please reply I havent found any info on the site.

thanks is advanced

[Migration User]

I personally use these scripts, for managing my database.

service1.symantec.com/support/on-technology.nsf/docid/2007121015451160

There is a script called "backupdb.wsf" which let you backup the DB of Ghost. On this site, there is also a guide, how to backup your DB.
I hope this one will help you.

Greetings

Alexander emmer

[Migration User]

The latest versions of the scripts are available at http://code.google.com/p/gss-scripts/ where there is also a bug-tracker for reporting any issues with them.

The backup script is described in more detail at http://groups.google.com/group/gss-scripts/web/backupdb

The restore script is described in more detail at http://groups.google.com/group/gss-scripts/web/restoredb

Also remember, it is important that if you use these tools using these to create duplicate GSS server instances (rather than moving an existing server and decommisionning the old one), you need to generate a fresh secure identity for the new server instance, otherwise clients will not be able to distinguish between servers. On the new server instance, you need to:

- go to the installed program directory
- remove the PUBKEY.CRT and PRIVKEY.CRT files which belong to the primary server instance
- stopping the running server instance, using ngserver -stop
- running ngserver -keygen to generate a new keypair
- restarting the server, which you can do by just running ngserver

Doing this ensures that your new server and clients maintain a proper secured connection and that the clients will bind to the correct server.

[Migration User]

Hi Nigel,

The last section in your reply may be what I'm missing as I am having issues with backup/restore and my clients not connecting to the right Console server. I am using the backup scripts to create a "template" configuration of the Console to deploy to multiple new Consoles. When I run the restore of the DB on a freshly built server I am getting "intermittent to no" connection after I clone clients that have been installed on the new Console and end up connecting to a different Console post-clone reboot.

I am writing the PUBKEY.CRT from the new Console to the client in the clone task process, removed the DNSCACHE.TXT file from my client image, and have setup multicast specific IP addresses on each Ghostcast Server Console to be unique private addresses for client subscription (multicast enabled VLANs).

Could neglecting to regenerate the security key after the Console database restore be the culprit of my client reconnection problems?

DJ

[Migration User]

 It's hard to know whether this is the root cause of your particular problem, since all connectivity problems tend to result in the same symptoms; it takes a systematic approach to diagnosis to determine what factors are at play when problems are occurring. WIth connectivity problems, the big thing is that the network itself is a participant - so, we always have at least three separate components to investigate: client, server, and network. Any problem could be due to any of them, even though the end result is "it doesn't work".

This means that the primary way to get evidence of what is going on is to use a traffic capture tool (like WireShark, to take captures from the endpoint's point of view, although routers and switches often have their own diagnostic tools), and one of the most important ways to use it is to get familiar with what normally happens - because when you are trying to diagnose a problem, what you need to be able to see is what *isn't* there, but should be.

So, it may indeed be that the key management is part of what is going wrong for you,  but it would take a lot more evidence to be sure.