ajkerrigan / crashplan-docker-synology Goto Github PK

Run a headless CrashPlan instance on a Synology device with Docker

License: MIT License

Shell 100.00%

crashplan-docker-synology's Introduction

crashplan-docker-synology

Update: The End of CrashPlan for Home

As of 2017-August-22, Code42 no longer offers CrashPlan for Home. Existing subscriptions will be honored through October of 2018 (see this announcement for more information).

Running CrashPlan from a NAS has always been a neglected use case from a support perspective, so this move isn't all that surprising. Still, this leaves a question for those of us currently relying on CrashPlan for Home... what do we do instead?

Like many of you, I'll be revisiting other backup options that I previously rejected and many new ones that have arisen over the past few years.

FernandoMiguel has created an excellent sheet comparing various cloud backup/storage offerings. I hope that it is useful to the rest of you who are planning your migrations.

Overview

This is an attempt to get CrashPlan running on a Synology NAS inside a Docker container. It has been tested successfully in the following configurations:

DSM Version: 6.0-7321

Device	RAM
Synology DS713+	4GB
Synology DS412+	2GB

I have been running the PC Load Letter CrashPlan Packages for a long time. They certainly made it much easier to deal with CrashPlan updates, but it was still fairly common for me to have issues after new releases. When I had issues with the 4.4.1 release, I decided to see if Docker would be a smoother way forward.

Assumptions and Precautions

This documentation assumes that:

You have a CrashPlan account, a Synology device and some experience using them together
Your Synology device supports Docker (check compatibility here)
You are comfortable connecting to your Synology device using SSH and running terminal commands
Docker experience shouldn't be necessary, but can't hurt :)

Before trying to run CrashPlan in a Docker container, it's a good idea to:

Back up your CrashPlan configuration files related to any currently installed instances of CrashPlan, in case you decide to switch back to your previous setup
Stop or uninstall existing CrashPlan instances

Installation

Install the Docker package via the DSM Package Manager
Stop any existing CrashPlan instances
SSH to your Synology NAS
Clone this repository to /root
- Note: If you don't have git installed, install the ipkg package manager and install it.
- ipkg install help here
Symbolically link the start up script
- ln -s /root/crashplan-docker-synology/S99crashplandocker.sh /usr/local/etc/rc.d/S99crashplandocker.sh
Review the predefined variables in the S99crashplandocker.sh script. If you have different locations for your installation, you will need to update the variables.
- Copy the user variables file to /root
  - cp /root/crashplan-docker-synology/cp-user-vars.sh /root
- Edit /root/cp-user-vars.sh
- Save the file
Run /usr/local/etc/rc.d/S99crashplandocker.sh start to start the container.
Wait 10-20 seconds
Run /usr/local/etc/rc.d/S99crashplandocker.sh status to see the running state of the container
- This command also shows the authorization token required for accessing the CrashPlan UI from a remote computer
Connect to the headless service using CrashPlan Desktop on a remote computer.
- See CrashPlan's documentation for help with this, and consult /usr/local/etc/rc.d/S99crashplandocker.sh status for details about the running CrashPlan instance.

Upgrading

The CrashPlan service running in your Docker container will update itself automatically. However, follow the steps below to make sure the Docker image is up to date.

To check for updates to the Docker image, run docker pull ajkerrigan/crashplan
If the image was updated, run /usr/local/etc/rc.d/S99crashplandocker.sh recreate to create and start a container based on the new image.
Note: It's a good idea to run the steps above after upgrading DSM (for example, after moving from DSM 5.2 to 6.0).

Customization

This script can be customized to suit your specific needs. Customization is done within the cp-user-vars.sh file which should be located in /root. The options most likely to need tweaking are:

USER_VOLUMES: The -v options passed to the docker run command. These control the paths that will be mounted inside the container.
CRASHPLAN_DIR: The CrashPlan home/installation directory. When switching from an existing install of CrashPlan, pointing this variable to your current installation may avoid the need to "adopt" the previous installation from the CrashPlan client.
DATA_DIR: The destination for incoming backups. Setting this to a data directory from an existing installation will save some time synchronizing backup progress.

Caveats

Because this script sets up mounted volumes that are not accessible from the DSM GUI, trying to manage this container from the Synology Docker GUI will break it. Checking status and resource utilization with the GUI is fine, but trying to start the container from the GUI will break the volume configuration. If that happens, remove the container and run /usr/local/etc/rc.d/S99crashplandocker.sh start again to set it up anew.
Anytime the container stops and restarts, it's going to overwrite the .ui_info file. That file contains an authentication token GUID that needs to be the same on the CrashPlan Desktop client and the server. Before trying to start your CrashPlan client, run /usr/local/etc/rc.d/S99crashplandocker.sh status and take note of the Auth Token. Use that to update the .ui_info file on your client machine. See CrashPlan's documentation for headless computers for more information.

Acknowledgements

gfjardim's Docker Image for CrashPlan (https://hub.docker.com/r/gfjardim/crashplan/) was an excellent starting point. I forked it into the ajkerrigan/crashplan image with the expectation that I'd tweak things as I went along.
patters over at PC Load Letter is a damn hero. He has been wrestling with getting CrashPlan to work on Synology devices for years, and has done a lot of work so that people like me could be lazier. He accepts donations, and damn well deserves them. His CrashPlan packages are the only reason I haven't given up running CrashPlan on my NAS by now.
Scott Hanselman's blog post is an excellent walkthrough of getting CrashPlan installed and running. His post is very readable and supported by plenty of screenshots.

Troubleshooting

Running CrashPlan on a Synology device has always been a quirky endeavor. I believe Docker removes some of the wonkiness, but I'm sure there are issues I haven't run into yet. I am not an expert on this stuff, but I've broken and fixed enough CrashPlan installations that I'm familiar with some of the ways things break. If you have issues you can't fix on your own, please open an issue in GitHub and I'll try to help.

Contributing

Do you have suggestions for how this script can be better written or better documented? Please open an issue, or fix it yourself and submit a pull request.

Additional Resources

PC Load Letter's CrashPlan packages. If you're not using Docker, use those packages.
Docker Hub pages for the ajkerrigan/crashplan image, or the gfjardim/crashplan image it was based on.
gfjardim's docker-containers GitHub repository.
CrashPlan Headless documentation.

crashplan-docker-synology's People

Contributors

Stargazers

Watchers

Forkers

gitter-badger pjmeyer brettveenstra rivy

crashplan-docker-synology's Issues

/usr/local/etc/crashplan: no such file or directory on START

First off: thanks for a great package!

I'm trying to install per Wiki instructions after a fresh install of DSM and Docker.

When starting the container via terminal, I'm getting seeing this:

/usr/local/etc/rc.d/S99crashplandocker.sh start
Found the user variables file. Updating...
CRASHPLAN_DIR=/usr/local/etc/crashplan
DATA_DIR=/volume1/CrashPlanBackups
USER_VOLUMES=-v /volume1:/volume1:ro
No existing CrashPlan container found. Running image "ajkerrigan/crashplan".
Unable to find image 'ajkerrigan/crashplan:latest' locally
latest: Pulling from ajkerrigan/crashplan
f069f1d21059: Pull complete
ecbeec5633cf: Pull complete
ea6f18256d63: Pull complete
54bde7b02897: Pull complete
a3ed95caeb02: Pull complete
ce9e695a6234: Pull complete
346026b9659b: Pull complete
d900dbe16dec: Pull complete
c599eff79b5a: Pull complete
Digest: sha256:cc665edccff63933b6bbdf765a6ea14236908ef28c941c9ff45d31e83e40935e
Status: Downloaded newer image for ajkerrigan/crashplan:latest
73f3ca6ad9972962036bfd21094e9a21490602c0e73be431fa4b9abc00a61656
/var/packages/Docker/target/usr/bin/docker: Error response from daemon: stat /usr/local/etc/crashplan: no such file or directory.

My version info:

DSM: 6.1-15047
Docker: 1.11.2, build bf60a63-synology

Looking through issue #9, it gives me hope there is a solution for this but not sure this is the same issue in play. Any suggestions?

No auth token in /config/id/.ui_info

Hi, thanks to your great documentation I managed to install, configure, and start the crashplan container. Unfortunately I do not manage to connect from my CrashPlan UI. Appears there is no authentication token in /config/id/.ui_info:

# cat /config/id/.ui_info
gets me
4243,unRAID

I expected the format to be:
4243,<token>,<localhost>

Any ideas how to fix this / how to connect from the UI?

BTW, I also noticed that the log files in /config/log are not being updated, despite the JAVA process being active. Should I look for logs at another location?

Many thanks!

Don't recommend storing files in /root

I had my git repo and cp-user-vars.sh in /root as recommended by the readme and just lost them after a DSM upgrade. Apparently DSM upgrades wipe /root.

Make use of the Wiki for documentation

I think the README has a lot of important information, but as bits have been added it's starting to get a bit unwieldy. It should probably be broken up, perhaps into a series of Wiki entries.

IP Address of container is not reachable from the LAN computers

Thank you for your work!
I'm hopeful this is more supportable vs the Patters synology packages that break monthly.

When I run the docker instance on my DS412+, it works great and can reach the CrashPlan online backup servers. The IP address of the docker instance is 172.17.0.1 (gateway: 172.17.42.1) and my lan subnet is 192.168.115.x. When the docker crash plan instance reports its info to the crash plan cloud, the 172 address is replicated to my LAN clients. This results is the LAN clients are not able to reach the docker instance.

Can I modify the docker network settings so that the docker container DHCPs on my network and treats the docker infrastructure as a bridge?

Make deployment smoother

The "install" process at this point is some combination of cloning the git repo and then copying and/or symlinking files. That is probably not intimidating to anyone who is in the position to need a script like this in the first place, but it does feel a bit clunky. Since we have the luxury of a somewhat predictable environment, it may be worth having a light install script that does the initial symlinking in one shot.

In that case, it may make sense to "install" cp-user-vars.sh by default, with commented out path variables set to the same values as the script defaults. Customization would then be a matter of uncommenting and tweaking lines in that file.

Synology md0 is running out of space

The Docker-image is running smoothly on my DS412+, thanks for the fine work!

I tried to install the latest update. Unfortunately it failed due to a lack of space on the system volume md0.
So I used the command:
/usr/bin/du -h -d 2 -x /usr/local/etc/
which gave me the information that crashplan is using ca. 1g of space:
12K /usr/local/etc/crashplan/id
761M /usr/local/etc/crashplan/cache
294M /usr/local/etc/crashplan/log
80K /usr/local/etc/crashplan/conf
20K /usr/local/etc/crashplan/bin
1.1G /usr/local/etc/crashplan

Wouldn't it be a good idea to move this directory to /volume1 e.g. /volume1/crashplan/?
This volume is much bigger and will not interfere with any DSM-updates.

Container does not start after reboot

I applied the latest DSM upgrade a few days ago and thought that the container worked fine since I am using the latest version of this script. But after 3 days I got the email from Crashplan saying that my client had not been connected for 3 days.

So today when I looked closer I noticed that the Crashplan container had not mounted any of the user specified volumes. So I then recreated the container and when I checked again they were mounted properly.

So as one more step I wanted to reboot the Synology to check if the container started properly. But it did not start at all.

The following is logged in syslog of the Synology:

Apr 25 09:05:10 diskstation synoddsm-hostd_SYNO.Docker.Container_1_list[12808]: synoProfile.cpp:285 Profile /var/packages/Docker/etc/.config not exist
Apr 25 09:05:10 diskstation synoddsm-hostd_SYNO.Docker.Container_1_list[12808]: synoProfile.cpp:285 Profile /var/packages/Docker/etc/.config not exist
Apr 25 09:05:11 diskstation synoddsm-hostd_SYNO.Docker.Container_1_list: SYSTEM:        Last message 'synoProfile.cpp:285 ' repeated 1 times, suppressed by syslog-ng on diskstation
Apr 25 09:05:11 diskstation synoddsm-hostd[12808]: util.cpp:105 SharePathGetByName failed, name = []
Apr 25 09:05:11 diskstation synoddsm-hostd[12808]: util.cpp:105 SharePathGetByName failed, name = [adoring_banach]
Apr 25 09:05:11 diskstation synoddsm-hostd[12808]: util.cpp:105 SharePathGetByName failed, name = [crashplan]
Apr 25 09:05:11 diskstation synoddsm-hostd[12808]: util.cpp:105 SharePathGetByName failed, name = [crashplan]
Apr 25 09:05:11 diskstation synoddsm-hostd: SYSTEM:     Last message 'util.cpp:105 SharePa' repeated 1 times, suppressed by syslog-ng on diskstation
Apr 25 09:05:11 diskstation synoddsm-hostd[12808]: util.cpp:105 SharePathGetByName failed, name = [trusty-crashplan]
Apr 25 09:05:11 diskstation synoddsm-hostd[12808]: util.cpp:105 SharePathGetByName failed, name = []
Apr 25 09:05:11 diskstation synoddsm-hostd[12808]: util.cpp:105 SharePathGetByName failed, name = [adoring_banach]
Apr 25 09:05:11 diskstation synoddsm-hostd[12808]: util.cpp:105 SharePathGetByName failed, name = [crashplan]
Apr 25 09:05:11 diskstation synoddsm-hostd[12808]: util.cpp:105 SharePathGetByName failed, name = [crashplan]
Apr 25 09:05:11 diskstation synoddsm-hostd: SYSTEM:     Last message 'util.cpp:105 SharePa' repeated 1 times, suppressed by syslog-ng on diskstation
Apr 25 09:05:11 diskstation synoddsm-hostd[12808]: util.cpp:105 SharePathGetByName failed, name = [trusty-crashplan]
Apr 25 09:05:14 diskstation root: == DSM 6.0 7321-2 finished boot up ==

If I manually execute /usr/local/etc/rc.d/S99crashplandocker.sh status it starts properly.

Any hints on what goes wrong and where to start looking?

/usr/local/etc/rc.d/S99crashplandocker.sh: line 41: docker: command not found

Change the startup script to reference the full path to the docker binary.