• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Offsite backup?

W

Worminater

Gawd
Joined
Apr 12, 2004
Messages
1,017
What do people here use? My current setup being small stuff sync'd across my computers via dropbox; large file storage on nas (~3tb currently); and my photo repo stored on local SSD and backed up to NAS (~100gb currently).

Specifically; I'm thinking about the photos/videos i've taken being backed offsite. Anyone have a favorite service/recommendation?
 
I use Crashplan....no complaints so far but I haven't had to do any kind of large scale restore (knock on wood). I run the client on WHS 2011 and currently backup near 1 TB.
 
I've heard good things about Crashplan and use Backblaze for myself. I ended up with Backblaze because I was able to get better speeds to their servers and I had a few TB's to be uploaded. I usually get 20-25mbps up, but I've seen it as high as 54mbps.
 
I've taken a new approach and am buying the cheapest disks possible, and using simple programs (syncback or rsync) to back up my data in three different places.

Had pretty good luck so far, but not had to deal with anything more than a single disk failure.
 
I'm not sure if I would call Backblaze nor Crashplan a good backup solution.

Read this story
http://www.fredmiranda.com/forum/topic/1112208/0

The problem is that both of them do not have a backup of your data. So if you lose you data locally, and screw up the recovery process you could lose all your data.

A good online backup solution should have backup of their own data. But being cheap sells better...
 
I'm running CrashPlan with backups to their servers and to my own local server.
 
Crashplan for me. I have 5Mbit upload and have 7TB currently stored on Crashplan. It's been working wonderfully for me.

I've never heard of Crashplan losing someones data.

Crashplan has many high-profile clients:

Google, Adobe, Cisco, Mozilla, Netflix, HP, Linkedin, Citrix, ICANN, Pandora, Kraft foods, Los Alamos, NASA, National Geographic, SanDisk, Bank of America, Harvard, Stanford, Johns Hopkins, Penn, MIT.

If they trust them I would too.
 
Definitely don't keep all your eggs in one basket and spread it out with a local backup and then another offsite backup.
 
I do remember seeing that page when I first decided to buy Crashplan.

It seems like a pretty isolated incident. It was a hardware failure followed by human error. No doubt they learned from their screw up and at least they offered to help by giving out free seed drives to get the data re-backed up.

Data storage is always a cost/risk balance.

So for me to lose my data I have to have 3 failures all happen at once. I have to lose my main working copy array and Crashplan has to suffer a hardware failure, and Crashplan has to suffer from human error all at once for me to completely lose my data.

I think the chances of me losing my local array at the same time Crashplan suffers form both a hardware and human error are pretty slim. Of course it could happen, but with any backup solution something could always happen.

For their cost I think its still a great service.

And I though backup was not about not losing one copy (that's impossible) it's about not losing all copies simultaneously.
 
Do you all have fiber connections ? I couldn't dream of uploading my data, it would take years. And I see in the thread that Crashplan has 60 Petabytes with millions of customers, that seems low. Alone I already have more than 60TB, sure that's extreme but 1TB doesn't seem to be that much and that would only mean 60 000 customers.
 
I use crashplan without a subscription. Backups my key files from my zfs server to my desktop (windows), a friend's computer (windows) and a server in my parents house (zfs).

Although it costs substantially more to put a server elsewhere, I thought this would be best. In this scenario I do not have to depend on the months of uploading to CP's servers or the hours/days /weeks of downloading if I need to recover. Depending on how bad the "catastrophic event" is, I have a backup that I can recover from over lan that is feets/yards away (my desktop), <5 miles away (friend's) and ~30 miles away (parents).

Additionally, I have the ability to control how my data is stored. Obviously, I chose ZFS to protect my data so I am also able to ensure there shouldn't be any corruption on at least one of my backups.
 
Aesma said:
Do you all have fiber connections ? I couldn't dream of uploading my data, it would take years. And I see in the thread that Crashplan has 60 Petabytes with millions of customers, that seems low. Alone I already have more than 60TB, sure that's extreme but 1TB doesn't seem to be that much and that would only mean 60 000 customers.
Click to expand...

Crashplan also uses deduplication so the two seasons of My Little Ponies that you and all the other Bronies have backed up only take the space up one time with pointers for the other bronies.

***I just used MLP as an example, go rainbow dash!
 
LibertySyclone said:
Crashplan also uses deduplication so the two seasons of My Little Ponies that you and all the other Bronies have backed up only take the space up one time with pointers for the other bronies.

***I just used MLP as an example, go rainbow dash!
Click to expand...

I don't think they could deduplicate between accounts without security concerns.
 
s0rce said:
I don't think they could deduplicate between accounts without security concerns.
Click to expand...

Why not? If you're doing de-dupe by blocks then a calculated checksum of it would be the same for anything else that happened to use the same sequence of bytes. Assuming the checksum is sufficiently unique and still smaller than the blocks (which could be of any size) then it would be reasonable to de-dupe based on it.
 
CrashPlan doesn't use De-dupe, Its all encrypted on your end with a 448-bit AES encryption, Now unless u make a custom password for that computer (an option they do offer in the software) they technically have ur credentials which is used for encryption up until u set a custom password. So sense the encrypted data would be unique regardless of the original unencrypted data that cant use de-dupe on their end, they may use it on your end but it wont do much.

Unless they are violating the privacy agreement (like Dropbox use to do before they changed their practices)

Now as to the low percentage of data per costumer they have, my guess is because they cater to people running non windows/mac os systems they have a lot of documents rather then Media (not to say they cant have large media), Not many have a 20tb movie collection. I for one fit all my important stuff on a 4gb flash drive, with my media that i use regularly fits on a 500gb HDD (with OS) with an archive of about 2tb that is for older photos and such.

Although i would like to convert my movie collection to Digital, i dont have the time right now.

They could also be compressing the stream before it gets encrypted saving on some data.
 
There's nothing about a series of bytes containing encrypted data that's any different than unencypted or uncompressed data. A checksum across a block (which could be of any size) is the only relevant thing. How a storage system cross-links the checksums has nothing to do with what the filesystem on the customer end thinks is present. It's all just bytes. Compressed, encrypted, plain, whatever, doesn't matter if the storage system is only doing it based on block checksums.
 
wkearney99 said:
There's nothing about a series of bytes containing encrypted data that's any different than unencypted or uncompressed data. A checksum across a block (which could be of any size) is the only relevant thing. How a storage system cross-links the checksums has nothing to do with what the filesystem on the customer end thinks is present. It's all just bytes. Compressed, encrypted, plain, whatever, doesn't matter if the storage system is only doing it based on block checksums.
Click to expand...

If the encryption key is different, then two copies of the same block of data will encrypt to completely different blocks of data. And encrypted data looks essentially random. So, since most customers would have unique encryption keys, any customers with the same local data would not have the same encrypted data on the server. Technically, of course, dedupe could still be used, but it would be almost completely ineffective. It would be like you generated 10GB of random data for each customer, and then tried to see if any blocks of data were shared between customers.
 
Blocks stored, not files in a filesystem. A chunk of data is just as series of bytes, what's in those bytes is irrelevant. How they were created is likewise irrelevant. How they checksum is the important factor. So, yes, the same chunks of the same data encrypted with different keys will result in different results. But the output of them could well have a checksum that overlaps some other completely different data. There's the de-dupe possibility. Yes, it would take a lot to discover and track this sort of thing. That's what much higher performance and capacity SANs are capable of doing.

A some point it's possible to have a checksum of every possible combination of bytes over a given block size. Assuming the block size and checksum calculation allow for a truly unique fingerprint for the sequence. When you've got a sufficiently large enough pool of data it's entirely possible to do it. Whether or not it's computationally or economically advantageous to do it is another matter. But it's certainly possible. Whether or not someone chooses to do it doesn't change that it's possible.

The same as whether it's likely customers will use encryption or compression. Some might, most probably won't.
 
You are wrong on two counts.

First, Crashplan uses a unique encryption key for every customer. Customers do not have a choice. The only choice is whether the customer uses a "private password" so that the encryption key itself is encrypted. As I already posted, each customer's data is encrypted with a unique encryption key.

http://support.crashplan.com/doku.p...s_createmaintainsave_my_encryption_key_for_me

Second, you obviously do not understand the mathematics of encryption and deduplication. No one with any sense would suggest it could be worthwhile to do deduplication on encrypted data. I could explain that a random 512-byte block has a state space of more than 10^1233, or that the probability of a random collision of a 128-bit hash used on 10^15 512-byte blocks is less than 10^-8 , but suffice it to say that anyone who has a basic understanding of information theory should know that, like random data, encrypted data cannot be effectively compressed or deduped.
 
Check out Amazon Glacier for backup. Pricing can be complicated, but great for online archiving.
 
Every time I make a copy on Windows, I do a MD5 checksum of the original and the copy, to make sure no bits have been flipped. To verify the copy is identical to the original.

Do you you do that, when you have uploaded files to crashplan? Compare crashplan files with the files on your computer? MD5 checksums?
 
You must log in or register to reply here.
Back
Top