Roll-forward logging is similar to journaling on other database products. The roll-forward logs (RFLs) are a record of all changes to the database.
The advantage of using roll-forward logging is that the roll-forward logs give you a history of changes since the last full or incremental backup, so you can restore eDirectory to the state it was in at the moment before a failure. Without roll-forward logs, you can restore eDirectory only to the point of the last full or incremental backup.
eDirectory creates a record of transactions in a log file before committing them to the database. By default, the log file for these records is reused over and over (consuming only a small amount of disk space), and the history of changes to the eDirectory database is not being saved.
When you turn on continuous roll-forward logging, the history of changes is saved in a set of consecutive roll-forward log files. Roll-forward logging does not reduce server performance; it simply saves the log file entries that eDirectory is already creating.
You must turn on roll-forward logging for servers that participate in a replica ring. If you don't, when you try to restore from your backup files you will get errors and the database will not open. The restore by default won't open a database that shares replicas with other servers unless it is restored back to the state it was in at the moment before it went down. (If you don't have roll-forward logs, you must follow a separate procedure to try to recover, described in Recovering the Database If Restore Verification Fails.)
Roll-forward logging is off by default. You must turn it on if you want to use it on a server. Roll-forward logging is also turned off and the settings returned to default when you restore a server, so after a restore you must turn it on again, re-create your configuration, and create a new full backup. (The new full backup is necessary so that you are prepared for any failures that might occur before the next unattended full backup is scheduled to take place.)
In a single-server environment, roll-forward logging is not required, but you can use it if you want to be able to restore eDirectory to the moment before it went down instead of just to the last backup.
Make sure you monitor disk space when roll-forward logging is on. For more information, see Backing Up and Removing Roll-Forward Logs.
In this section:
You can turn on and configure roll-forward logging using either iManager or the eMBox Client. See Configuring Roll-Forward Logs with iManager or Configuring Roll-Forward Logs with the eMBox Client.
If you decide to use continuous roll-forward logging, you must be aware of the following issues:
Turn on roll-forward logging before a backup is done if you want to be able to use this feature for restoring the database.
For fault tolerance, make sure that the roll-forward logs are placed on a different storage device than eDirectory. For security, you should also restrict user rights to the logs. For more information, see Location of the Roll-Forward Logs.
Document the location of the roll-forward logs. For more information, see Location of the Roll-Forward Logs.
Monitor the available disk space where the logs are located. For more information, see Backing Up and Removing Roll-Forward Logs.
If the logs are turned off or lost, turn them back on, then do a new full backup to ensure that you can make a full recovery. This is necessary in these cases:
If you turn on logging of stream files, the roll-forward logs use up disk space more quickly. When logging of stream files (such as login scripts) is turned on, the whole stream file is copied into the roll-forward log every time there is a change. You can slow the growth of the log files by turning off roll-forward logging of stream files and, instead, back them up only when you do an incremental or full backup.
The slowest part of restoring the database is replaying the roll-forward logs. Roll-forward logs grow larger based on how many changes are made to the tree structure and whether stream files (such as login scripts) are being logged.
If your database changes often, you might need to consider more frequent eDirectory backups so that fewer changes need to be replayed from roll-forward logs during a restore.
Don't change the name of a roll-forward log file. If the filename is different than when the log was created, the log file can't be used in a restore.
Keep in mind that removing eDirectory also removes all the roll-forward logs. If you want to be able to use the logs for restoring in the future, before removing eDirectory you must first copy the roll-forward logs to another location.
If a restore is necessary, make sure you re-create the roll-forward logs configuration on the server after the restore is complete to make sure they are turned on and are placed in a fault-tolerant location. After turning on the roll-forward logs, you must also do a new full backup.
This step is necessary because during a restore, the configuration for roll-forward logging is set back to the default, which means that roll-forward logging is turned off and the location is set back to the default. The new full backup is necessary so that you are prepared for any failures that might occur before the next unattended full backup is scheduled to take place.
If you turn on roll-forward logging, you should change the location of the roll-forward log directory to a different storage device than eDirectory.
Here are the important issues to consider when choosing the location:
Don't leave them in the default location---make sure you put them on a different storage device than eDirectory. This way, if eDirectory is lost because of a storage device failure, you can still access the roll-forward logs to restore eDirectory.
For example, on NetWare the default location is sys:_netware\nds.rfl\. However, if you turn on roll-forward logging, you should not use the default location. The logs should not be placed on volume sys: because that is the same volume where the eDirectory database is located.
If you only have one storage device on your server, the roll-forward logs can't provide fault tolerance for eDirectory in case of a storage device failure. In this case, you probably should not use the roll-forward logs.
You can change the location of the roll-forward logs using Backup Configuration in iManager or setconfig in the eMBox Client. The roll-forward logs directory must be local to the server.
Document the location. Document where the roll-forward logs are placed so that you can find them when you need to restore the database on a server. It's important to do this while the server is healthy, before any failures happen.
To find out the location when the server is healthy, you can look it up in iManager in Backup Configuration, or in the eMBox Client using the backup getconfig option. But if the server has a failure that affects eDirectory (such as hardware failure), you won't be able to look up the location of the roll-forward logs.
If the server has already had a failure and you are trying to restore it, keep in mind that any new installations of eDirectory will show the default location of the roll-forward logs. So, if you have just reinstalled eDirectory as the first step of a restore process, eDirectory will not show the correct location of the roll-forward logs on the server before it went down. You will need to refer to your documentation to find out where they are.
The settings for the roll-forward logs are also recorded in the _ndsdb.ini file, but that file is on the same disk partition/volume as eDirectory, so if you were to lose the storage device where eDirectory was located, you couldn't use the _ndsdb.ini file to look up the location.
Restrict rights to where the roll-forward logs are located. This is a security issue. The information is not easily readable, but the logs could be decoded to reveal sensitive data.
Monitor the amount of free disk space to make sure there is enough. See Backing Up and Removing Roll-Forward Logs.
A good strategy is to set up a disk partition/volume solely for the roll-forward logs. This way, disk space and security privileges can be easily monitored.
The last directory in the path is created by eDirectory. It is based on the name of the current eDirectory database.
For example, if the location you specified was d:\Novell\NDS\DIBFiles and your eDirectory database was currently named NDS, the location of the roll-forward logs would be d:\Novell\NDS\DIBFiles\nds.rfl. If you renamed the database from NDS to ND1, the roll-forward log directory would be changed to d:\Novell\NDS\DIBFiles\nd1.rfl.
When you change the location, the new directory is created immediately, but a roll-forward log is not created there until a transaction takes place in the database.
When restoring, all the necessary roll-forward logs must be in the same directory. For more information, see Preparing for a Restore.
If left unchecked, roll-forward logs can fill up the disk partition/volume where they are placed. If roll-forward logs cannot be created because no more disk space is available, eDirectory stops responding on that server. We recommend that you periodically back up the log files and remove unused logs from the server to free up disk space.
To identify, back up, and remove roll-forward logs that are safe to remove:
Make a note of the name of the last unused roll-forward log.
You can find out the name of the last unused roll-forward log in the following ways:
The last unused roll-forward log is the most recent roll-forward log that the database has completed and is no longer using to record transactions. It's called the last unused roll-forward log because the database has finished writing to it and has begun a new log file, so it does not need to have this one open any more. (The current roll-forward log in which the database is recording transactions is in use and is still needed by the database.)
Do a file system backup of the roll-forward logs, to put them all safely on tape.
Remove the roll-forward logs that are older than the last unused roll-forward log.
WARNING: Keep in mind that you must be cautious when removing roll-forward logs from the server. Compare carefully with your tape backup to make sure you have a backup copy of everything you delete.
The last unused roll-forward log indicates which file the database has just completed and closed. It does not indicate whether it's safe to remove that file from the server. You must make sure that you remove only files that you have a tape backup for.
If you need to retrieve any of the roll-forward logs from tape for use in a restore because you have placed some of them on tape backup, keep in mind the following issues:
If you remove eDirectory from your server, the roll-forward log directory and all the logs in it are also removed. If you want to be able to use the logs for restoring the server in the future, before removing eDirectory you must first copy the roll-forward logs to another location.