On 01/12/14 06:45, Christian Völker wrote:
> Am 30.11.2014 um 19:43 schrieb Timothy J Massey:
>> Or it might be something else completely.
>>
> I guess it is something completely different. According to the man page
> the timeout values is related to I/O. For this I set it to 60.000 and
> meanwhile to 6,000. It does not even take 2 minutes (120 seconds) until
> it ends. I did not use a stop watch but it is all in all below 14 seconds!
>
> See following log:
> #Here command is executed as user backuppc
>> time ./BackupPC_dump -f -v esxi.evs-nb.de ; time
> Sending csums for mssql-flat.vmdk (size=42949672960)
> #The vmdk is generated as thin (sparse file!), but the max size is
> around 40GB.
> Read EOF:
> #Why end of file? Related to thin/ sparse?The "--sparse" parameter on
> rsync did not help. I migrated the disk to thick (=non-sparse) with the
> same result. Not related to sparse...
> Tried again: got 0 bytes
> Child is sending done
> Got done from child
> #Why TF do you think you are done?
> Got stats: 0 0 0 0 ('errorCnt' => 0,'ExistFileSize' => 0,'ExistFileCnt'
> => 0,'TotalFileCnt' => 0,'ExistFileCompSize' => 0,'TotalFileSize' => 0)
> #Even with no errors reported!
> Child is aborting
> Got exit from child
> Can't write 33792 bytes to socket
>
Given the size of the file seems to be part of the issue, along with the
remote end being the one to close the connection unexpectedly, can you try:
a) Use rsync (outside of backuppc) to transfer the file, preferably
using protocol 28.
b) Check the logs on the client side, and enable debugging as needed, to
find out if there is any issue.
Personally, I think you are somewhat crazy trying to do this for a few
reasons:
1) You know the file content will change every day
2) It will therefore consume the total (compressed if you enable
compression) size on the backuppc server for every full/incremental you keep
3) There is little to no benefit in storing a disk image in backuppc
However, I regularly do the following with large files that need to
backed up, such as database dumps (backups), or disk images:
1) in a pre-backup, I shutdown the VM
2) split the disk image into a series of small files (between 10MB and
100MB each)
3) start the VM
4) allow backuppc to backup the chunks
a) rsync is much quicker at completing the backup, because content of
most chunks does not change
b) rsync will transfer less data (not exactly sure why, but it works
that way in my tests)
c) backuppc will not require as much disk space to store the backups
because most of the chunks will never change their content
Of course, this will cost you double the storage space on the remote
end, but the advantage with that is you also have the latest backup
stored locally, which 99% of the time is the one you will want to
restore back to, so no need to wait for the disk image to transfer over
the network.
Hope something in all that will help you.
Regards,
Adam
--
Adam Goryachev Website Managers www.websitemanagers.com.au
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
