



I have other backup software that scan the exact same folders and finish in less than 30 seconds. My hard drives are reasonably fast, so even with a quarter million files it doesn't take long to scan the filesystem. In any case, thanks for your interest in SpiderOak. SpiderOak does some optimizations with directory hashing to avoid having to open the journal to scan for specific changes in unchanged folders, but there are some situations where that optimization is defeated (such as if you remount a file system with changed gids, inode IDs, timestamps, etc.)Īnyway, once it's running, it uses the operating system facilities on Linux/Mac/Windows to notice changes automatically so rescanning the whole backup selection after startup is not usually necessary. In a profile, basically none of this CPU time is spent in the crypto module, just mostly for unserializing the per-folder journal to compare state. (SpiderOak works with any folders you like, including externa/network drives, not just one folder like Dropbox.) įYI, when SpiderOak first starts running, like any backup software, it has to scan your filesystem to see what may have changed while it was shutdown, and that can take a lot of IO and CPU if you have many folders and/or many small files (hundreds of thousands). It's not really about the encryption directly it's about the way the database design has to change to support zero knowledge (the server can no longer do the database work.) Things like garbage collection have to happen client side. By the same metric, none of Dropbox's commercial competitors (perhaps with the exception of Google Drive, which I don't use) are even close to convenient. pptx to be there as soon as I wake my laptop. pptx file in my Dropbox on my desktop PC, take my laptop to the conference room, and expect the. When I need to do a presentation, I can just work on the. It's just bad app design, bad protocol design, and perhaps overloaded servers.ĭropbox, on the other hand, immediately begins to upload/download my files, and once it's done scanning any large folders, its speed is only limited by the bandwidth of my Internet connection. In any case, encryption isn't making it slow. Maybe it does sleep(random()) between each upload. It just sits idle for half an hour or more, scarcely utilizing any network resources. At one point I had over 100GB stored in there, and it was a PITA to sync any files at all.)Īs an interesting comparison, Microsoft SkyDrive performs just as terribly as SpiderOak does when you give it a few hundred folders with ~100K files to sync, despite the fact that it does no client-side encryption. (I have over 50GB of data in my SpiderOak account, made up of a quarter million files. Wuala is no better in my experience, although YMMV depending on your use case and filesystem structure. I understand that the protocol needs to be different if all the encryption is done by the client, but this is just ridiculous. It's very annoying when I just want to see a few files that I know I changed in another machine. Nothing gets synched during this time, and the client sometimes consumes a whole CPU core for extended periods. That's how long it takes for the client to find out what files I changed in my other machines in the meantime, including all the files that have nothing to do with this particular machine. I agree with you and suspect that it has more to do with crappy architecture.Īnecdote: SpiderOak takes 5 minutes synchronizing metadata with the server if I start it on a laptop that I only use occasionally. Encryption shouldn't have any noticeable impact on sync speed, since modern CPUs can encrypt a file a hundred times over in the time it takes to upload/download it. I have absolutely no intention to spread FUD about client-side encryption, and in fact I don't think Dropbox's speed advantage has anything to do with (lack of) encryption.
