Article

brunold's picture
article
Reads:

3809

Score:
0
0
 
Comments:

1

ZLM 7.3 IR1 Disaster Recovery for a Single Primary ZLM Server

(View Disclaimer)

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:

  1. 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

  2. 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.

  3. 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 .
    
    
  4. 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-modules

    to:
    /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.system

    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 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 10636
    tcp        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.system
    NLDAP 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 DER
    CONNECTED(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 -alias
    127.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.
  5. 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/ 
    
    
  6. 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.

  7. 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 
    
    
  8. 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.

  9. 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:

http://forums.novell.com/novell-product-support-forums/zenworks/linux-management/zlm-7x/zlm7-install-setup/

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.
AttachmentSize
ZLM73IR1_Disaster_Recovery.odt41.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.




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!

© 2013 Novell