and other brilliant error messages

CrashPlan packages for Synology NAS

UPDATE – CrashPlan For Home (green branding) was retired by Code 42 Software on 22/08/2017. See migration notes below to find out how to transfer to CrashPlan for Small Business on Synology at the special discounted rate.

CrashPlan is a popular online backup solution which supports continuous syncing. With this your NAS can become even more resilient, particularly against the threat of ransomware.

The instructions and notes on this page apply to both versions of the Synology package.

CrashPlan is a Java application which can be difficult to install on a NAS. Way back in January 2012 I decided to simplify it into a Synology package, since I had already created several others. It has been through many versions since that time, as the changelog below shows. Although it used to work on Synology products with ARM and PowerPC CPUs, it unfortunately became Intel-only in October 2016 due to Code 42 Software adding a reliance on some proprietary libraries.

Licence compliance is another challenge – Code 42’s EULA prohibits redistribution. I had to make the Synology package use the regular CrashPlan for Linux download (after the end user agrees to the Code 42 EULA). I then had to write my own script to extract this archive and mimic the Code 42 installer behaviour, but without the interactive prompts of the original.

Synology Package Installation

The repository will push its certificate automatically to the NAS, which is used to validate package integrity. Set the Trust Level to Synology Inc. and trusted publishers:

Now browse the Community section in Package Center to install CrashPlan:
The repository only displays packages which are compatible with your specific model of NAS. If you don’t see CrashPlan in the list, then either your NAS model or your DSM version are not supported at this time. DSM 5.0 is the minimum supported version for this package, and an Intel CPU is required.

Since CrashPlan is a Java application, it needs a Java Runtime Environment (JRE) to function. It is recommended that you select to have the package install a dedicated Java 8 runtime. For licensing reasons I cannot include Java with this package, so you will need to agree to the licence terms and download it yourself from Oracle’s website. The package expects to find this .tar.gz file in a shared folder called ‘public’. If you go ahead and try to install the package without it, the error message will indicate precisely which Java file you need for your system type, and it will provide a TinyURL link to the appropriate Oracle download page.

To install CrashPlan PRO you will first need to log into the Admin Console and download the Linux App from the App Download section and also place this in the ‘public’ shared folder on your NAS.

If you have a multi-bay NAS, use the Shared Folder control panel to create the shared folder called public (it must be all lower case). On single bay models this is created by default. Assign it with Read/Write privileges for everyone.

If you have trouble getting the Java or CrashPlan PRO app files recognised by this package, try downloading them with Firefox. It seems to be the only web browser that doesn’t try to uncompress the files, or rename them without warning. I also suggest that you leave the Java file and the public folder present once you have installed the package, so that you won’t need to fetch this again to install future updates to the CrashPlan package.

CrashPlan is installed in headless mode – backup engine only. This will configured by a desktop client, but operates independently of it.

The first time you start the CrashPlan package you will need to stop it and restart it before you can connect the client. This is because a config file that is only created on first run needs to be edited by one of my scripts. The engine is then configured to listen on all interfaces on the default port 4243.

CrashPlan Client Installation

Once the CrashPlan engine is running on the NAS, you can manage it by installing CrashPlan on another computer, and by configuring it to connect to the NAS instance of the CrashPlan Engine.

Make sure that you install the version of the CrashPlan client that matches the version running on the NAS. If the NAS version gets upgraded later, you will need to update your client computer too.

The Linux CrashPlan PRO client must be downloaded from the Admin Console and placed in the ‘public’ folder on your NAS in order to successfully install the Synology package.

By default the client is configured to connect to the CrashPlan engine running on the local computer. Run this command on your NAS from an SSH session:echo `cat /var/lib/crashplan/.ui_info`
Note those are backticks not quotes. This will give you a port number (4243), followed by an authentication token, followed by the IP binding (0.0.0.0 means the server is listening for connections on all interfaces) e.g.:4243,9ac9b642-ba26-4578-b705-124c6efc920b,0.0.0.0
port,--------------token-----------------,binding
Copy this token value and use this value to replace the token in the equivalent config file on the computer that you would like to run the CrashPlan client on – located here:C:\ProgramData\CrashPlan\.ui_info (Windows)“/Library/Application Support/CrashPlan/.ui_info” (Mac OS X installed for all users)“~/Library/Application Support/CrashPlan/.ui_info” (Mac OS X installed for single user)/var/lib/crashplan/.ui_info (Linux)
You will not be able to connect the client unless the client token matches on the NAS token. On the client you also need to amend the IP address value after the token to match the Synology NAS IP address.
so using the example above, your computer’s CrashPlan client config file would be edited to:4243,9ac9b642-ba26-4578-b705-124c6efc920b,192.168.1.100
assuming that the Synology NAS has the IP 192.168.1.100
If it still won’t connect, check that the ServicePort value is set to 4243 in the following files:C:\ProgramData\CrashPlan\conf\ui_(username).properties (Windows)“/Library/Application Support/CrashPlan/ui.properties” (Mac OS X installed for all users)“~/Library/Application Support/CrashPlan/ui.properties” (Mac OS X installed for single user)/usr/local/crashplan/conf (Linux)/var/lib/crashplan/.ui_info (Synology) – this value does change spontaneously if there’s a port conflict e.g. you started two versions of the package concurrently (CrashPlan and CrashPlan PRO)

As a result of the nightmarish complexity of recent product changes Code42 has now published a support article with more detail on running headless systems including config file locations on all supported operating systems, and for ‘all users’ versus single user installs etc.

You should disable the CrashPlan service on your computer if you intend only to use the client. In Windows, open the Services section in Computer Management and stop the CrashPlan Backup Service. In the service Properties set the Startup Type to Manual. You can also disable the CrashPlan System Tray notification application by removing it from Task Manager > More Details > Start-up Tab (Windows 8/Windows 10) or the All Users Startup Start Menu folder (Windows 7).
To accomplish the same on Mac OS X, run the following commands one by one:

Migration from CrashPlan For Home to CrashPlan For Small Business (CrashPlan PRO)

Go through the online migration using the link in the email notification you received from Code 42 on 22/08/2017. This seems to trigger the CrashPlan client to begin an update to 4.9 which will fail. It will also migrate your account onto a CrashPlan PRO server. The web page is likely to stall on the Migrating step, but no matter. The process is meant to take you to the store but it seems to be quite flakey. If you see the store page with a $0.00 amount in the basket, this has correctly referred you for the introductory offer. Apparently the $9.99 price thereafter shown on that screen is a mistake and the correct price of $2.50 is shown on a later screen in the process I think. Enter your credit card details and check out if you can. If not, continue.

Log into the CrashPlan PRO Admin Console as per these instructions, and download the CrashPlan PRO 4.9 client for Linux, and the 4.9 client for your remote console computer. Ignore the red message in the bottom left of the Admin Console about registering, and do not sign up for the free trial. Preferably use Firefox for the Linux version download – most of the other web browsers will try to unpack the .tgz archive, which you do not want to happen.

Configure the CrashPlan PRO 4.9 client on your computer to connect to your Syno as per the usual instructions on this blog post.

Put the downloaded Linux CrashPlan PRO 4.9 client .tgz file in the ‘public’ shared folder on your NAS. The package will no longer download this automatically as it did in previous versions.

This will stop the CrashPlan package and automatically import its configuration. Notice that it will also backup your old CrashPlan .identity file and leave it in the ‘public’ shared folder, just in case something goes wrong.

You should see your protected folders as usual. At first mine reported something like “insufficient device licences”, but the next time I started up it changed to “subscription expired”.

Uninstall the CrashPlan 4.8.3 Synology package, this is no longer required.

At this point if the store referral didn’t work in the second step, you need to sign into the Admin Console. While signed in, navigate to this link which I was given by Code 42 support. If it works, you should see a store page with some blue font text and a $0.00 basket value. If it didn’t work you will get bounced to the Consumer Next Steps webpage: “Important Changes to CrashPlan for Home” – the one with the video of the CEO explaining the situation. I had to do this a few times before it worked. Once the store referral link worked and I had confirmed my payment details my CrashPlan PRO client immediately started working. Enjoy!

Notes

The package uses the intact CrashPlan installer directly from Code 42 Software, following acceptance of its EULA. I am complying with the directive that no one redistributes it.

The engine daemon script checks the amount of system RAM and scales the Java heap size appropriately (up to the default maximum of 512MB). This can be overridden in a persistent way if you are backing up large backup sets by editing /var/packages/CrashPlan/target/syno_package.vars. If you are considering buying a NAS purely to use CrashPlan and intend to back up more than a few hundred GB then I strongly advise buying one of the models with upgradeable RAM. Memory is very limited on the cheaper models. I have found that a 512MB heap was insufficient to back up more than 2TB of files on a Windows server and that was the situation many years ago. It kept restarting the backup engine every few minutes until I increased the heap to 1024MB. Many users of the package have found that they have to increase the heap size or CrashPlan will halt its activity. This can be mitigated by dividing your backup into several smaller backup sets which are scheduled to be protected at different times. Note that from package version 0041, using the dedicated JRE on a 64bit Intel NAS will allow a heap size greater than 4GB since the JRE is 64bit (requires DSM 6.0 in most cases).

If you need to manage CrashPlan from a remote location, I suggest you do so using SSH tunnelling as per this support document.

The package supports upgrading to future versions while preserving the machine identity, logs, login details, and cache. Upgrades can now take place without requiring a login from the client afterwards.

If you remove the package completely and re-install it later, you can re-attach to previous backups. When you log in to the Desktop Client with your existing account after a re-install, you can select “adopt computer” to merge the records, and preserve your existing backups. I haven’t tested whether this also re-attaches links to friends’ CrashPlan computers and backup sets, though the latter does seem possible in the Friends section of the GUI. It’s probably a good idea to test that this survives a package reinstall before you start relying on it. Sometimes, particularly with CrashPlan PRO I think, the adopt option is not offered. In this case you can log into CrashPlan Central and retrieve your computer’s GUID. On the CrashPlan client, double-click on the logo in the top right and you’ll enter a command line mode. You can use the GUID command to change the system’s GUID to the one you just retrieved from your account.

The log which is displayed in the package’s Log tab is actually the activity history. If you are trying to troubleshoot an issue you will need to use an SSH session to inspect these log files:/var/packages/CrashPlan/target/log/engine_output.log
/var/packages/CrashPlan/target/log/engine_error.log
/var/packages/CrashPlan/target/log/app.log

When CrashPlan downloads and attempts to run an automatic update, the script will most likely fail and stop the package. This is typically caused by syntax differences with the Synology versions of certain Linux shell commands (like rm, mv, or ps). The startup script will attempt to apply the published upgrade the next time the package is started.

Although CrashPlan’s activity can be scheduled within the application, in order to save RAM some users may wish to restrict running the CrashPlan engine to specific times of day using the Task Scheduler in DSM Control Panel:
Note that regardless of real-time backup, by default CrashPlan will scan the whole backup selection for changes at 3:00am. Include this time within your Task Scheduler time window or else CrashPlan will not capture file changes which occurred while it was inactive:

If you decide to sign up for one of CrashPlan’s paid backup services as a result of my work on this, please consider donating using the PayPal button on the right of this page.

Package scripts

For information, here are the package scripts so you can see what it’s going to do. You can get more information about how packages work by reading the Synology 3rd Party Developer Guide.

0046 26/Aug/17 – Updated to CrashPlan PRO 4.9, added support for migration from CrashPlan For Home to CrashPlan For Small Business (CrashPlan PRO). Please read the Migration section on this page for instructions.

0041 20/Jul/16 – Improved auto-upgrade compatibility (hopefully), added option to have CrashPlan use a dedicated Java 7 Runtime instead of the default system one, including 64bit Java support on 64 bit Intel CPUs to permit memory allocation larger than 4GB

0040 25/May/16 – Added cpio to the path in the running context of start-stop-status.sh

0039 25/May/16 – Updated to CrashPlan 4.7.0, at each launch forced the use of the system JRE over the CrashPlan bundled Intel one, added Maven build of JNA 4.1.0 for ARMv7 systems consistent with the version bundled with CrashPlan

0036 14/Dec/15 – Updated to CrashPlan 4.5.0, separate firewall definitions for management client and for friends backup, added support for DS716+ and DS216play

0035 06/Nov/15 – Fixed the update to 4.4.1_59, new installs now listen for remote connections after second startup (was broken from 4.4), updated client install documentation with more file locations and added a link to a new Code42 support doc
EITHER completely remove and reinstall the package (which will require a rescan of the entire backup set) OR alternatively please delete all except for one of the failed upgrade numbered subfolders in /var/packages/CrashPlan/target/upgrade before upgrading. There will be one folder for each time CrashPlan tried and failed to start since Code42 pushed the update

0031 20/May/15 – Updated to CrashPlan 4.2, cross compiled a newer cpio binary for some architectures which were segfaulting while unpacking main CrashPlan archive, added port 4242 to the firewall definition (friend backups), package is now signed with repository private key

0030 16/Feb/15 – Fixed show-stopping issue with version 0029 for systems with more than one volume

0029 21/Jan/15 – Updated to CrashPlan version 3.7.0, improved detection of temp folder (prevent use of /var/@tmp), added support for Annapurna Alpine AL514 CPU (armhf) in DS2015xs, added support for Marvell Armada 375 CPU (armhf) in DS215j, abandoned practical efforts to try to support Code42’s upgrade scripts, abandoned inotify support (realtime backup) on PowerPC after many failed attempts with self-built and pre-built jtux and jna libraries, back-merged older libffi support for old PowerPC binaries after it was removed in 0028 re-write

0028 22/Oct/14 – Substantial re-write:
Updated to CrashPlan version 3.6.4
DSM 5.0 or newer is now requiredlibjnidispatch.so taken from Debian JNA 3.2.7 package with dependency on newer libffi.so.6 (included in DSM 5.0)jna-3.2.5.jar emptied of irrelevant CPU architecture libs to reduce size
Increased default max heap size from 512MB to 1GB on systems with more than 1GB RAM
Intel CPUs no longer need the awkward glibc version-faking shim to enable inotify support (for real-time backup)
Switched to using root account – no more adding account permissions for backup, package upgrades will no longer break this
DSM Firewall application definition added
Tested with DSM Task Scheduler to allow backups between certain times of day only, saving RAM when not in use
Daemon init script now uses a proper PID file instead of Code42’s unreliable method of using grep on the output of ps
Daemon init script can be run from the command line
Removal of bash binary dependency now Code42’s CrashPlanEngine script is no longer used
Removal of nice binary dependency, using BusyBox equivalent renice
Unified ARMv5 and ARMv7 external binary package (armle)
Added support for Mindspeed Comcerto 2000 CPU (comcerto2k – armhf) in DS414j
Added support for Intel Atom C2538 (avoton) CPU in DS415+
Added support to choose which version of CrashPlan PROe client to download, since some servers may still require legacy versions
Switched to .tar.xz compression for native binaries to reduce web hosting footprint

0022 10/Jun/13 – Updated all CrashPlan client versions to 3.5.3, compiled native binary dependencies to add support for Armada 370 CPU (DS213j), start-stop-status.sh now updates the new javaMemoryHeapMax value in my.service.xml to the value defined in syno_package.vars

011 minor fix to allow a wildcard on the cpio archive name inside the main installer package (to fix CP PROe client since Code 42 Software had amended the cpio file version to 3.2.1.2)

010 minor bug fix relating to daemon home directory path

009 rewrote the scripts to be even easier to maintain and unified as much as possible with my imminent CrashPlan PROe server package, fixed a timezone bug (tightened regex matching), moved the script-amending logic from installer.sh to start-stop-status.sh with it now applying to all .sh scripts each startup so perhaps updates from Code42 might work in future, if wget fails to fetch the installer from Code42 the installer will look for the file in the public shared folder

008 merged the 14 package scripts each (7 for ARM, 7 for Intel) for CP, CP PRO, & CP PROe – 42 scripts in total – down to just two! ARM & Intel are now supported by the same package, Intel synos now have working inotify support (Real-Time Backup) thanks to rwojo’s shim to pass the glibc version check, upgrade process now retains login, cache and log data (no more re-scanning), users can specify a persistent larger max heap size for very large backup sets

007 fixed a bug that broke CrashPlan if the Java folder moved (if you changed version)

006 installation now fails without User Home service enabled, fixed Daylight Saving Time support, automated replacing the ARM libffi.so symlink which is destroyed by DSM upgrades, stopped assuming the primary storage volume is /volume1, reset ownership on /var/lib/crashplan and the Friends backup location after installs and upgrades

I might be completely off base here and/or missed a vital step but does this look feasible. I know this seems like a lot of hoops to jump through but I really liked the “set it and forget it” approach of CPH before they starting breaking the updates. I had a good run for 1-2 years and am sorry to see it go.

Nicholas – I have the same issue as you currently. Can you be more specifc please when you say to replace the ‘upgrade’ directory with a file as described above. Do you mean to put a file into the upgrade directory? Whats should the filename be. Did you get that file from somewhere or is it just an empty file ?

I went ahead and took the plunge and converted my CPH to CPP and as it turns out the 4.9 software can still be downloaded.

So, I converted everything and I’m fairly certain I followed all of the instructions here. My settings all came through including backup sets and their respective chosen files/directories. However, CPP reports that there is nothing to backup.

The admin site does show that there is data.

Any ideas why my CPP client shows

Side question – I didn’t see a way to restore files from the web interface. Is that no longer possible with CPP?

Running Green Branded 4.8.3 which was working great up until the other day. It stopped working so I Uninstalled/Reinstalled/Reconfig hoping everything would be fine but it doesn’t appear that my backups are going nor am I able to connect via the client.

Looking at the logs on my NAS it appears that it’s just not able to connect to Central and keeps saying this (along with lots of other things over and over)

PG::DefaultGroup RemotePeer not allowed to connect, missing PbK

I wonder if they changed the protocol in 4.8.4 stopping anything with 4.8.3 from connecting. Heck, it won’t even upgrade.. :(

I think Crashplan Central went mad around 1/11.. When I try to connect I now see inbound connections from Central (various IPs in 216.17.8.0/24) with a source port of either 443 or 4282 but destined to random high ports… What gives? I’ve never seen that before and it just doesn’t make any sense, it’s the reverse of what should be happening! I’m trying to see if I can do some funny NATing or something, I don’t think I can though.. Hmmmm…. Might have to fire up HyperBackup to Amazon Drive sooner than I was planning… :(

Ohh! I’m back in business! I’m running an Sophos XG firewall and the rule I had in place that bypassed advanced threat prevention was moved and wasn’t functioning like it should which is why it wasn’t working.. Soo, the moral of the story is to check EVERYTHING! :)

I took the plunge as well and managed to install the docker solution described here. I had some issues though. After logging in to the GUI, I got a message about not being able to connect to the backend service (or something along those lines). This happened twice. Clicking on “Retry” seemed to help. However, the GUI is very very slow. I have a DS412+ with 4GB an I set the heap size in docker to 2048M. Is that sufficient?

Now CPP is synchronising the file information and the CPU is at 99%.

In the ui_root.log I see messages like:

2018-01-21T06:16:41.264Z – info: Retrying communication with service connect ECONNREFUSED 127.0.0.1:4244 attempt 58
2018-01-21T06:16:42.512Z – info: Unable to communicate with the service. Timeout attempting to connect to the service

I’m running the Small Business version. I moved up to that one earlier, before switching to docker. I decided to try that one when Crashplan started trying to push the version 6 (the latest, no headless version) on me.
The jlesage docker is running Crashplan ver 6.6 – which has a web UI, so no problem there.
(But I really don’t know why patters version couldn’t run with a web UI).

After the newest update from Crashplan Pro.. many things changed on the visual and on the way we manage the instances.

1) it seems that now we can make again a local backup.
2) the management of a headless (synology) it not accessible via the old way, by usual changing the .ui_info file. Anyone found a way of doing it?

So, I to have gone over to docker. it seems to being running fine. I found the instructions in the post below to be very accurate. I would say two things:

1) As indicated in the instructions be sure to create the directory before running the docker command. I didn’t and i had to delete the container and start again
mkdir -p /volume1/docker/appdata/crashplan-pr
2) As indicated later in the thread, make the change below. This will help if you ever need to do a restore. If you don’t do it before running the docker command you’ll have to delete the container and start over.
-v /volume1/:/volume1:ro portion of the docker run command to -v /volume1/:/volume1:rw

Moved to crashplan pro business as the home version was being discontinued. That part of the migration went ok and managed to get headless working with that *initially* in December 2017. It’s now stopped working because (I think) CrashPlan Pro on the Synology has updated itself to version 6.7. Doesn’t matter what UI I install on the PC – 4.9 or 6.7 (tried 32 and 64 bit options) and none of them can connect. Help !!!

So today CrashPlan pushed the CrashPlan Pro MacOS client upgrade from 4.9.0 to 6.7.0 and that instantly broke the communication with my CrashPlan server running on the Synology because they aren’t compatible. As we all know we can block the upgrade on the server side, but I was yet to see if anyone had a way to block the client side. I went into the various directory structures such as /Applications/CrashPlan.app/Contents and did a ‘touch upgrade’ and ‘chmod 444 upgrade’ as well as doing it in /Library/Application Support/CrashPlan doing the very same thing with the upgrade file hoping that will block the automatic upgrade. Does anyone else have ideas here?

I can’t use Docker on my NAS which is one of the only ones to have an Intel 32bit CPU (DS214play). I had prevented the Mac OS client from upgrading the same way as with the NAS – within the app as you pointed out. Has worked so far and my installation is still functional.
The folder path you need to create and then change the permissions for is:/Applications/CrashPlan.app/Contents/Resources/Java/upgrade

You can download the old 4.9.0 client from the CrashPlan Pro portal. If you do what I said above in both directories it seems to be not auto upgrading. I’m not sure which location requires the upgrade file block so I put them in both. Let’s just hope it stays on 4.9.0. Make sure you save the 4.9.0 client version once you grab it from the portal as they will most likely delete it soon.

Hi
Crashplan changed the auth in my installation and uses and identity file now. I have not yet discovered if I can change the port the client listen to but I manged to connect to my box using the below procedure

What did I do?

Amended my previous headless Putty SSH port forward, to be this:

Source Port 4244
Destination localhost:4244

I then installed Crashplan on my Windows 10 box and ran it once which sets up basic files you will need. Then I went into Task Manager and killed EVERY Crashplan service. You MUST do this before proceeding.

Then I:

1) On Windows – created a copy of .identity on windows

2) On the NAS – copied the contents of .identity .identity on Windows (i.e. overwrote the existing contents)

Then I made a LOCAL port forward of 4244 to localhost:4244 on the NAS. Then I fired up the Destop app on my Windows an logged in and then I could manage it.

Hi,
I’ve finally installed the docker image. Hopefully this will be more reliable!
One question, is it possible to schedule the docker image to start and stop ? I mean, I would like to make the Crashplan image start at 0:00am and stop to 3:00am so the backup occurs only during the night – this way, the docker image won’t use any memory for nothing during the day ?
Am I clear ?
Thanks

I don’t see why you couldn’t do that via a script.
However, I also don’t see that as gaining you much.
Fire up the instance.
Watch it as it pegs many resources while it comes online and reaches out to CP.
Then also notice the amount of time it takes to block sync back to CP as well.
IMO, I would just leave it run 7×24 and schedule the backups run when you want.
I don’t see much added value to killing the session each day.
Mine doesn’t use much resources once its up and running.

Of course there is some extra overhead. It’s a virtual container.
However, are you running out of ram or pegging the cpu as a result of
Running it?
If not, there is no harm.
You have the ram and cpu to use so why not put it to use.
Your choice

@Greg: You can set up a start and stop task in Task Scheduler. To do this, create a Scheduled Task -> User-defined script. User will be “root” in both cases.

To start the container the Run command will be:
#!/bin/sh \
docker start crashplan-pro

To stop the container the Run command will be:
#!/bin/sh \
docker stop crashplan-pro

This is what I do on my Synology daily since the container keeps it from going into sleep mode or whatever if it’s left running continuously. However when the Task stops the container you’ll get a System Event notification saying “Docker container: crashplan-pro stopped unexpectedly.” each time. It doesn’t actually affect the container however.

Dave, did you use the standard http/port configuration everyone has been using since the start of the container chain?
If so, you should be trying to access your container similar to this:http://nas_ip:5800
With the command line switches on the container you can tell it to do http/https or even change which port.
You can verify which port you configured by looking on the nas in the gui for the container and it would show up as “local port / Container port”

Thanks! I was sure I used the exact ports when I set this up…. in my container is says ports 4242 and 4243. Even if I try those I don’t get anything. When I try the link you provided I get my online page. I just want to be able to change items I backup or don’t backup like I did from the PC, but for some reason (I think because versions are different) I can’t do that any longer either.

Using the url I provided you should get CP central which allows you to completely manage CP from there.
From there you can decide what gets backed up and when just like local.
As long as CP central is communicating with your container CP.

Try these directions.
Docker Image Update
Synology
For owners of a Synology NAS, the following steps can be use to update a
container image.
1.Open the Docker application.
2.Click on Registry in the left pane.
3.In the search bar, type the name of the container (jlesage/docker-crashplan-pro).
4.Select the image, click Download and then choose the latest tag.
5.Wait for the download to complete. A notification will appear once done.
6.Click on Container in the left pane.
7.Select your CrashPlan PRO container.
8.Stop it by clicking Action->Stop.
9.Clear the container by clicking Action->Clear. This removes the
container while keeping its configuration.
10.Start the container again by clicking Action->Start. NOTE: The
container may temporarily disappear from the list while it is re-created.
fromhttps://hub.docker.com/r/jlesage/crashplan-pro/#synology

I finally made the decision to move to Synology Cloud c2.synology.com that is now available in US. When I deleted the crashplan app from my synology server I felt such a relief. I will do the same for my 4 friends that I got sucked into manage their servers.

I got so tired of crashplan on synology. I will not go back, even if you pay me. I just had enough. C2 is more expensive but it seems okay for my needs right now. I will also invest on a secondary local storage solution, just in case.

I selected the 1TB plan for now and this is 59.99 euro per year. I did not receive a bill yet as they give you a 30 day tree trial and I just signed up last week. I was also curious as to where my data is hosted. I will ask them this question to be clear. I assume though, as you said that they are hosted in “Europe – Frankfurt” as this is what I see on my dashboard. I said assume as it is not clear to me what the location indication on the dashboard means – it has no description, just “Europe – Frankfurt”.

So far I used their web interface to restore files and I have no complains. I will also like to try the AWS S3 backup but I have to understand out their pricing chart first.

I just migrated my account from CPH to CPSMB tonight and it looks like only version 6.7.2 of the client is available so my Synology NAS no longer works. :-/ Anyone know where I can get the 4.9.0 client? Does anyone still have the binaries who could send it to me?

Thanks – I managed to track them down by figuring out the file names and then googling for the file names. It took awhile but all worked for me. Just a heads up that it took about two weeks for my backups to show as working on the CP console, including the history showed as unavailable. For the first five days or so the backups showed completed on the client side, but the console was saying I had not backed up in 5, 6, 7, etc. days. After just shy of two weeks suddenly the console began to show the backups were happening correctly and regularly and now everything is fine other than the failed upgrade notices. Thanks to this forum for all the help.

Hi there,
Please anyone can share the setup v4.9.0 for Windows x64?
Binaries are no longer available on crashplan.
I need to reinstall the client on a fresh installation to debug a backup problem discovered since a few days.
On syno the apps start and stop after one minute.
I’ve check some logs, i’ve only one suspicious line : “Reason for stopping backup: Full filesystem scan started.” ok, but ? 😦
For information, I use crashplan without problem now since 3 years (with a swtich home to pro of course sucessfully)
Thanks for the setup client for Windows 🙂
And if you have an idea regarding this error, I’ll take it 🙂
Kreg

Seems that CrashPlan is not going to be a long term solution for us, given that we’re hacking the ability to not let the software update. Has anyone tried Synology’s Hyper Backup to replace using CrashPlan? Seems that it’s nice and integrated. Thoughts?