CrashPlan 4.7 notice from Code42

[Slovak]

Just received this from CrashPlan:

Dear Peter,

Our records indicate that one or more of the devices associated with your CrashPlan account are using an operating system that does not meet the supported operating system version requirements.

Beginning on May 16, 2016, all devices that connect to the Code42 public cloud will be upgraded to CrashPlan app version 4.7. If you use another computer you own or a friend's computer as a backup destination, both computers must upgrade to CrashPlan app version 4.7 in order for backups to continue. These computers must be upgraded to a supported operating system so that the CrashPlan app can automatically upgrade to version 4.7 and continue computer-to-computer backups.

Details on this topic and your options can be found on our support site.

For an optimal data backup strategy, we strongly recommend that our users backup to three destinations – local, offsite and online. Learn more about our triple destination backup strategy here.

If you are interested in learning more about automatic, continuous cloud storage options from CrashPlan, check out our subscription options at store.code42.com/store/.

Thank you,

The CrashPlan team

Not sure what to read into it. Usually, older versions of CrashPlan are supported for a defined time before being "discontinued" and forced to upgrade. Is Code42 looking to eliminate "support" for the people using their software but not backing up to their paid cloud? Is this a way to eliminate someone running CrashPlan on a NAS and backing up large volumes of data to their "unlimited" cloud?

Or is this just a PSA letting us know of an upcoming upgrade so that we can "expect" breakage with past versions?

 

[Phlogi]

Could we "easily" fake the jail environment to make it look like linux, as they still support that?

 

[birt]

I just received the same notice.

I'm considering blocking the update on the destination computer, although I'm not sure that's going to have the desired effect - they might simply block account logins with older versions.

 

[Slovak]

I just received the same notice.

I'm considering blocking the update on the destination computer, although I'm not sure that's going to have the desired effect - they might simply block account logins with older versions.

How will you block the update?

 

[birt]

There's a number of ways. One would be blocking access via the firewall (if the update is coming from a different IP than the one used for logging in), another would be blocking access to the files so that the service doesn't have write access to them and yet another would be replacing the update-related class files in the JAR with dummies that have empty functions. I'm sure there must be other ways that I'm not thinking of right now.

The problem is: would it continue to work if it wasn't updated? In any case, I am taking daily snapshots of the destination computer's OS drive, I figure I'll just roll back after the upgrade and check if it works then block the update if it does (or block the update and then check if it insists on updating as soon as it starts).

Worst case I'll just create a VM and be done with it, it might be more sensible this way. Worst problem is that I would have to re-upload a couple TB of stuff.

 

[Slovak]

Worst problem is that I would have to re-upload a couple TB of stuff.

Shouldn't need to. Just point the VM mount point to the same dataset/directory as now. I've moved a couple of CrashPlan instances, and generally it'll rescan/resync the full install and then just update the new files. Much more efficient. There's a couple of FAQ on Code42 site specific to this.

 

[birt]

Thanks, didn't know, I'll try that if it comes to it. Uploading ~2TB at 1MB/s can take quite a while so I'd rather avoid that.

Come to think of it, I believe I might just opt for the VM anyway if the current setup stops working. It's not the first time I have to fool a Windows box into thinking a network drive is local and I already have a backup VM lying around on my VM server which has a dedicated link to the NAS. As a bonus, it would save me the pain in the behind of having to read that .ui_info file in the crashplan jail every time I want to run the UI remotely.

 

[Dillan]

I got the same notice and my destination is currently a linux box, fully updated, so I am very confused. I think it is more of a PSA, because the devices they list as not working when you follow the links in the post are linux boxes with a kernel version 2.6.31 or earlier and glibc version 2.8 or earlier. Still not sure why I got the notice as both of those on my system are far newer than those versions.

 

[Thirtybird]

I got this same notice as well. I'm currently in the process of setting up an ubuntu crashplan VM on freenas. My install is done and working - I still want to change my mount points to match the jail I was using, but it's synchronizing block information on the new backup VM.

Doing it with an ubuntu VM running on a Virtualbox jail on FreeNas 9.2.1.8 using Virtualbox Shared Folders to share the jail storage with the Ubuntu 16.04 server guest. Since Ubuntu 16.04 is a supported OS from Crashplan, this should stay working (in theory)

Steps below:

add jail for virtualbox
create a new VM called "Crashplan"
add storage to host for each mount to be backed up

set up ubuntu 16.04 server x86
add ssh daemon during install

(steps to set up ubuntu not included!)

perform the following to get the VirtualBox Client Tools installed
apt-get update
apt-get upgrade
apt-get install build-essential linux-headers-generic
apt-get install virtualbox-guest-dkms virtualbox-guest-utils
reboot now

Query the GuestAddition versions with this command
lsmod | grep -io vboxguest | xargs modinfo | grep -iw version

The following was the version that worked
version: 5.0.18_Ubuntu

Install Crashplan
https://support.code42.com/CrashPlan/4/Getting_Started/Installing_The_Code42_CrashPlan_App
Extract the installer
cd ~
mkdir Downloads
cd to the directory with the downloaded file (Since the shared folders are aleady mounted, I just browsed to my NAS)
tar zxvf CrashPlan_4.6.0_Linux.tgz -C ~/Downloads
cd ~
cd Downloads/crashplan-install
./install.sh
(accepted all install defaults)
Crashplan installed successfully

Open up connection on service port 4243 to remote computers
vi /usr/local/crashplan/conf/my.service.xml

Change <serviceHost> from localhost to 0.0.0.0

restart Crashplan
verify that java is listening on all IPs for port 4243
netstat -peanut

tcp6 0 0 :::4243 :::* LISTEN 0 16594 1127/java

Edit JAVA options here (unsure if this is still necessary?)
vi /usr/local/crashplan/bin/run.conf

Add "-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.PollSelectorProvider" to both variables
SRV_JAVA_OPTS="-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.PollSelectorProvider -Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappB....
GUI_JAVA_OPTS="-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.PollSelectorProvider -Dfile.encoding=UTF-8 -Dapp=CrashPlanDesktop -DappB....

verify the token doesn't match your client connection token
cat /var/lib/crashplan/.ui_info ; echo

token doesn't match client machine (it shouldn't)

stop crashplan

edit the .ui_info file and put the correct token from the client machine in there
vi /var/lib/crashplan/.ui_info

start crashplan

Configure a static IP address
https://www.howtoforge.com/linux-basics-set-a-static-ip-on-ubuntu
cp /etc/network/interfaces /etc/network/interfaces.bak
vi /etc/network/interfaces

change the netwrok adapter config to a static address
iface enp0s3 inet static
address 192.168.X.X
netmask 255.255.255.0
gateway 192.168.X.1
dns-nameservers 192.168.X.1

reboot now

update .ui_info on client machine to new ip address

connect from remote PC WORKS!

Assume the old backup server role - let it do its synchronization (takes forever)

I'm still working on the steps to change the shared folder mount point - this is done from the Virtualbox Host server using VBoxManage... rough steps below
------------------------------
create user on Virtualbox HOST to allow SSH in (add to wheel group to allw SU access)
adduser

SSH to Virtualbox Host

sudo to vbox user
sudo - vbox

$ VBoxManage list vms
"Crashplan" {GUID here}

$ VBoxManage guestproperty enumerate "Crashplan"

From : http://askubuntu.com/questions/563031/change-mount-point-of-virtualbox-shared-folder
Both properties detailed in the first link have default values when not set or cleared:
/VirtualBox/GuestAdd/SharedFolders/MountPrefix defaults to sf_ if not set.
/VirtualBox/GuestAdd/SharedFolders/MountDir defaults to /media if not set

VBoxManage guestproperty get "Crashplan" "/VirtualBox/GuestAdd/SharedFolders/MountPrefix"
VBoxManage guestproperty get "Crashplan" "/VirtualBox/GuestAdd/SharedFolders/MountDir"

VBoxManage guestproperty set "Crashplan" "/VirtualBox/GuestAdd/SharedFolders/MountPrefix" "/"
VBoxManage guestproperty set "Crashplan" "/VirtualBox/GuestAdd/SharedFolders/MountDir" "/"

 

[adrianwi]

I've started down this root using ubuntu 14.4 for the crashplan VM, but I'm struggling with some permissions when trying to access the datasets I've mounted to the VirtualBox VM and subsequently shared with ubuntu.

I'm using ownCloud and want to backup the ocfiles dataset but in order for owncloud to work this need to be set as www:www. When I share through the VM it assigns permissions of root:vboxsf and when I assign the vboxsf group to the user account I still can't access the folder. This worked fine for another dataset (backup) but this doesn't have the www:www permissions (it has 501:staff as it's a rsync from a HDD on my iMac).

Any ideas?

 

[frenzo]

I finally gave up on the plugin and went with Ubuntu VM. The plugin was just too frustrating. I did not use VM Shared Folders but instead mounted Read Only NFS shares (they auto mount on reboot) to access the data I wanted to backup. It's been up about 2 weeks with virtually no issues except having the update the port and token on my desktop's Crashplan client every few days. Not sure if that can be fixed but it is really not a big deal.

 

[Dillan]

I got a response back from a crashplan team member, it looks like they sent out a lot of false negatives:

"We sent out an email blast warning of our impending update to users that we believed would not be supported on the new version, but the criteria that we set for the email meant that some customers that were running valid configurations did get included by accident."​

If we are lucky, everything will continue as usual after the update without any need for new workarounds.

 

[Slovak]

2 FreeNAS instances did not auto upgrade from 4.5.0 to 4.7.0. Surprisingly, some computers (which upgraded the client software to 4.7.0) continued to back up successfully, while others stopped backing up/connecting altogether.

Performing a quick self-upgrade resolved the issues and CrashPlan continues to run as before. Reference https://forums.freenas.org/index.php?threads/tested-crashplan-4-5-setup.41418/ and https://forums.freenas.org/index.php?threads/unable-to-find-crashplan-server.42117/#post-272251 for details.

In a nutshell, my upgrade process was:

Code:

sudo jexec name_of_jail_ csh
cd /usr/pbi/crashplan-amd64/share/crashplan
wget --no-check-certificate http://download.code42.com/installs/linux/install/CrashPlan/CrashPlan_4.7.0_Linux.tgz
tar -xf CrashPlan_4.7.0_Linux.tgz
cd crashplan-install/
cpio -idv < CrashPlan_4.7.0.cpi
service crashplan stop
cd ..
rm -r lib*
cp -r crashplan-install/lib* .
service crashplan start
rm CrashPlan_4.7.0_Linux.tgz
rm -r crashplan-install