Large Update filesizes

Started by tantalus, November 16, 2010, 02:45:51 PM

Previous topic - Next topic

tantalus

Hello,

I've recently purchased Espionage and I am quite happy with the program. Yet, I have some troubles (I think) with the built-in backup functionality. Everytime a backup is performed there is way more traffic than expected. Info: I am backing up to a Jungledisk share, which is accessed just like a mapped network drive.
Problem description:
I unlock a folder and change a file, size 0,5MB. Upon locking the folder, the backup procedure is triggered and the changes are sent to the mapped jungledisk drive. However, instead of 0,5MB or 8MB (the sparsebundle size) the Jungledisk monitor shows 117MB(!) being transferred.

Could you please help me resolve this issue?

Christian

greg

#1
Hi Christian,

We haven't tested Espionage with JungleDisk and can't make any guarantees about its compatibility with it, however, there is one suggestion that I can make, and that's to change the options that 'rsync' uses when doing the backup. Try the suggestion mentioned in this post for doing that. Whether it will help I'm not sure, but it's worth a try.

Kind regards,
Greg, Tao Effect
Follow @espionageapp@twitter.com or @espionage@mstdn.io for news and updates!

tantalus

#2
Hi Greg,

thank you for your assistance. I tried the tipps you suggested (entering the piece of code in terminal), yet the problem persists.
It might have something to do with the way Jungledisk treats uploads to amazon S3 (Jungledisk is a amazon S3 client). It seems to be unable to upload only those parts wich have been changed.... However, you can modify the jungledisk subscription to improve the upload mechanism (uploading only the parts of a file which have changed). I modified my subscription and am now testing how it works. I will tell you how it turns out.

Cheers,
Christian

tantalus

#3
I've done some testing and experimenting. Besides Jungledisk I tried other cloud storage solutions, such as Zumodrive, because Jungledsik still gave me troubles. Zumodrive is somewhat similiar to Dropbox, but has the advantage of selecting the folders you want to backup to the cloud. I then pointed the built-in backup feature of Espionage to the mapped Zumodrive - very convenient. When the automatic backup is initiated, the data is cached by the Zumodrive software and the data is then uploaded to the cloud. I noticed the following. If I encrypt a folder with 1,2MB content. The data uploaded to the cloud is approx. 109MB. How can this be, with a folder being only 1,2MB large?
If the backup has completed and I unlock the folder, change nothing and lock it again, there is again approx. 100MB transferred.
Could you please help me with this?

Christian

greg

#4
Quote from: "tantalus"f I encrypt a folder with 1,2MB content. The data uploaded to the cloud is approx. 109MB. How can this be, with a folder being only 1,2MB large?

Encrypted folders have an overhead. You'll have the same or similar overhead with any other software that uses Apple's encrypted disk images.

QuoteIf the backup has completed and I unlock the folder, change nothing and lock it again, there is again approx. 100MB transferred.
Could you please help me with this?

If you have encrypted a folder as a sparsebundle (not a sparseimage), and you have Espionage's backups pointed into a folder that's in turn backed up by Zumodrive, then the only reason it would backup the entire thing is if it's not very bright.  ;)

A sparsebundle is composed of 8MB encrypted "bands". Espionage's backups only send the changed bands for a sparsebundle, not the entire thing.

If your Zumodrive settings are set to back up the folder directly (not its backup inside the EspionageBackups folder), then this can happen because Espionage moves around the hidden disk image, and Zumodrive might see this as a folder being deleted and re-created. However, if Zumodrive is backing up the EspionageBackups folder (and not the original encrypted folders), then it should technically be able to figure out what files changed, and only upload those. If it doesn't do this then you should contact their developers to ask them why it's behaving this way.

Hope that helps!

Kind regards,
Greg, Tao Effect
Follow @espionageapp@twitter.com or @espionage@mstdn.io for news and updates!

tantalus

#5
Ok, I understand now that the overhead is intrinsic and is no "problem" of Espionage. Thanks for the clarification.

The past days I tested ZumoDrive, SugarSync and Dropbox. It seems that only Dropbox is working properly with Espionage. Here is the test "scenario": I created a test folder with a test file ("Hello world"), encrypted  and uploaded it to the three services. I then unlocked the folder and changed the text file ("Hello World" --> "Hello Planet"). Afterwards I tested how long each of the three services needed to upload the changes from the Espionage's built-in backup feature. Note: I have a low bandwith, everything takes quite a while here...

Dropbox only needed a minute or so.
Zumodrive and Sugarsync needed over an hour...

My conclusion: There are cloud storage solutions which can't' just upload only the changed parts of a file or folder. They always upload everything all over again, which renders them unusable with Espionage. The only service I found which worked nicely was Dropbox. They also explain this behavior in their help section (https://www.dropbox.com/help/8). I guess Dropbox suits my requirements the most.

Christian

ming21

#6
Both SygarSync and Dropbox sync only the changed data after the original has been uploaded. This saves time as it doesn't need to re-upload all the data each time it changes. Regarding speed, my experience is that they are very close as to not be a issue.

I use both and they are different, but both work well. I prefer SugarSyncing for syncing documents as it is easier and has far more features. When using Sugar Sync with espionage, you need to select "Don't save any folders" in the Advanced Preferences Menu. This avoids an error Espionage generates because sometimes SugarSync begins to sync before Espionage releases the folder and Espionage thinks it has encountered an unassociated file so it saves it to be safe. I think this is what happens, I'm not the software engineer so I don't know for certain. In any case, I have never lost data by doing this. And, if you are maintaining a backup, even if you lost data while syncing, I still have the uncompromised backup.

I prefer Dropbox for backups as I can use the Dropbox as the destination for the Espionage backups and they are then synced offsite securely if all goes to hell with my computer(s).

Both services are reliable, unlike Zumo, which I stopped using because of the resource drain on my computers and the unreliability of it. It was by far the slowest of the services. BTW SugarSync now provides 5GB of storage free compared to Dropbox's 2GB. Hope this helps.