Article
You want to know what you need to backup on your ZLM server to be able to start over from scratch and restore the whole system based on the ZLM backups? Then read on …
Depending on your ZLM installation there might be different recovery scenarios for a crashed ZLM server. It might vary if you have just a single primary server you need to rebuild or if you have another secondary server you can configure to be the new primary. It depends if you are able to repair the ZLM server or of you need to reinstall the whole system.
This guide is if you have just a single primary ZLM server without a secondary and you are not able to repair the system. You need to start over with a new SLES and ZLM installation and restore all configurations and backups.
This guide has been tested with ZLM 7.3 IR1 installed on a SLES 10 SP3 x86-64 bit system but might work with other versions as well, whereas some steps might vary a little bit.
Section 1 – Information / Backups you should take on daily or weekly base
You need to collect data from your running ZLM server in two different classes:
The first class contains some basic configuration information like the host name, the name of the ZLM management zone, object store login information and so on. You should collect this information after the initial ZLM installation and best after each upgrade (hot patch or interims release) in case something has changed. I provide a simple shell script at the end of this section where you can see all files you need for a disaster recovery later on. So either use that script or copy them manually to a backup media.
The second class is the real ZLM data from
| the object store (eDirectory) the data store (postgreql or Oracle) the package repository |
- backup via zlm_ndsbackup.sh
- backup via zlm_dbbackup.sh - normal filesystem backup /var/opt/novell/zenworks/pkg-repo |
This second class contains data that might change day by day depending if you mirror additional updates, register new devices, distribute software and so on. The ZLM documentation has a section about this backups:
http://www.novell.com/documentation/zlm73/lm7trouble/data/by5anfd.html
Try to make the backups of the class two data within a short timeframe. Maybe within 30 minutes or so. Then the data should be consistent. Otherwise you might need to run a few additional sync commands afterwards that check the information between the object and data store. The Novell documentation has them listed in the restore documentation section of the various parts.
The script below is intended to run on your running ZLM server to collect the required information. In the second part of it you have the commands for the class two data. Comment that out in case you want to backup that a different way.
My script below creates a backup folder in /images where all relevant information gets stored I need for recovery. I prepared this script for my test environment to make sure I have all information. That test system contained just about 100 packages and 25 bundles and 5 devices and therefor it was no problem to copy the whole packages folder to the backup location. In production that folder is much bigger and it would not fit into that filesystem.
An important note about the package repository … The real RPM files are stored in the /var/opt/novell/zenworks/pkg-repo/packages directory and the "bundles" and "catalogs" folder contain beside other files just links to those package files. Make sure your backup solution backups the links and restores also the links and not the real files. Otherwise it would place the files multiple times into the package repository and the disk usage would grow dramatically. This happened when I simply ran a "cp pkg-repo ..." and later on copied it back.
# cat zlm-backup-all.sh
#!/bin/bash
BACKUPDIR='/images/backup'
DAT=`date +%Y%m%d`
mkdir -p ${BACKUPDIR}
cd ${BACKUPDIR}
######################
### CLASS ONE DATA ###
######################
if [ -e /etc/opt/novell/zenworks/zmd/deviceid ];
then
cp /etc/opt/novell/zenworks/zmd/deviceid ${BACKUPDIR}
cp /etc/opt/novell/zenworks/zmd/secret ${BACKUPDIR}
else
cp /etc/zmd/deviceid ${BACKUPDIR}
cp /etc/zmd/secret ${BACKUPDIR}
fi
# some disk / mount information that the new system can be partitioned similarly
df > disk-layout.log
df > mount.log
cp /opt/novell/zenworks/datamodel/share/ldap-certs ${BACKUPDIR}
cp /etc/opt/novell/zenworks/zlm.conf ${BACKUPDIR}
cp -rp /var/opt/novell/nici .
cp -rp /var/nds/dib .
rm dib/dsbk.pipe
cp /etc/opt/novell/nici* .
cp -rp /etc/opt/novell/zenworks .
cp -rp /etc/crontab .
######################
### CLASS TWO DATA ###
######################
# data store
zlm_dbbackup.sh -H localhost -D ${BACKUPDIR}/zlm_dbbackup-${DAT}
# object store – you need to provide the ZLM Administrator password
zlm_ndsbackup.sh -U admin.system -D ${BACKUPDIR}/zlm_ndsbackup-${DAT} -B
# package repository
tar -cvzf bundles.tar.gz /var/opt/novell/zenworks/pkg-repo/bundles
tar -cvzf catalogs.tar.gz /var/opt/novell/zenworks/pkg-repo/catalogs
cp -Rp /var/opt/novell/zenworks/pkg-repo/files .
cp -Rp /var/opt/novell/zenworks/pkg-repo/packages .
Don't forget to backup your zlmmirror config files as well!
Section 2 – Installation / Configuration of a new SLES / ZLM server
According to the backups from section 1 I copied all those files after the SLES installation into the folder /images/backup and use that as the reference for the shell commands.
So here are the steps to install a new system and restore all configurations and backups:
- Install the new SLES server using the same SLES distribution, patch level and architecture as the old system had. Also assign it the same host name and ip address as the old system had because some zlm configurations depend on this.
If you are not sure about the partition layout you used, check the disk-layout.log and mount.log for information about it. You can resize the filesystems a little bit at this time, but make sure there is enough disk space to restore all information afterwards.
The host name, domain and management zone name (needed in step 2) of the old system can be checked in the backup of the /etc/opt/novell/zenworks/zlm.conf file.
# cat zlm.conf <?xml version="1.0" encoding="utf-8"? > <DataStore > <Session > <ServerAddress > blx-zlm002.brunold.at:10636</ServerAddress > <RootContext > o=cell</RootContext > <Domain > blx_zlm002</Domain > </Session > </DataStore >Hostname: blx-zlm002
DNS domain: brunold.at
ZLM management domain: blx_zlm002 - Install the same ZLM version (ZLM 7.3 IR1 in this case) using the same management zone name as you had on the old system. After the installation run the configuration either as part of the ZLM installation or afterwards via zlm-config manually:
# zlm-install ... HERE COME THE INSTALLATION MESSAGES, NOT INTERESTING AT THIS TIME, THEREFOR I SKIP THEM AND CONTINUE WITH THE CONFIGURATION ... Would you like to run zlm-config now? (y/n) [y]: Detected SuSE Linux Enterprise Server 10 (x86_64) Stopping any zlm services that may be running. Step 1: Gathering Information The first ZENworks Server installed is configured as the primary server. Is this the first server in your system? (y/n) [y]: y Enter a unique Management Zone name: blx_zlm002 (see your zlm.conf) Enter an Administrator password: <old zlm Administrator password > Repeat the Administrator password: <old zlm Administrator password > ZENworks Linux Management requires a database. ZENworks can create a local PostgreSQL database or use an existing PostgreSQL or Oracle database. Do you want ZENworks to install and set up a local PostgreSQL database for you? (y/n) [y]: y ...At this point you would have a newly installed ZLM system you can access via the ZCC but it is missing all data you had on the old one. To verify that this new installation would work, try to login via the ZCC using the ZLM Administrator.
Take care that while you restore the ZLM backups some devices may register with the new installation because the scheduled ZMD refresh takes place. At that time the ZMD refreshes its services and contacts the ZLM server. As it does not find its existing object, it registers again and ZLM uses the default registration rule and places the new object in /Devices/Servers. You would need to check after all ZLM components are restored if you find there some devices that were placed in a different folder before. In that case you could simply delete the devices in /Devices/Servers and the next time it refreshes it finds its correct object.
- Restore the package repository and make sure all files below /var/opt/novell/zenworks/packages are owned by the user zenworks and the group zenworks (recursive).
This steps might vary depending on how you made the backup of the package repository. If you used a backup solution, install that software and restore all the files. The sample below expected that it was copied simply to a different folder and there were tar archives created from the bundles and catalogs directory to protect the links in there.
# cd /var/opt/novell/zenworks/pkg-repo # cp -Rp /images/backup/packages . # cp -Rp /images/backup/files . # cp /images/backup/bundles.tar.gz . # cp /images/backup/catalogs.tar.gz . # tar -xvzf bundles.tar.gz # tar -xvzf catalogs.tar.gz # chown -R zenworks.zenworks .
- Restore the ZLM object store (eDirectory) backup and make sure you use the full path to the backup file
# zlm_ndsrestore.sh -U admin.system -F <backuup file with full path > -B
sample:
# zlm_ndsrestore.sh -U admin.system -F /images/backup/zlm_ndsbackup-20100216/February-2010/2010-02-16/20\:20\:06-backup -B
Provide the ZLM Administrator password
Check the restore log file after this process finishes to make sure no errors occured:
# cat /var/opt/novell/log/zenworks/ndsrestore.log |==================DSBackup Log: Restore================| Log file name: /var/opt/novell/log/zenworks/ndsrestore.log Restore started: 2010-2-28'T11:57:49 Restore file name: /images/backup/zlm_ndsbackup-20100226/February-2010/2010-02-2 6/12:08:39-backup ****************************************************************** Starting database restore... RESTORE STARTED AT 11:57:48 02/28/10 RESTORE COMPLETED IN 0 SECONDS DIRECTORY RESTORED FROM THE BACKUP FILE: /images/backup/zlm_ndsbackup-20100226/ February-2010/2010-02-26/12:08:39-backup ****************************************************************** Restoring file /images/backup/zlm_ndsbackup-20100226/February-2010/2010-02-26/12 :08:39-backup Warning! Roll forward logs have been turned off and reset to the default location Database restore finished Completion time 00:00:22 Restore completed successfully
At this time there seems to be a problem with the restore of the eDirectory security objects (Certificate Authority and the SSL Certificates) and therefor the ZLM server will not be functional after this. The problem is that the certificate authority does not get restored properly and therefor the SSL certificate of the ldap server does not work and the ZLM server does not open port 10636 for secure ldap access. If you are not sure if this situation applies to your current system check it with the following commands:
# rcndsd restart # netstat -tanpu | grep 10636 tcp 0 0 0.0.0.0:10636 0.0.0.0:* LISTEN 12562/ndsd
If you get the LISTEN line your system is okay and eDirectory listens on the secure LDAP port and you can skip to step 5. If that lines does not appear you need to continue here..
I opened a service request with Novell support about this and let them investigate this problem. Till we get a resolution we can resolve the problem on our own with a few extra steps. Hopefully the restore will work with a future hot patch and we do not need the following steps:
This section below might need to be adopted depending on what Novell support comes back with about the eDirectory restore problem.First stop the eDirectory and adopt a library path:
# rcndsd stop
# vi /etc/ld.so.conf.d/novell-NDSbase.conf (for x86-64 platforms only)modify the file from:
/opt/novell/eDirectory/lib
/opt/novell/eDirectory/lib/nds-modulesto:
/opt/novell/eDirectory/lib 64
/opt/novell/eDirectory/lib64/nds-modules
/opt/novell/lib64# ldconfig
# ldapconfig set 'Require TLS for Simple Binds with Password=no' -a admin.systemPassword: <provide the ZLM Administrator password > LDAP Server Configuration: LDAP Server: CN=LDAP Server - blx-zlm002.O=system LDAP Group: CN=LDAP Group - blx-zlm002.O=system Require TLS for Simple Binds with Password set to no LDAP Server refreshed with the new configuration.
Now we delete the eDirectory certificate authority using ldap tools and recreate it afterwards with the ndsconfig command. Take care that you need to insert the name of the ZLM management zone into the ldapdelete command. You used that during the ZLM installation in step 2 and can get it from the backup of the zlm.conf file:
# ldapdelete -H ldap://localhost:10389 -D cn=admin,o=system -W -Z -x 'cn=<ZLM management zone name > -TREE CA,cn=Security'
Password: <provide the ZLM Administrator password >sample:
# ldapdelete -H ldap://localhost:10389 -D cn=admin,o=system -W -Z -x 'cn=BLX_ZLM002-TREE CA,cn=Security'
Now we use ndsconfig to recreate the certificate authority and that also recreates all the server certificates:
# ndsconfig upgrade[1] Instance at /etc/nds.conf: blx-zlm002.O=system.BLX_ZLM002-TREE Migrating the eDirectory configuration file "/etc/nds.conf" to the new configuration file location "/etc/opt/novell/eDirectory/conf/nds.conf"... Upgrading Novell eDirectory server with the following parameters, Please wait... Tree Name : BLX_ZLM002-TREE Server DN : blx-zlm002.O=system Configuration File : /etc/opt/novell/eDirectory/conf/nds.conf Instance Location : /var/nds/data DIB Location : /var/nds/dib Checking if server is ready to service requests... Done Enter admin name with context[admin.org]: admin.system Enter the password for admin.system: <provide the ZLM Administrator password > Performing eDirectory health check... Done For more details view health check logfile: /var/nds/log/ndscheck.log Extending schema... Done For more details view schema extension logfile: /var/nds/log/schema.log Configuring HTTP service... Done Configuring LDAP service... Done Configuring SNMP service... Done Configuring SAS service... Done Associating certificate with the NCP server object... INFO: Server is already associated with a certificate. Done Configuring NMAS service... Done Configuring SecretStore... INFO: SecretStore extensions have already been added to the server. Done Configuring LDAP Server with default SSL CertificateDNS certificate... Done Triggering the 'External Reference Check' process... Done The instance at /etc/opt/novell/eDirectory/conf/nds.conf is successfully configured.
Now we need to migrate the eDirectory configuration file back to the original location:
# mv /etc/opt/novell/eDirectory/conf/nds.conf /etc
and delete the line "/etc/opt/novell/eDirectory/conf/nds.conf"from the file /etc/opt/novell/eDirectory/conf/.edir/instances.0. There must be only one line in containing "/etc/nds.conf".
# rcndsd restart
Now check if the steps above worked and eDirectory is now listening on the secure ldap port:
# netstat -tanpu | grep 10636tcp 0 0 0.0.0.0:10636 0.0.0.0:* LISTEN 12562/ndsd
Now we switch back the TLS requirement as the port 10636 is now open:
# ldapconfig set 'Require TLS for Simple Binds with Password=yes' -a admin.systemNLDAP server configuration utility for Novell eDirectory 8.8 SP3 v20216.73 [1] Instance at /etc/nds.conf: blx-zlm002.O=system.BLX_ZLM002-TREE Password: <provide the ZLM Administrator password > LDAP Server Configuration: LDAP Server: CN=LDAP Server - blx-zlm002.O=system LDAP Group: CN=LDAP Group - blx-zlm002.O=system Require TLS for Simple Binds with Password set to yes LDAP Server refreshed with the new configuration.
As the certificate authority now has changed, we need to export the new public key of it and add it to the java key store ZLM uses for the secure ldap connection to the edirectory:
First grab the password for the java keystore we need to create from your running ZLM server, not the old config file ! Therefor check the file server.xml of the ZLM tomcat instance for it:
# cat /etc/opt/novell/zenworks/tomcat/base/server.xml | grep keystorePass
keystorePass="6629e7bf19a845c1a8ee81cb2da50b89"Then grab the public key of the edirectory certificate authority and copy it to a file eg. called ca.b64:
# openssl s_client -connect localhost:10636 -showcerts -keyform DERCONNECTED(00000003) depth=1 /OU=Organizational CA/O=BLX_ZLM002-TREE verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/O=BLX_ZLM002-TREE/CN=blx-zlm002.brunold.at i:/OU=Organizational CA/O=BLX_ZLM002-TREE -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- 1 s:/OU=Organizational CA/O=BLX_ZLM002-TREE i:/OU=Organizational CA/O=BLX_ZLM002-TREE -----BEGIN CERTIFICATE----- MIIFOzCCBCOgAwIBAgIkAhwU4T7E9RD9k7RX/68pr64twzvO+ApIlj/Xgd5kAgIM DTQnMA0GCSqGSIb3DQEBBQUAMDYxGjAYBgNVBAsTEU9yZ2FuaXphdGlvbmFsIENB MRgwFgYDVQQKFA9CTFhfWkxNMDAyLVRSRUUwHhcNMTAwMjI2MTEyMDA0WhcNMjAw MjI2MTEyMDA0WjA2MRowGAYDVQQLExFPcmdhbml6YXRpb25hbCBDQTEYMBYGA1UE ChQPQkxYX1pMTTAwMi1UUkVFMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEA4yDkpyO/ck67GKDioJHl3LXI623pPAORuAHLJRJcaBziQowZO984snooe7/I yjQ6EqY7KFtJ4xoqCWcTf9MGolb0+Kw1PNHWdp00PIfMoTgh/kLZuBKzCzkpuvhG eOw+Cf3eGRkIS9SMEESTmmurbDWLLMcvttsnqGshm6mdMEF5qklEf4MBp9F15JHi UDfu0g1UQm8g1O2EUltlTfbnGWRAd8Mk6q2mpoiJRr29gyIMGBNeh965X8YVirei kXM9+RkeItcUISPFLKMloaIeU1y7fsMhkzKJE+1U1Xyb5oI+Tl79rHclJJ2jj7RE luGn3V+Yt7dSyxUATcCcSz8iTwIDAQABo4ICLzCCAiswHQYDVR0OBBYEFLmWcUAJ cuaeddzABSVzXafh6IoVMB8GA1UdIwQYMBaAFLmWcUAJcuaeddzABSVzXafh6IoV MAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMIIBzAYLYIZIAYb4NwEJBAEEggG7 MIIBtwQCAQABAf8THU5vdmVsbCBTZWN1cml0eSBBdHRyaWJ1dGUodG0pFkNodHRw Oi8vZGV2ZWxvcGVyLm5vdmVsbC5jb20vcmVwb3NpdG9yeS9hdHRyaWJ1dGVzL2Nl cnRhdHRyc192MTAuaHRtMIIBSKAaAQEAMAgwBgIBAQIBRjAIMAYCAQECAQoCAWmh GgEBADAIMAYCAQECAQAwCDAGAgEBAgEAAgEAogYCARgBAf+jggEEoFgCAQICAgD/ AgEAAw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAwGDAQAgEAAgh//////////wEB AAIEBvDfSDAYMBACAQACCH//////////AQEAAgQG8N9IoVgCAQICAgD/AgEAAw0A QAAAAAAAAAAAAAAAAwkAQAAAAAAAAAAwGDAQAgEAAgh//////////wEBAAIEFOE+ xDAYMBACAQACCH//////////AQEAAgQU4T7Eok4wTAIBAgICAP8CAQADDQCA//// //////////8DCQCA/////////zASMBACAQACCH//////////AQH/MBIwEAIBAAII f/////////8BAf8wDQYJKoZIhvcNAQEFBQADggEBAFIUh1l8IpbIxhK5bni8ZQFa GBtMzqB6LtmN0cSgSMXKgHMUiH3tVcS/xFKQzjLdM7Nhe+ZCGsWsHDAezlcTi/94 zOwNj8L8SnGWkfAjPSSIlXd31pvvxaUXY+u1YOLlP59USe1joX2/lWEPKyjUH62x AulOP6JFoVyrHEmaft4pa4l01mxIsM8dw1FLbJnlVQIcIE4WYYAUUAQ+5/TbwQGR 1Iza0vw1YuiCxiE3uLIa6E5FwyaDgkFqqdO366TFWUieCgOciFYfkQUdQBeKe20F ApDmLGq5VPEYg1DUsH6ISndQgjOn++KJaId2ExlF3RbiAN/oy05pQx6Hd4lVVrg= -----END CERTIFICATE----- --- Server certificate subject=/O=BLX_ZLM002-TREE/CN=blx-zlm002.brunold.at issuer=/OU=Organizational CA/O=BLX_ZLM002-TREE
Take care that you copy the second certificate in the list (1 s:/OU=Organizational CA/O=BLX_ZLM002-TREE) starting with "-----BEGIN CERTIFICATE-----" till "-----END CERTIFICATE-----" into the ca.b64 file.
Now create the new java keystore and copy it to the appropriate location:
# /opt/novell/eDirectory/lib64/nds-modules/embox/jre/bin/keytool -import -file ca.b64 -alias127.0.0.1 -keystore ldap-certs Enter keystore password: <provide the keystore password here > Owner: O=BLX_ZLM002-TREE, OU=Organizational CA Issuer: O=BLX_ZLM002-TREE, OU=Organizational CA Serial number: 21c14e13ec4f510fd93b457ffaf29afae2dc33bcef80a48963fd781de6402020c0d3427 Valid from: Fri Feb 26 12:20:04 CET 2010 until: Wed Feb 26 12:20:04 CET 2020 Certificate fingerprints: MD5: 9A:C6:F7:95:E3:1B:00:38:74:D6:AC:35:50:7E:9C:6F SHA1: 5B:8D:8B:7E:FE:27:89:C1:3B:26:90:42:F4:43:72:29:1A:C3:C1:17 Trust this certificate? [no]: yes Certificate was added to keystore
# cp ldap-certs /opt/novell/zenworks/datamodel/share/ldap-certs
This section above might need to be adopted depending on what Novell support comes back with about the edirectory restore problem. - Restore some other ZLM server configuration files you backed up before:
# cp /images/backup/zenworks/serverid /etc/opt/novell/zenworks # cp /images/backup/zenworks/serversecret /etc/opt/novell/zenworks # cp /images/backup/deviceid /etc/zmd/ # cp /images/backup/secret /etc/zmd/
- Now we need to adopt another section in the ZLM tomcat server.xml that differs because of the new installation and restoring the old eDirectory backups. Therefor get the values from the server.xml of your old ZLM server:
# cat /images/backup/zenworks/tomcat/base/server.xml ... <Realm connectionURL="ldap://127.0.0.1:10636" className="com.novell.zenworks.datamodel.realm.LDAPRealm" connectionName="cn=2a1fd3e190edbdfc76674c43c6058e14,ou=Roles, ou=System,ou=blx_zlm002,o=cell" connectionPassword="96a557c500034fa99aa366edc9eaf548" ...Grab the two lines with connectionName and connectionPassword and replace them in your current server.xml file located in /etc/opt/novell/zenworks/base.
- Restore the datastore (postgresql) information
First grab the current database password:
# grep password /etc/opt/novell/zenworks/hibernate.cfg.xml <property name="connection.password" > 6629e7bf19a845c1a8ee81cb2da50b89</property >Now restore the backup using that database password:
# zlm_dbrestore.sh -F <FILE >
sample:
# zlm_dbrestore.sh -F /images/backup/zlm_dbbackup-20100226/2010-02-26/12\:08\:27-zenworks-backup.tar.gz Checking for Novell ZENworks running Checking for Novell ZENworks Loader running The novell-zenserver needs to be stopped for the database restore to be performed. Would you like to proceed [y/n]? > y Shutting down Novell ZENworks done Checking for Novell ZENworks unused The novell-zenloader needs to be stopped for the database restore to be performed. Would you like to proceed [y/n]? > y Shutting down Novell ZENworks Loader done Checking for Novell ZENworks Loader unused The password for authenticating to the postgres database may be found in /etc/opt/novell/zenworks/hibernate.cfg.xml Dropping the zenworks database. Enter password Password: <provide the database password here > Creating the zenworks database. Enter password Password: <provide the database password here > CREATE DATABASE Restoring the zenworks database from the backup file. Restarting novell-zenserver..... Starting Novell ZENworks done Restarting novell-zenloader..... Starting Novell ZENworks Loader done Success: Restore The restore information may be found in /var/opt/novell/log/zenworks/dbrestore.log. Time taken for restore: 177 secs
- Restart ZLM service and test the restored ZLM system
# zlm-config –restart
As part of the test I would check the zlm logfiles loader-messages.log, services-messages.log and tomcat/catalina.out in /var/opt/novell/log/zenworks for errors since the last zlm restart.
Additional login to the ZLM web interface and see if you have all devices and bundles listed in. Check /Devices/Servers if some devices registered while the restore process was active. In that case delete the device objects under /Devices/Servers and then they will use the original one when they refresh the next time.
Check some bundle assignments and then rug a "rug ref" on a managed device and check with "rug bl" if you see all assigned bundles. Also you can try a bundle installation if you want.
- Restore your ZLM mirror configuration
Depending on how you ran the mirror before (cron or manually) configure the same on your new installation and see if it still works.
So that should be all you need to do that you have a working ZLM server again.
As I said before depending on what Novell comes back about the object store (eDirectory) restore problem some steps might vary a little bit, but then I will post a new guide for the disaster recovery process.
If you expect some problems with this guide feel free to post your question in the Novell public support forums:
I try to help there as much as I can.
Rainer
-------------------------------- Editor's Note: When it comes to disaster recovery, Novell has some extraordinary offerings. Check it out.| Attachment | Size |
|---|---|
| ZLM73IR1_Disaster_Recovery.odt | 41.39 KB |
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.
Related Articles
User Comments
ZLM 7.3 IR1 Disaster Recovery for a Single Primary ZLM Server
Submitted by WilliamByrne on 4 February 2012 - 7:13pm.
Great article, Rainer!
- Be the first to comment! To leave a comment you need to Login or Register


1