jarrodatCode42

Wanted to pop in here and expound on the topic.

CrashPlan has versioning that is set (by default) to back up changed files in 15 minute increments. If a file is corrupted, CrashPlan will attempt to back up the changes as it is not a corruption detection utility.

However, it's versioning allows for a user to easily restore the uncorrupted file by selecting a date prior to the corruption occurring.

This process is explained in greater detail here:

https://support.code42.com/CrashPlan/4/Troubleshooting/Recov...

The default versioning can be adjusted, so ultimately it's the responsibility of the individual user to confirm the health of their backup and verify the versioning frequency that best fits their needs.

Just wanted to clarify this policy.

CrashPlan requires a device to connect to it's backup at least once within a 6 month period. This is to ensure the integrity of the data we're storing. Part of CrashPlan’s ability to maintain the backup health and integrity relies upon regular connection from the device. CrashPlan is able to routinely perform maintenance on the backup by comparing checksums between both device and CrashPlan Central. If you are unable to connect the device to the backup within a 6 month period, you can also perform a restore from the backup as this qualifies as recent backup activity.

Since the infrastructure for CrashPlan's backup engine is the same between our Business/Consumer clients, we recommend that all users routinely connect their devices to the backup destinations. That being said, this policy only affects CrashPlan for Home subscribers at this time.

Hello Everyone,

Wanted to jump in here to confirm.

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.) Additionally, there is no minimum connection time for local CrashPlan backups.

It’s important for CrashPlan users to consistently connect their device(s). 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...

Please let me know if I can provide additional clarity.

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

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