But... but... but... it's different from what I'm used to, so it can't be any good!

I have five different CrashPlan archives on three different hard drives. Are you saying that the de-duplicating that CrashPlan does in any archive is independent of the other four archives, even though each archive has exactly the same filename, i.e., 791869747154424520? I guess that must be the case, otherwise my "M:\Disk 01" archive would be essentially empty as it contains an exact copy of my "E:\Disk 1" archive which is an exact copy of my D:\ disk drive. If it were de-duplicated based on what had been backed up to the E: archive, the M: archive wouldn't have anything in it because the entire M: archive is a duplicate of the E: archive.

It is curious that the M: archive is 56GB smaller than the E: archive, so there must have been some de-duplicating going on there.

Given the likely premise that you guys and the millions of other people happily using CrashPlan know more about this than I do, I'll hang in there with CrashPlan, as it does appear that I do indeed have multiple copies of my data saved so if something happens to one of the archives, I have the data in another one. Along with the original data, of course. At least no-one can accuse me of not being serious about backing up my data!

tanstaafl.

You're making my head spin.

Here is what I know: in the 3-step setup I described in my previous post, if step 3 involved choosing two locations, then yes, I would have a full backup set in both locations. If my local drive had failed, I could get all the exact same data from the cloud.

I've sort of lost the thread on how your system has been set up. Sorry about that...

It only deduplicates *within* a backup archive. If you backup the same file to more than one destination you'll have the file in both destinations independent of one another. Each backup destination is a complete independent backup which is the point. If one backup destination depended on another having two would be somewhat useless.

Deduplication mainly is useful for slow bandwidth connections. If you have multiple copies of one file in different folders, it only sends it once. It works locally and only keeps the one copy though. If one of the files changes then it stores new copy in the backup and the old one stays for both locations as it's part of the history. If only part of a big file changes, it only sends the changed bit.

The big number is the GUID of the machine. Every install or machine has a unique number to identify it. So yes the base filename on each of your destinations will be the same.

Stop trying to understand the files, do you backups and do spot checks using the Restore tab to see what you have. Disconnect backup destinations to simulate lost drives.

You lost me with M:\ and E:\ but in theory they should be the same size if they are the same source data. Note that as soon as one destination misses a backup e.g. you unplug for offsite, the size will change of course as one will grow without the other. If you plug it back in it should catch up but will have missed any intermediate changes of course.

O.K., that makes sense. I am starting to understand this now.

I didn't describe very well what I am doing with E:\ and M:\. It is not as complicated as I made it sound.

My files are on my C:\ and my D:\ drives. I back up the C:\ data to a directory (Disk 1) on the E:\ drive; I back up the D:\ data to a second directory on the E:\ Drive (Disk 2).

Then I repeat the process, backing up to Drive M:\. This suggests to me that E:\ and M:\ should be more or less identical. They aren't. I'll keep an eye on them, examine them with the Restore module, and see if I can find out why. Maybe it's something simple like I didn't turn off compression on the M:\ drive or something.

Thank you, Christian, for the clarification. You are pretty good at that!

tanstaafl.

You might be slowing your backups down by turning compression off. CPUs are extremely fast at compressing stuff now and drives are still faster when they have less data to write...

Though if course if your drives are full, with say scans of medical bills, that might not be the case

In my case, probably not. The great majority of the data I am backing up is already compressed: photos, audio, compiled program files and the like.

Compressing those files frequently results in files that are larger than the originals, although not by much. Well, sometimes maybe not, a quick test on four music files totaling 87MB(Beethoven Ninth) showed a compressed file that was about eight tenths of one percent smaller than the original, but it took about 15 seconds for the 7-Zip program to process the file.

Since I am not backing up to the Cloud, file size, storage required, and speed are not concerns. The backup program just ticks away quietly in the background with no noticeable impact on performance, and now I feel better knowing that even if something happens to one of my backup archives, I sill have another copy of it immediately accessible to me.

One reason Cloud backup is not realistic for me is that even in the unlikely event of optimal conditions, assuming I had already put in the several months of 24-hour a day uploading it would require to put my data into the Cloud, in the event of catastrophic failure it would take almost three weeks of continuous downloading to get it back. I wonder whether a lot of people who think they are perfectly safe with a Cloud backup have taken that into account? Although I guess that just getting the critical data back wouldn't take so long, and the pictures and music etc. could come later.

As for medical bills, my life is an open book. If someone wants to know that I had outpatient surgery on my arm to address a calcified tendon, well, you heard it here first I guess. The only people who might be interested in my medical records is my health insurance company, and they already have them.

tanstaafl.

Some cloud backup services will/can FedEx your entire backup to you on a new hard drive. So recovery can be via overnight courier.

Same for sending the original 'seed' backup to them. You create a backup set, courier the hard drive, then increment backups from there via the cloud.

The big win with cloud backup is that the saved data is physically far removed from your locale and within the cloud service is also redundantly protected. And the continuous incremental cloud backup process means the data exposed to actual loss is only the most recent few minutes or hours worth.

It's sad that, in this day and age, Truck Bandwidth is still faster. Sad but true.

And of course, Randall tackles that question quite adequately...

https://what-if.xkcd.com/31/

I was just going to use that station wagon hurtling down a highway quote. Foiled by xkcd.

What If is genius. The book has some fun additional entries as well.

My 6 & 9 year old both enjoy Randall's What If? and Thing Explainer books. Sure, a chunk of it is over their heads (and mine!) but the writing style is humors and ridiculous.

FWIW, "What If" is currently available on Amazon as an Amazon Prime free book. I just downloaded it.

tanstaafl.