Steve,

Thanks for the clarification. It fits all the behavior I've seen during testing. I was hoping it was more rsync like. I would expect the destination could be protected fairly well. The group that is looking at this has a volume with ~28M inodes in use with sizable increases for one data set. I think trying to track the changes for all of these may get time consuming. It's a Windows share and I think they may use robocopy to sync things up.

Thanks again,

Jeff

On Fri, Nov 4, 2011 at 5:41 AM, Steve Losen scl@virginia.edu wrote:

...

Greetings,

I was experimenting with ndmpcopy and got an unexpected result.  I was wondering if anyone can clarify if this is correct behavior or not. I've tried it on both 7.3.3P5 and 8.1RC1.  I got slightly different error messages, but both failed.

I set up a source directory of foo and populated it with some data.  I ran the following command which worked:

ndmpcopy /vol/perf_test/foo /vol/perf_test/foo2

The part that broke was I deleted the zoneinfo directory from foo2, then ran the same command with the "-l 1" option.  I got the following error:

Ndmpcopy: easystreet: Log: RESTORE: Invalid operation: ./zoneinfo

I was expecting it to put zoneinfo back into the destination.  I started over again and used the "-d" option for the level 1 incremental.  The log file had no additional information.

Should an incremental put this directory back?

Thanks,

Jeff

Hi Jeff,

An incremental dump via ndmpcopy works like this:

Find all changes to the SOURCE folder since the base dump of this incremental dump (read the restore_symboltable file to accmplish this).  "Changes" would be any new files, modified files, renamed files, deleted files, etc.  Only the source folder is checked.  It is assumed that the destination folder has not been changed since the base dump. (In your email you say you changed the destination.)

Copy just the changed/new files to the destination folder, and delete anything from the destination that has been deleted from the source since the base dump.

If you need to change the destination and later bring it back into sync with the source, then you need rsync.

Steve Losen   scl@virginia.edu    phone: 434-924-0640

University of Virginia               ITC Unix Support