sync prob with big files

Kevin Korb kmk at sanitarium.net
Fri Dec 9 06:30:18 MST 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/09/11 05:23, fuzzy_4711 wrote:
> 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.
> 

What is renaming the file?  Your rsync command line implies that you
are syncing directories.  That means the file names should be the
same.  That is not the format of rsync's temporary file names.

> 
>> 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.

Rsync would not log there.  Any errors would simply output via stdout.
 IOW, to the terminal where you ran the rsync.  If it is running from
cron then any output should be emailed to the owner of the cron job.

> 
>> 
>> 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

- -- 
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
	Kevin Korb			Phone:    (407) 252-6853
	Systems Administrator		Internet:
	FutureQuest, Inc.		Kevin at FutureQuest.net  (work)
	Orlando, Florida		kmk at sanitarium.net (personal)
	Web page:			http://www.sanitarium.net/
	PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7iDWoACgkQVKC1jlbQAQfQogCffqUWxe+GGk0EPlv5NMoe8qH3
txwAn3cCW5AMIkpu2w3ejDhe7xw9cSvs
=jhpF
-----END PGP SIGNATURE-----


More information about the rsync mailing list