NDSRC - A Cross-Platform eDirectory/NICI Backup Tool

0 Likes
over 9 years ago

Labels:

Collateral
New Release-Feature
How To-Best Practice
Comment List
Anonymous
  • Cause ndsrc method worked for me for backing up edirectory on RHEL 5.8 and restoring it on SLES 11 SP 3 and dsbk backup restore does not work as errors like Loader Failed:for /dxevent, error are thrown. Also the edirectory instance is not listening on the ports any more after restarting ndsd after the dsbk restore.

    Thanks for the perl script. It saved me a lot of headache.
  • Thanks for the feedback. I'm glad to hear it worked for you, and if you have any other thoughts on it let me know. The current version should work with eDirectory 9.0 once it is out, too, at least based on beta testing.
  • Good question. I'd definitely recommend using dsbk for anything requiring support, and for any situation where it is likely that you'll actually be bringing a single server back into a tree with many other replicas-holders. The reason is that dsbk is the ONLY way to properly do this, assuming you do it properly (which is a big assumption), and properly merge in a server such that its copy of data is consistent with all other servers in the tree. If, for example, you do not handle your Roll-Forward Log (RFL) files correctly, restoring with dsbk may not work fully. Back when dsbk was just embox this also required Role Based Services (RBS) to be properly setup in iManager, which was quite painful. There were also bugs with dsbk for a long time which, while not complaining about problems, failed to backup NICI, so restores without NICI were missing things that were encrypted with NICI. It's all fixed now, but ndsrc.pl is older than those kinds of issues.

    The ndsrc.pl script is meant to just grab the DIB and NICI with as few assumptions as possible; the one notable exception to that assumptions rule is: "You know how to restore it and the risks in doing so if there are other servers in the to-be-restored tree." No need for RFL configuration, having any kind of access to any working eDirectory commands, or much of anything. Just grab the DIB, exactly as it is, maintaining directory structures everywhere, so have a perfect DIB backup for whenever you need it. i.e. be very much like 'dsrepair -rc' on NetWare.
  • Just curious...Why would one use ndsrc when there is dsbk (TID 3295479)?

    SAMPLE BACKUP SCRIPT:
    #! /bin/sh
    # Clean up old backups...
    find /root/backup-edir/cron -type f -ctime +15 -exec rm {} \;
    PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/opt/novell/eDirectory/bin:
    dsbk backup -b -f $BACKUPFOLDER/edirbak-`date +%Y-%m-%d`.bak -l $BACKUPFOLDER/edirbk-`date +%Y-%m-%d`.log -t -w

    sample REPORTING SCRIPT:
    #!/bin/sh
    # Email admin edir backup reports
    # Allow enough time for the edir backup to finish processing.
    echo "" >> /root/backup-edir/cron/edirbak-`date +%Y-%m-%d`.log
    ls -lh /root/backup-edir/cron >> /root/backup-edir/cron/edirbak-`date +%Y-%m-%d`.log
    mail -s NDS BACKUP REPORT -a /root/backup-edir/cron/edirbak-`date +%Y-%m-%d`.log itadmin@mycompany.com </dev/null
  • A customer noted that extracting the ndsrc-generated archive threw a nastygram when they used tar to extract as shown below:

    # tar -xvf test-12\:34\:56.tar
    test-12: Unknown host
    tar: test-12\:34\:56.tar: Cannot open: Input/output error
    tar: Error is not recoverable: exiting now
    2011-09-12 09:59:00 Jobs:0 Err:2

    The tar command has become smart over time and now appears to know how to chat on the network; as a result if it does not know you are explicitly pointing to a file and it sees a colon (:) in the file name it tries to find something on the network. The default filename created by ndsrc.pl includes colons to show the time of the backup taken for both eDir and NICI and so if you try to use tar as shown above to extract the archive it will fail (for versions of tar that understand colons may be delimiters for hosts). The workaround for this is to just add a dot-slash before the file:

    # tar -xvf ./test-12\:34\:56.tar

    This tells 'tar' that this is a file where you are.... an absolute path should work as well of course... and therefore tar doesn't try to do anything network-related.
Related Discussions
Recommended