Hello All,

Jarrod from Code42 here. Sorry about the scare. Wanted to clarify a few things.

If a restore has been initiated from the archive of the device in question it's considered "connected" and your data won't be deleted. To be clear - no automated process is going to remove your data while you’re restoring.

You are correct in your assumption about the other devices— we are in the process of enforcing this policy when we previously haven't. We realize that many users won't be aware of this existing retention policy. That's why we've been testing different messages to small batches of users (small meaning .3% of our user base) and seeing how they respond.

Like the email says many of the affected archives are from backups that were once connected to an older device. This often happens because people aren't aware of our "adoption" process that is used to connect and existing backup to a new device. Because silent, continuous backup is very "set it and forget" many folks just end up backing up their new machine instead of getting rid of the old backup. Bit by bit the data in those forgotten archives adds up. Thus why we’ve begun enforcing this policy.

We’re trying to learn as much as possible from these small test batches so that we can clean up some of these “dusty archives” as we call them sooner rather than later while making sure we do right by our customers. I’ve certainly learned a lot from the feedback you’ve provided here.

Please let me know if you have additional questions.

Best Regards,

Jarrod

Hello Everyone,

Great questions, let’s dive right in.

One thing I wanted to clarify is that this policy only affects devices that have not connected to CrashPlan Central in 6 months or longer. This does not affect volumes that have not connected to the device in that period of time. (i.e. an external hard drive that has not connected in 6 months.)

Many of you are inquiring about the notification emails being sent before/after the archives are deleted. Like I mentioned in my previous reply, we’ve been testing verbiage to small groups of our users who are affected. Our goal here is to dial in the messaging so users take action as opposed to ignoring the email (something we routinely see from our some of our customer base). In some cases, we sent very direct emails in order to provoke action from the sample base.

We want users to address any old archives that have not connected. Part of CrashPlan’s ability to maintain the archive health and integrity relies upon regular connection from the device. CrashPlan is able to routinely perform maintenance on the archive by comparing checksums between both device and CrashPlan Central.

https://support.code42.com/Administrator/3/Monitoring_And_Ma...

From the feedback we’ve received so far (including this thread), it’s evident we should provide advanced warning prior to deletion of these archives. We’ll continue to refine our messaging to reflect this.

Thank you again for all your feedback.

Jarrod

It would be good if -- in addition to emailing customers BEFORE you archive their backups -- you specify in the email what counts as 'connected'. I already responded to this HN post by digging an ancient machine out of the closet and booting it, so that it can connect to CrashPlan, make a null backup, and thus rescue my old backups of it from impending deletion. If merely performing a single-file restore (or merely checking some box on the website) was enough to indicate that the backup is still 'live', that would be nice to know.

Thanks for the reply Jarrod. It's good to know my data is safe for now. I'm continuing to run restores of all my other old devices.

The biggest problem here was the communication. The email I got said "...this device has been removed from CrashPlan Central". That's a pretty scary thing to receive. Had it instead said "...will be removed in 60 days", with follow up emails every week, and perhaps daily in the last few days before deletion that would have been much more reassuring and informative, and I would have had the time to check everything was in order before the deadline. It's far better to send too many emails warning a user about a deletion than it is to send too few.

While those backups are old, and I probably do have all the files I need from them, I certainly wouldn't like it if they were deleted without me being able to check through to make sure there is nothing important left.

I appreciate that I was caught in a small test group, so hopefully you'll have these kind of issues ironed out before too many other people see it.

I have a question... Are you sending people emails letting them know you have ALREADY deleted the backup, or are you giving them advanced warning that you WILL delete it in X days?

Do you intend to remove the verbiage about "Unlimited online storage?" If something is legitimately unlimited then this policy makes no sense but as both you and I know truly unlimited anything is impossible, so why say it?

Is there another method to prevent / cancel the delete without having to activate that machine? I can envision a scenario where I'm given a week to reconnect an old machine, but I'm travelling overseas for a month and don't have physical access to it.

I can understand the policy and the action, but the notification should come prior to deletion. And possibly include a per machine opt-out for paying customers. (For the record I am a paying customer and have a couple old backups, but haven't yet run across this.)

+1 for the per machine opt-out. I have some older machines that I only use infrequently but still want to use CrashPlan on. It's unlikely any would be turned off for six months, but one of them did have a multi-month disconnect from CrashPlan due to a weird Java version conflict.

(Also, because I tend to keep my older machines and still want to use CrashPlan there, it's harder for me to use the "adopt a machine" method. I bought a new computer and just finished re-uploading about 200GB of near-identical data.)