title: Backing up and restoring Sun DS using command line tools link: https://onemoretech.wordpress.com/2008/01/22/backing-up-and-restoring-sun-ds-using-command-line-tools/ author: lembobro description: post_id: 576 created: 2008/01/22 16:27:56 created_gmt: 2008/01/22 16:27:56 comment_status: open post_name: backing-up-and-restoring-sun-ds-using-command-line-tools status: publish post_type: post

Backing up and restoring Sun DS using command line tools

I’m just going to do a document dump here, because it’s always nice to have really clear instructions somewhere when bad stuff happens. The following is taken from my own administrator’s notes.

These procedures have been used successfully on Sun Directory 5.1 SP4 servers. Syntax may (probably will) differ in other versions of Sun directory server, and in other Netscape family directories (e.g. Fedora Directory Server). Check the command reference for your specific version.

Before you read on, a couple of conventions. When I install a directory server I break the environment up into an administration directory and a user directory at a minimum. This way if the user directory goes flaky I can still use the gui directory console to do things like create a new directory instance. I usually designate the first master on a physical server “M1”, the second “M2”, and so on. Replicas get the label “R1”, “R2”, etc. The physical host name is included in the instance name as well. So a typical instance will be called “slapd-hostname-M1”, for example.

Intro

Directory environment backups are usually done in 3 separate ways.

• Traditional tape archive
• Sun Directory binary backup
• LDIF dump

This note will explain how to use the command line tools provided by Sun to restore a directory database using the last two methods.

Restoring from Binary Backup

A binary backup of the directory database is typically done using the db2bak utility found in the directory instance root (e.g. /u01/app/iplanet/directory5.1/ slapd-hostname-M1). When executed without any arguments, the command line tool will create the backup files in a folder called bak under the instance root (e.g. /u01/app/iplanet/directory5.1/slapd-hostname-M1/bak).

All production directories run db2bak for each instance as a cron job.

In order to restore the database from this backup, the bak2db tool is used. This utility (really a shell script) is also found in the instance root. To run this change to the instance root folder and execute:

./db2bak

Before running the restore tool, the directory instance must be completely shut down using the stop-slapd script for that instance (also found in the instance root). The syntax for the command is:

bak2db -n [backup folder name]

For practical purposes, to restore the user directory on the production master you would issue a command like this from the M1 instance root (slapd-hostname-M1):

./bak2db bak/2005_06_07_16_42_17

Note that the path is to a folder under the bak folder, not a file. Each folder is named for the time the backup was made.

Once the database is restored, use the start-slapd script to restart the directory instance.

Restoring from LDIF Backup

LDIF backup of directory instances are generally done using the db2ldif tool, found in the directory instance root. The syntax is for this command is:

db2ldif -n [database name]

Since we’ve standardized on “userRoot” as the standard name for user databased, backing up the user db on hostname-M1 would be done using this command:

./db2ldif -n userRoot

The completed backup is stored as a plain text file in a folder called “ldif” under the instance root. These files are named for the time the backup was done.

To restore from such a backup, the ldif2db tool can be used. Before beginning, the directory instance must be completely stopped using stop-slapd. The syntax for the restore command is:

./ldif2db -n [database name] -i [full-path-to-backup-file]

For some strange reason Netcape, Sun, and even Red Hat, have failed to make clear that the full path of the input file is required by this tool (perhaps because they’re embarrassed that the full path is required).

So, to restore the master user database in production you would issue (note I am going to cheat here, using the environment variable “$DSHOME” for the server root path “/u01/app/iplanet/directory5.1”):

./ldif2db -n userRoot -i $DSHOME/slapd-hostname -M1/ ldif/2005_06_07_16435.ldif

It is important to note that while a binary restore of the database will recover indexing done to the database, an LDIF restore will not. After an LDIF restore indexes will need to be recreated.

After doing an LDIF restore make sure to start the directory instance using start-slapd.

Copyright 2004-2019 Phil Lembo