News and Reviews > Mini-Reviews by Members
Not-so-mini review of CrashPlan backup software
JavaJones:
Update on iDrive: All is not so rosy.
I have run into a couple of concerns and issues over the past week or two that I thought I should mention here.
First off I get notifications for updates to the client but trying to use the built-in update function never works. It downloads to 100%, then just sits there and never applies an update. This may be a security setting issue on my end. It's a minor but consistent annoyance. Downloading the application from their server manually and then just reinstalling it seems to work fine to update though.
Second - and perhaps most importantly - their system's support for deduplication seems to either be extremely minimal/simplistic or *non-existent*.
This is normally considered as much of a benefit to the host/service provider as to the user in that it can help them reduce data use on their end *if* it's done *between* people's accounts (i.e. if you have a large movie file downloaded and Joe Schmoe who also uses iDrive does, then they only need to store a single instance of the file on their server). This is an obvious privacy and security risk and it does not appear that iDrive does this (which is good for you, the user). For the user the main benefit is reduced bandwidth use if the file can be found to already exist on their server.
If deduplication is done *within a single user's account* it can still help with bandwidth, i.e. if you *move* files around on your system, it does not have to re-upload them. Unfortunately iDrive does not seem to handle this, or doesn't support it very well. What happened is I have 2 physical hard drives being backed up to the same location at iDrive (and locally). I had 150GB of photos on one drive when I did my original iDrive Express "seeded" backup that I sent to them. I later moved that 150GB of photos to the other drive, where all the other pictures live; it's a sort of archive, whereas the main drive is an SSD and a "working drive". So I do such file transfers semi-frequently. iDrive then had to *re-backup* all 150GB of photos (re-upload), even though they were the same exact photos and had simply been moved from one drive to another!
I consider this to be a pretty big drawback, at least for my usage patterns. I will seldom be moving such a large amount of data at once, usually it's more like 10-15GB, and that can re-upload fairly quickly. But it's still a needless inconvenience and evidence of an extremely simplistic - frankly naive - backup client. It is quite honestly not confidence inspiring, although I have no other specific reason to believe that their backup system is shoddy. It just seems like such a big, important, and obvious thing, one wonders what else they're overlooking...
It also may help explain why CrashPlan - which uses fairly sophisticated deduplication, block-level even, I believe - might be using so much more memory than iDrive. It seems reasonable to conclude that CrashPlan is just doing a lot more with the data locally, i.e. it also does compression, whereas iDrive seems to do so minimally if at all (the local backup size is roughly equivalent to the original data size on disk), or to only do it for remote backup and not local. I would really like to see both compression *and* deduplication and I consider both it to be an important features of any modern backup solution. The fact that iDrive appears to be missing both this (to some degree) is worrisome. They do claim to have compression and incremental backup on their features page, but I assume both are it is referring to remote backups, and apparently "incremental" doesn't cover my scenario of moved-but-not-modified files. [edit: I later found that compression *is* working]
Lastly, when I contacted support to discuss this issue they were not exactly impressively knowledgeable. The rep did eventually tell me several times that the data would have to be re-uploaded, but couldn't explain why and didn't seem to understand that this was a missing *feature* (and an important and relatively standard one). He did say he'd open a feature request for that, but had no information about whether such a request was common. Visiting their (surprisingly hard to find from their site) forums I don't see any other mention of it, which is surprising. Maybe my usage pattern is unusual.
Anyway, all that being said I'm still sticking with iDrive for a while, both because I have invested money in it, and because CrashPlan was not without its (significant) problems either. As I've mentioned, I have such a large amount of data that a "seeded" backup service is necessary, and the per-GB storage cost needs to be reasonably low. iDrive and CrashPlan are the only 2 services that seem affordable for my needs at present, but I'd love to hear about other options if anyone is aware of one that fits those specific needs.
Last but not least if you're still interested in iDrive after my concerns expressed above, and if you don't need 10TB of space like I do, this deal might be more of interest (I haven't tested it to see if it's still live):
https://www.idrive.com/idrive/deals/pd/backupreview
- Oshyan
4wd:
First off I get notifications for updates to the client but trying to use the built-in update function never works. It downloads to 100%, then just sits there and never applies an update. This may be a security setting issue on my end. It's a minor but consistent annoyance. Downloading the application from their server manually and then just reinstalling it seems to work fine to update though.-JavaJones (May 25, 2015, 02:34 PM)
--- End quote ---
FWIW, I think I've had 5-6 updates in the last two weeks or so and all of them have downloaded and installed OK. I've had to reallow some of the components through WFwAS but other than that the updates have worked.
Last but not least if you're still interested in iDrive after my concerns expressed above, and if you don't need 10TB of space like I do, this deal might be more of interest (I haven't tested it to see if it's still live):
https://www.idrive.com/idrive/deals/pd/backupreview
--- End quote ---
That's the deal I got but I didn't have to fill out a page to get it, just sign up for a free account and install the software. I got offered the deal after about a day by email.
JavaJones:
4wd, glad to hear the updates work for you. Must be some configuration issue on my end. I'll have to look into it.
- Oshyan
JavaJones:
Update 2 on iDrive: Another problem found.
The impression of iDrive being a feature-rich but fairly naively implemented application continues to solidify for me. The latest issue is that backups take a *really long time* (about 14 hours on an overclocked 4.2Ghz i7 2700k with 32GB of RAM). Now of course we're talking about 3TB of data, but these are incremental backups. The problem appears to be that iDrive is very bad at identifying what data has changed and so it basically scans through *all data in the backup set* and then updates anything new or changed that it finds. You can see in this screenshot of the log that it's actually only backing up a mere 47 changed files! But it still took 14hrs to do it because there are 1.3 million total files.
I'm fairly certain there are more effective approaches, such as using the NTFS file table to look for changed files, doing active file system monitoring (performance considerations?), etc. And of course the tremendous length of time is due largely to the sheer size and number of files in my backup. Still though, I don't think this should be considered normal and expected behavior, right? If I recall correctly from my time with CrashPlan, this kind of thing was not really a problem. But this may go into the pile of evidence suggesting that CrashPlan's high memory use had a bit more reason to it than I'd expected, i.e. if it's doing more work in monitoring the file system for changes, deduplication, etc. than iDrive is. It's still an open question whether the memory trade-off is worth it for those features...
I should note that there is a separate "continuous data protection" option that may help with my particular needs, but it's a bit of a workaround. Here's their page on the feature (emphasis mine):
https://www.idrive.com/help/Mac/continuous_data_protection
The Continuous Data Protection feature allows IDrive to automatically recognize the changes to files present in your backup-set and back them up in real-time...
--- End quote ---
What's odd is that this indicates the technology I'm talking about *does* exist in iDrive, it's just not used for the main backup. So why not just use this Continuous Data Protection *instead* of the main backup? Well, the big limitation is it does not consider or backup files larger than 500MB. As their FAQ indicates:
CDP is not a replacement for the traditional schedule backup feature but works along with the scheduled backup to provide timely protection for your data.
--- End quote ---
Now thinking about my particular backup needs, dealing with files greater than 500MB in size is fortunately not actually that common. So my current thinking is I will enable this CDP feature and see how well it works, and lower the frequency of the full backups to once or twice a week instead of daily as I have it now. If I'm right about not dealing with large files that much, then this should give me a good level of protection through the week, and then reserve the once-weekly full backup to basically just catch any missed big file changes. It will still take a long time, but at least it will only be once a week. The one big exception is my Lightroom catalog, which is currently around 1.6GB in size. This is a pretty important one for me, so I need to think about how much this puts me at risk... I'm also not sure whether this CDP option works for both online and local backup.
Does anyone else deal with big quantities of data?
I think once I've worked out all the kinks and addressed all my own questions I'll try to write a separate "mini" review of iDrive to distill these experiences down into something more immediately useful and accessible.
- Oshyan
f0dder:
So clearly CrashPlan is doing something wrong, wrong, wrong.-JavaJones (May 17, 2015, 07:46 PM)
--- End quote ---
Java? :-)
I'm fairly certain there are more effective approaches, such as using the NTFS file table to look for changed files, doing active file system monitoring (performance considerations?)
-JavaJones (May 27, 2015, 02:30 PM)
--- End quote ---
If I were to design a backup solution, I'd definitely use a combination of USN Journal scanning, if available, on program start-up, combined with filesystem notification events.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version