sync prob with big files

[fuzzy_4711]

Thank you very much for your help.

I still get an error, even I changed the script according to your
suggestions. Thanks for that. This is what I got.

At the device to read from I have this file which should be synced to
the target:
-rwxrwxrwx 1 bacula pulse 128497545778 Nov  3 13:19 bkp-nas-0002

At the device where the file should have been written, I got this:
-rwxrwxrwx 1 bacula pulse 128497545778 Dec  9 01:28 cifs664f

I can confirm, that bkp-nas-0002 was the file which has been synced.

Notice the same target file size, so the sync must have been complete.
The file is just not renamed. Rsync must have failed in its last
seconds, I guess. But why? FYI I included more detailed configs.


> Also, capture any
> error that rsync outputs (this is actually easier without the -v).
Even rsync quits with exit code 1, no log entry in /var/log/messages for
rsync.

> 
> 2.  --devices and --specials are both included within -a

I changed that, the script is syncing like that now:
rsync -az --omit-dir-times --size-only --numeric-ids --delete
--bwlimit=$KILOBYTES_PER_SECOND $BACULA_BACKUP_DIR $MOUNT_DIR/$SYNC_DIR

And yes, all variables are expanded correctly, I could verify this in
the process list, while the task was running.

> 
> 3.  Can CIFS actually handle ACLs, XATTRs, devices, and specials?  In
> my very limited non-Windows guy experience it can't.  OTOH, if both
> source and target are CIFS then the source shouldn't have anything
> that the target can't handle.

Just to make sure, here is how both NAS-Devices are mounted:

Device, where to write to:
$MOUNT -t cifs -o soft,username=backup,password=xxxxxx,uid=107,gid=107
//192.168.1.8/Volume_1 $MOUNT_DIR

Device, where to read from (fstab)
//192.168.1.9/Volume_1 /nas01_backup    cifs
soft,username=backup,password=xxxxxx,uid=107,gid=107   0 0

> 4.  You probably shouldn't use --size-only on a regular basis.

In my last try I used it again, as you could see above, since I do have
2 successfully synced big files there, which would be destroyed again,
because their date changed (Bacula is appending to one file, since its
file size limit is reached). Based on the behaviour I found right now,
my guess is that this is not the prob.

Any further help would be highly appreciated.

-fuz