IBM Security Verify

 View Only

LDAP Directory server automatic data backup or scheduled ldif backup methods.

By Amrin Maria Khan Adawadkar posted Thu October 17, 2019 03:59 PM

  
By Amrin Maria Khan Adawadkar and Pradip K Jadav
Problem scenario:  

In customer environments, there can be a sudden system crash or data corruption. Having back-ups of data ensures valuable client information is not lost from the LDAP Server. Along with that, it always increases productivity and reduces time wasted in re-adding data manually in a repetitive manner. Using the DB back-up and restore commands work great in this scenario. This comes with its own set of advantages and disadvantages. 

There are many times, there is no other recovery option other than re-building the instance from scratch. Or even creating a new instance on another OS. DB backup and restore may cause issues if instance owners are different on the source and target systems. In such scenarios, a simple import of LDIF file which was backed-up earlier is the best possible solution.  

  • Environment:  

IBM Security Directory Server 6.4 

IBM Security Directory Suite 8.0.1 

  • Solution:  
     
  1. DB Back-up and Restore:  

 

  • idsdbback  
    The following command can be used to take an offline back up of database,configuration, and schema files 

>idsdbback -I ldapdb2 -k /backupdir 

To perform an online backup of server, issue the following command: 

i>dsdbback –n –I <instance_name> -b <outputfile> -u -k <backupdir> 

 

  • idsdbrestore  
    The following command can be used to restore a directory sever's database, configuration files, and schema files: 

>idsdbrestore -I ldapdb2 -k /backupdir 

 

Pros:  

  • The directory server and DB configuration files are backed up.  
  • This can be configured to automatically back-up on a schedule.  
  • Online and offline options are available.  

Cons: 

  • Little flexibility in how the underlying DB2 restore is done.  
  • Restore cannot be directed to distribute the database across multiple disks. 
  • The backed-up files take a large amount of space.  
  • For restore, directory and DB instance names and owners must be same as the source. 

 

  1. LDIF file back-up: 

 

  • idsdb2ldif - export data from a database to a LDIF file.  
    > idsdb2ldif -I <instance_name> -o export.ldif 
  • idsldif2db/bulkload - import the data into the database from the LDIF file.  
    > idsldif2db -I <instance_name -i export.ldif 
     
  • You can even create a bash/python/perl script and schedule a cron job which can execute every week 
  1. Use the idsdb2ldif command in the script 
  1. Give options while executing this script. 
  1. Must options should be full path and output file name. Also, the instance name 
  1. Other options you can provide are remote server details where this file should be sent. Not having it on local system is better in case of a full system crash 
  1. Internally back script will execute idsdb2ldif and then scp to send this file to the remote server mentioned earlier.  

Pros:  

  • portability, standardization, and size factors that these commands provide. 
  • output LDIF file can be used to restore a directory server on a different operating system. 
  • it is relatively easy to modify an LDIF file. 
  • disk space required for an LDIF file with entries is 6 times less than the space required for a DB2 backup with the entries.  
  • Ideal when we want to have a backup of only the entries present in LDAP Server. 

Cons:  

  • time required to complete the process is more as compared to db2 backup and db2 restore. 
  • to restore a directory server by using bulkload, the directory server must be empty.  
  • This process does not backup any other important configurations like ibmslapd.conf or changelog DB configuration.  

 

 

 

 

  • Conclusion: 

If possible, always try to configure automatic DB back-ups on a weekly or bi-monthly schedule. You simply need to ensure the location where backup files are generated has enough space. Even if automatic back-ups are not scheduled, take online or offline back-ups regularly.  

In a situation where complete data corruption has occurred and customer must rebuild the instance, LDIF back up of all entries will help in quickly restoring the LDAP Server. However, it is not an alternative for idsdbback and idsdbrestore. 

Having this LDIF file handy will enable customer to quickly import the users and get the business up and running. An ideal implementation will be when performance tuning, runstats, reorg is done every week, this tool can be run to collect an LDIF back-up.  

  • References:  

https://www.ibm.com/support/knowledgecenter/en/SSVJJU_6.4.0/com.ibm.IBMDS.doc_6.4/c_tg_backuptds_overview.html 

https://www.ibm.com/support/knowledgecenter/en/SSVJJU_6.4.0/com.ibm.IBMDS.doc_6.4/ds_ag_apndix_db2_backup_restore.html 

https://www.ibm.com/support/knowledgecenter/en/SSVJJU_6.4.0/com.ibm.IBMDS.doc_6.4/c_ig_LDIF_data_management.html 

https://www.ibm.com/support/knowledgecenter/en/SSVJJU_6.4.0/com.ibm.IBMDS.doc_6.4/r_cr_dbback.html 

https://www.ibm.com/support/knowledgecenter/en/SSVJJU_6.4.0/com.ibm.IBMDS.doc_6.4/r_cr_dbrestore.html 

https://www.ibm.com/support/knowledgecenter/en/SSVJJU_6.4.0/com.ibm.IBMDS.doc_6.4/r_cr_ldif2db.html 

https://www.ibm.com/support/knowledgecenter/en/SSVJJU_6.4.0/com.ibm.IBMDS.doc_6.4/r_cr_db2ldif.html 

https://www.ibm.com/support/pages/backup-and-restore-procedures 

0 comments
10 views

Permalink