UPDATE – The instructions and notes on this page apply to all three versions of the package hosted on my repo: CrashPlan, CrashPlan PRO, and CrashPlan PROe.
CrashPlan is a popular online backup solution which supports continuous syncing. With this your NAS can become even more resilient – it could even get stolen or destroyed and you would still have your data. Whilst you can pay a small monthly charge for a storage allocation in the Cloud, one neat feature CrashPlan offers is for individuals to collaboratively backup their important data to each other – for free! You could install CrashPlan on your laptop and have it continuously protecting your documents to your NAS, even whilst away from home.

CrashPlan is a Java application, and one that’s typically difficult to install on a NAS – therefore an obvious candidate for me to simplify into a package, given that I’ve made a few others. I tried and failed a few months ago, getting stuck at compiling the Jtux library for ARM CPUs (the Oracle Java for Embedded doesn’t come with any headers).
I noticed a few CrashPlan setup guides linking to my Java package, and decided to try again based on these: Kenneth Larsen’s blog post, the Vincesoft blog article for installing on ARM processor Iomega NAS units, and this handy PDF document which is a digest of all of them, complete with download links for the additional compiled ARM libraries. I used the PowerPC binaries Christophe had compiled on his chreggy.fr blog, so thanks go to him. I wanted make sure the package didn’t require the NAS to be bootstrapped, so I picked out the few generic binaries that were needed (bash, nice and cpio) directly from the Optware repo.
Aside from the challenges of getting the library dependencies fixed for ARM and QorIQ PowerPC systems, there was also the matter of compliance – Code 42 Software’s EULA prohibits redistribution of their work. I had to make the syno package download CrashPlan for Linux (after the end user agrees their EULA), then I had to write my own script to extract this archive and mimic their installer, since their installer is interactive. It took a lot of slow testing, but I managed it!

My most recent package version introduces handling of the automatic updates which Code 42 sometimes publish to the clients. This has proved to be quite a challenge to get working as testing was very laborious. I can confirm that it worked with the update from CrashPlan PRO 3.2 to 3.2.1 , and from CrashPlan 3.2.1 to 3.4.1:

Installation
- This package is for Marvell Kirkwood, Marvell Armada 370, Intel and Freescale QorIQ PowerPC CPUs only, so please check which CPU your NAS has. It will work on an unmodified NAS, no hacking or bootstrapping required. It won’t work on older PowerQUICC PowerPC models owing to difficulties getting Java working. It is possible to run CrashPlan on those, but it requires chroot-ing to a Debian install. Christophe from chreggy.fr has recently released packages to automate this.
- In the User Control Panel in DSM, enable the User Homes service.
- Install the package directly from Package Center in DSM. In Settings -> Package Sources add my package repository URL which is
http://packages.pcloadletter.co.uk
. - You will need to install either one of my Java SE for Embedded packages first (Java 6 or 7). Read the instructions on that page carefully too.
- If you previously installed CrashPlan manually using the Synology Wiki, you can find uninstall instructions here.
Notes
- The package downloads the CrashPlan installer directly from Code 42 Software, following acceptance of their EULA. I am complying with their wish that no one redistributes it.
- CrashPlan is installed in headless mode – backup engine only. This is configured by a desktop client, but operates independently of 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 very large backup sets by editing /volume1/@appstore/CrashPlan/syno_package.vars. If you’re 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 Intel models which come with 1GB RAM and can be upgraded to 3GB very cheaply. RAM is very limited on the ARM ones. 128MB RAM on the J series means CrashPlan is running with only one fifth of the recommended heap size, so I doubt it’s viable for backing up very much at all. My DS111 has 256MB of RAM and currently backs up around 60GB with no issues. I have found that a 512MB heap was insufficient to back up more than 2TB of files on a Windows server. It kept restarting the backup engine every few minutes until I increased the heap to 1024MB.
- As with my other syno packages, the daemon user account password is randomized when it is created using the openssl binary. DSM Package Center runs as the root user so my script starts the package using an su command. This means that you can change the password yourself and CrashPlan will still work.
- The default location for saving friends’ backups is set to /volume1/crashplan/backupArchives (where /volume1 is you primary storage volume) to eliminate the chance of them being destroyed accidentally by uninstalling the package.
- The first time you run the server you will need to stop it and restart it before you can connect the client. This is because a config file that’s 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.
- Once the engine is running, you can manage it by installing CrashPlan on another computer, and editing the file conf/ui.properties on that computer so that this line:
#serviceHost=127.0.0.1
is uncommented (by removing the hash symbol) and set to the IP address of your NAS, e.g.:
serviceHost=192.168.1.210
On Windows you can also disable the CrashPlan service if you will only use the client. - 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’re trying to troubleshoot an issue you will need to use an SSH session to inspect the two engine log files which are:
/volume1/@appstore/CrashPlan/log/engine_output.log
/volume1/@appstore/CrashPlan/log/engine_error.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). You will need to wait several minutes in the event of this happening before you take action, because the update script tries to restart CrashPlan 10 times at 10 second intervals. After this, you simply start the package again in Package Center and my scripts will fix the update, then run it. One final package restart is required before you can connect with the CrashPlan Desktop client (remember to update that too).
- After their backup is seeded some users may wish to schedule the CrashPlan engine using cron so that it only runs at certain times. This is particularly useful on ARM systems because CrashPlan currently prevents hibernation while it is running (unresolved issue, reported to Code 42). To schedule, edit /etc/crontab and add the following entries for starting and stopping CrashPlan:
55 2 * * * root /var/packages/CrashPlan/scripts/start-stop-status start
0 4 * * * root /var/packages/CrashPlan/scripts/start-stop-status stop
This example would configure CrashPlan to run daily between 02:55 and 04:00am. CrashPlan by default will scan the whole backup selection for changes at 3:00am so this is ideal. The simplest way to edit crontab if you’re not really confident with Linux is to install Merty’s Config File Editor package, which requires the official Synology Perl package to be installed too (since DSM 4.2). After editing crontab you will need to restart the cron daemon for the changes to take effect:
/usr/syno/etc.defaults/rc.d/S04crond.sh stop
/usr/syno/etc.defaults/rc.d/S04crond.sh start
It is vitally important that you do not improvise your own startup commands or use a different account because this will most likely break the permissions on the config files, causing additional problems. The package scripts are designed to be run as root, and they will in turn invoke the CrashPlan engine using its own dedicated user account. - If you update DSM later, you will need to re-install the Java package or else UTF-8 and locale support will be broken by the update.
- If you decide to sign up for one of CrashPlan’s paid backup services as a result of my work on this, I would really appreciate it if you could use this affiliate link, or consider donating using the PayPal button on the right.
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 Package wiki.
installer.sh
#!/bin/sh
#--------CRASHPLAN installer script
#--------package maintained at pcloadletter.co.uk
DOWNLOAD_PATH="http://download.crashplan.com/installs/linux/install/${SYNOPKG_PKGNAME}"
[ "${SYNOPKG_PKGNAME}" == "CrashPlan" ] && DOWNLOAD_FILE="CrashPlan_3.5.3_Linux.tgz"
[ "${SYNOPKG_PKGNAME}" == "CrashPlanPRO" ] && DOWNLOAD_FILE="CrashPlanPRO_3.5.3_Linux.tgz"
[ "${SYNOPKG_PKGNAME}" == "CrashPlanPROe" ] && DOWNLOAD_FILE="CrashPlanPROe_3.5.3_Linux.tgz"
DOWNLOAD_URL="${DOWNLOAD_PATH}/${DOWNLOAD_FILE}"
CPI_FILE="${SYNOPKG_PKGNAME}_*.cpi"
EXTRACTED_FOLDER="${SYNOPKG_PKGNAME}-install"
DAEMON_USER="`echo ${SYNOPKG_PKGNAME} | awk {'print tolower($_)'}`"
DAEMON_PASS="`openssl rand 12 -base64 2>/dev/null`"
DAEMON_ID="${SYNOPKG_PKGNAME} daemon user"
DAEMON_HOME="/var/services/homes/${DAEMON_USER}"
OPTDIR="${SYNOPKG_PKGDEST}"
VARS_FILE="${OPTDIR}/install.vars"
ENGINE_SCRIPT="CrashPlanEngine"
SYNO_CPU_ARCH="`uname -m`"
NATIVE_BINS_URL="http://packages.pcloadletter.co.uk/downloads/crashplan-native-${SYNO_CPU_ARCH}.tgz"
NATIVE_BINS_FILE="`echo ${NATIVE_BINS_URL} | sed -r "s%^.*/(.*)%\1%"`"
INSTALL_FILES="${DOWNLOAD_URL} ${NATIVE_BINS_URL}"
TEMP_FOLDER="`find / -maxdepth 2 -name '@tmp' | head -n 1`"
#the Manifest folder is where friends' backup data is stored
#we set it outside the app folder so it persists after a package uninstall
MANIFEST_FOLDER="/`echo $TEMP_FOLDER | cut -f2 -d'/'`/crashplan"
LOG_FILE="${SYNOPKG_PKGDEST}/log/history.log.0"
UPGRADE_FILES="syno_package.vars conf/my.service.xml conf/service.login conf/service.model"
UPGRADE_FOLDERS="log cache"
source /etc/profile
PUBLIC_FOLDER="`cat /usr/syno/etc/smb.conf | sed -r '/\/public$/!d;s/^.*path=(\/volume[0-9]{1,4}\/public).*$/\1/'`"
preinst ()
{
if [ -z ${PUBLIC_FOLDER} ]; then
echo "A shared folder called 'public' could not be found - note this name is case-sensitive. "
echo "Please create this using the Shared Folder DSM Control Panel and try again."
exit 1
fi
if [ -z ${JAVA_HOME} ]; then
echo "Java is not installed or not properly configured. JAVA_HOME is not defined. "
echo "Download and install the Java Synology package from http://wp.me/pVshC-z5"
exit 1
fi
if [ ! -f ${JAVA_HOME}/bin/java ]; then
echo "Java is not installed or not properly configured. The Java binary could not be located. "
echo "Download and install the Java Synology package from http://wp.me/pVshC-z5"
exit 1
fi
#is the User Home service enabled?
UH_SERVICE=maybe
synouser --add userhometest Testing123 "User Home test user" 0 "" ""
UHT_HOMEDIR=`cat /etc/passwd | sed -r '/User Home test user/!d;s/^.*:User Home test user:(.*):.*$/\1/'`
if echo $UHT_HOMEDIR | grep '/var/services/homes/' > /dev/null; then
if [ ! -d $UHT_HOMEDIR ]; then
UH_SERVICE=false
fi
fi
synouser --del userhometest
#remove home directory (needed since DSM 4.1)
[ -e /var/services/homes/userhometest ] && rm -r /var/services/homes/userhometest
if [ "${UH_SERVICE}" == "false" ]; then
echo "The User Home service is not enabled. Please enable this feature in the User control panel in DSM."
exit 1
fi
cd ${TEMP_FOLDER}
for WGET_URL in ${INSTALL_FILES}
do
WGET_FILENAME="`echo ${WGET_URL} | sed -r "s%^.*/(.*)%\1%"`"
[ -f ${TEMP_FOLDER}/${WGET_FILENAME} ] && rm ${TEMP_FOLDER}/${WGET_FILENAME}
wget ${WGET_URL}
if [[ $? != 0 ]]; then
if [ -d ${PUBLIC_FOLDER} ] && [ -f ${PUBLIC_FOLDER}/${WGET_FILENAME} ]; then
cp ${PUBLIC_FOLDER}/${WGET_FILENAME} ${TEMP_FOLDER}
else
echo "There was a problem downloading ${WGET_FILENAME} from the official download link, "
echo "which was \"${WGET_URL}\" "
echo "Alternatively, you may download this file manually and place it in the 'public' shared folder. "
exit 1
fi
fi
done
exit 0
}
postinst ()
{
#create daemon user
synouser --add ${DAEMON_USER} ${DAEMON_PASS} "${DAEMON_ID}" 0 "" ""
#save the daemon user's homedir as variable in that user's profile
#this is needed because new users seem to inherit a HOME value of /root which they have no permissions for.
su - ${DAEMON_USER} -s /bin/sh -c "echo export HOME=\'${DAEMON_HOME}\' >> .profile"
#extract CPU-specific additional binaries
mkdir ${SYNOPKG_PKGDEST}/bin
cd ${SYNOPKG_PKGDEST}/bin
tar xzf ${TEMP_FOLDER}/${NATIVE_BINS_FILE} && rm ${TEMP_FOLDER}/${NATIVE_BINS_FILE}
#extract main archive
cd ${TEMP_FOLDER}
tar xzf ${TEMP_FOLDER}/${DOWNLOAD_FILE} && rm ${TEMP_FOLDER}/${DOWNLOAD_FILE}
#extract cpio archive
cd ${SYNOPKG_PKGDEST}
cat "${TEMP_FOLDER}/${EXTRACTED_FOLDER}"/${CPI_FILE} | gzip -d -c | ${SYNOPKG_PKGDEST}/bin/cpio -i --no-preserve-owner
echo "#uncomment to expand Java max heap size beyond prescribed value (will survive upgrades)" > ${SYNOPKG_PKGDEST}/syno_package.vars
echo "#you probably only want more than the recommended 512M if you're backing up extremely large volumes of files" >> ${SYNOPKG_PKGDEST}/syno_package.vars
echo "#USR_MAX_HEAP=512M" >> ${SYNOPKG_PKGDEST}/syno_package.vars
echo >> ${SYNOPKG_PKGDEST}/syno_package.vars
#the following Package Center variables will need retrieving if launching CrashPlan via cron
echo "CRON_SYNOPKG_PKGNAME='${SYNOPKG_PKGNAME}'" >> ${SYNOPKG_PKGDEST}/syno_package.vars
echo "CRON_SYNOPKG_PKGDEST='${SYNOPKG_PKGDEST}'" >> ${SYNOPKG_PKGDEST}/syno_package.vars
cp ${TEMP_FOLDER}/${EXTRACTED_FOLDER}/scripts/${ENGINE_SCRIPT} ${OPTDIR}/bin
cp ${TEMP_FOLDER}/${EXTRACTED_FOLDER}/scripts/run.conf ${OPTDIR}/bin
mkdir -p ${MANIFEST_FOLDER}/backupArchives
chown -R ${DAEMON_USER} ${MANIFEST_FOLDER}
#save install variables which Crashplan expects its own installer script to create
echo TARGETDIR=${SYNOPKG_PKGDEST} > ${VARS_FILE}
echo BINSDIR=/bin >> ${VARS_FILE}
echo MANIFESTDIR=${MANIFEST_FOLDER}/backupArchives >> ${VARS_FILE}
#leave these ones out which should help upgrades from Code42 to work (based on examining an upgrade script)
#echo INITDIR=/etc/init.d >> ${VARS_FILE}
#echo RUNLVLDIR=/usr/syno/etc/rc.d >> ${VARS_FILE}
echo INSTALLDATE=`date +%Y%m%d` >> ${VARS_FILE}
echo JAVACOMMON=\${JAVA_HOME}/bin/java >> ${VARS_FILE}
cat ${TEMP_FOLDER}/${EXTRACTED_FOLDER}/install.defaults >> ${VARS_FILE}
#remove temp files
rm -r ${TEMP_FOLDER}/${EXTRACTED_FOLDER}
#change owner of CrashPlan folder tree
chown -R ${DAEMON_USER} ${SYNOPKG_PKGDEST}
exit 0
}
preuninst ()
{
#make sure engine is stopped
su - ${DAEMON_USER} -s /bin/sh -c "${OPTDIR}/bin/${ENGINE_SCRIPT} stop"
sleep 2
exit 0
}
postuninst ()
{
if [ -f ${SYNOPKG_PKGDEST}/syno_package.vars ]; then
source ${SYNOPKG_PKGDEST}/syno_package.vars
fi
if [ "${LIBFFI_SYMLINK}" == "YES" ]; then
rm /lib/libffi.so.5
fi
#if it doesn't exist, but is still a link then it's a broken link and should also be deleted
if [ ! -e /lib/libffi.so.5 ]; then
[ -L /lib/libffi.so.5 ] && rm /lib/libffi.so.5
fi
#remove daemon user
synouser --del ${DAEMON_USER}
#remove daemon user's home directory (needed since DSM 4.1)
[ -e /var/services/homes/${DAEMON_USER} ] && rm -r /var/services/homes/${DAEMON_USER}
exit 0
}
preupgrade ()
{
#make sure engine is stopped
su - ${DAEMON_USER} -s /bin/sh -c "${OPTDIR}/bin/${ENGINE_SCRIPT} stop"
sleep 2
#if identity and config data exists back it up
if [ -d ${DAEMON_HOME}/.crashplan ]; then
mkdir -p ${SYNOPKG_PKGDEST}/../${DAEMON_USER}_data_mig/conf
mv ${DAEMON_HOME}/.crashplan ${SYNOPKG_PKGDEST}/../${DAEMON_USER}_data_mig
for FILE_TO_MIGRATE in ${UPGRADE_FILES}; do
if [ -f ${OPTDIR}/${FILE_TO_MIGRATE} ]; then
cp ${OPTDIR}/${FILE_TO_MIGRATE} ${SYNOPKG_PKGDEST}/../${DAEMON_USER}_data_mig/${FILE_TO_MIGRATE}
fi
done
for FOLDER_TO_MIGRATE in ${UPGRADE_FOLDERS}; do
if [ -d ${OPTDIR}/${FOLDER_TO_MIGRATE} ]; then
mv ${OPTDIR}/${FOLDER_TO_MIGRATE} ${SYNOPKG_PKGDEST}/../${DAEMON_USER}_data_mig
fi
done
fi
exit 0
}
postupgrade ()
{
#use the migrated identity and config data from the previous version
if [ -d ${SYNOPKG_PKGDEST}/../${DAEMON_USER}_data_mig/.crashplan ]; then
mv ${SYNOPKG_PKGDEST}/../${DAEMON_USER}_data_mig/.crashplan ${DAEMON_HOME}
for FILE_TO_MIGRATE in ${UPGRADE_FILES}; do
if [ -f ${SYNOPKG_PKGDEST}/../${DAEMON_USER}_data_mig/${FILE_TO_MIGRATE} ]; then
mv ${SYNOPKG_PKGDEST}/../${DAEMON_USER}_data_mig/${FILE_TO_MIGRATE} ${OPTDIR}/${FILE_TO_MIGRATE}
fi
done
for FOLDER_TO_MIGRATE in ${UPGRADE_FOLDERS}; do
if [ -d ${SYNOPKG_PKGDEST}/../${DAEMON_USER}_data_mig/${FOLDER_TO_MIGRATE} ]; then
mv ${SYNOPKG_PKGDEST}/../${DAEMON_USER}_data_mig/${FOLDER_TO_MIGRATE} ${OPTDIR}
fi
done
rmdir ${SYNOPKG_PKGDEST}/../${DAEMON_USER}_data_mig/conf
rmdir ${SYNOPKG_PKGDEST}/../${DAEMON_USER}_data_mig
#make CrashPlan log entry
TIMESTAMP="`date +%D` `date +%I:%M%p`"
echo "I ${TIMESTAMP} Synology Package Center updated ${SYNOPKG_PKGNAME} to version ${SYNOPKG_PKGVER}" >> ${LOG_FILE}
#daemon user has been deleted and recreated so we need to reset ownership (new UID)
chown -R ${DAEMON_USER} ${DAEMON_HOME}/.crashplan
chown -R ${DAEMON_USER} ${SYNOPKG_PKGDEST}
#read manifest location from the migrated XML config, and reset ownership on that path too
if [ -f ${SYNOPKG_PKGDEST}/conf/my.service.xml ]; then
MANIFEST_FOLDER=`cat ${SYNOPKG_PKGDEST}/conf/my.service.xml | grep "<manifestPath>" | cut -f2 -d'>' | cut -f1 -d'<'`
chown -R ${DAEMON_USER} ${MANIFEST_FOLDER}
fi
#the following Package Center variables will need retrieving if launching CrashPlan via cron
grep "^CRON_SYNOPKG_PKGNAME" ${SYNOPKG_PKGDEST}/syno_package.vars > /dev/null \
|| echo "CRON_SYNOPKG_PKGNAME='${SYNOPKG_PKGNAME}'" >> ${SYNOPKG_PKGDEST}/syno_package.vars
grep "^CRON_SYNOPKG_PKGDEST" ${SYNOPKG_PKGDEST}/syno_package.vars > /dev/null \
|| echo "CRON_SYNOPKG_PKGDEST='${SYNOPKG_PKGDEST}'" >> ${SYNOPKG_PKGDEST}/syno_package.vars
fi
exit 0
}
start-stop-status.sh
#!/bin/sh
#--------CRASHPLAN start-stop-status script
#--------package maintained at pcloadletter.co.uk
if [ "${SYNOPKG_PKGNAME}" == "" ]; then
#if this script has been invoked by cron then some Package Center vars are undefined
source "`dirname $0`/../target/syno_package.vars"
SYNOPKG_PKGNAME="${CRON_SYNOPKG_PKGNAME}"
SYNOPKG_PKGDEST="${CRON_SYNOPKG_PKGDEST}"
CRON_LAUNCHED=True
fi
#Main variables section
DAEMON_USER="`echo ${SYNOPKG_PKGNAME} | awk {'print tolower($_)'}`"
DAEMON_HOME="/var/services/homes/${DAEMON_USER}"
OPTDIR="${SYNOPKG_PKGDEST}"
TEMP_FOLDER="`find / -maxdepth 2 -name '@tmp' | head -n 1`"
MANIFEST_FOLDER="/`echo $TEMP_FOLDER | cut -f2 -d'/'`/crashplan"
LOG_FILE="${SYNOPKG_PKGDEST}/log/history.log.0"
ENGINE_SCRIPT="CrashPlanEngine"
APP_NAME="CrashPlanService"
SCRIPTS_TO_EDIT="${ENGINE_SCRIPT}"
ENGINE_CFG="run.conf"
LIBFFI_SO_NAMES="5 6" #armada370 build of libjnidispatch.so is newer, and uses libffi.so.6
CFG_PARAM="SRV_JAVA_OPTS"
source ${OPTDIR}/install.vars
JAVA_MIN_HEAP=`grep "^${CFG_PARAM}=" "${OPTDIR}/bin/${ENGINE_CFG}" | sed -r "s/^.*-Xms([0-9]+)[Mm] .*$/\1/"`
SYNO_CPU_ARCH="`uname -m`"
case $1 in
start)
#set the current timezone for Java so that log timestamps are accurate
#we need to use the modern timezone names so that Java can figure out DST
SYNO_TZ=`cat /etc/synoinfo.conf | grep timezone | cut -f2 -d'"'`
SYNO_TZ=`grep "^${SYNO_TZ}" /usr/share/zoneinfo/Timezone/tzname | sed -e "s/^.*= //"`
grep "^export TZ" ${DAEMON_HOME}/.profile > /dev/null \
&& sed -i "s%^export TZ=.*$%export TZ='${SYNO_TZ}'%" ${DAEMON_HOME}/.profile \
|| echo export TZ=\'${SYNO_TZ}\' >> ${DAEMON_HOME}/.profile
#this package stores the machine identity in the daemon user home directory
#so we need to remove any old config data from previous manual installations or startups
[ -d /var/lib/crashplan ] && rm -r /var/lib/crashplan
#check persistent variables from syno_package.vars
USR_MAX_HEAP=0
if [ -f ${SYNOPKG_PKGDEST}/syno_package.vars ]; then
source ${SYNOPKG_PKGDEST}/syno_package.vars
fi
USR_MAX_HEAP=`echo $USR_MAX_HEAP | sed -e "s/[mM]//"`
#create or repair libffi symlink if a DSM upgrade has removed it
for FFI_VER in ${LIBFFI_SO_NAMES}; do
if [ -e ${OPTDIR}/lib/libffi.so.${FFI_VER} ]; then
if [ ! -e /lib/libffi.so.${FFI_VER} ]; then
#if it doesn't exist, but is still a link then it's a broken link and should be deleted
[ -L /lib/libffi.so.${FFI_VER} ] && rm /lib/libffi.so.${FFI_VER}
ln -s ${OPTDIR}/lib/libffi.so.${FFI_VER} /lib/libffi.so.${FFI_VER}
fi
fi
done
#fix up some of the binary paths and fix some command syntax for busybox
#moved this to start-stop-status from installer.sh because Code42 push updates and these
#new scripts will need this treatment too
FIND_TARGETS=
for TARGET in ${SCRIPTS_TO_EDIT}; do
FIND_TARGETS="${FIND_TARGETS} -o -name ${TARGET}"
done
find ${OPTDIR} \( -name \*.sh ${FIND_TARGETS} \) | while IFS="" read -r FILE_TO_EDIT; do
if [ -e ${FILE_TO_EDIT} ]; then
#this list of substitutions will probably need expanding as new CrashPlan updates are released
sed -i "s%^#!/bin/bash%#!${SYNOPKG_PKGDEST}/bin/bash%" "${FILE_TO_EDIT}"
sed -i -r "s%(^[ \t]+)nice -n%\1${SYNOPKG_PKGDEST}/bin/nice -n%" "${FILE_TO_EDIT}"
sed -i -r "s%/bin/ps [^\|]*\|%/bin/ps w \|%" "${FILE_TO_EDIT}"
sed -i "s/rm -fv/rm -f/" "${FILE_TO_EDIT}"
sed -i "s/mv -fv/mv -f/" "${FILE_TO_EDIT}"
fi
done
#any downloaded upgrade script will usually have failed until the above changes are made so we need to
#find it and start it, if it exists
UPGRADE_SCRIPT=`find ${OPTDIR}/upgrade -name "upgrade.sh"`
if [ -n "${UPGRADE_SCRIPT}" ]; then
rm ${OPTDIR}/${ENGINE_SCRIPT}.pid
SCRIPT_HOME=`dirname $UPGRADE_SCRIPT`
#make CrashPlan log entry
TIMESTAMP="`date +%D` `date +%I:%M%p`"
echo "I ${TIMESTAMP} Synology repairing upgrade in ${SCRIPT_HOME}" >> ${LOG_FILE}
mv ${SCRIPT_HOME}/upgrade.log ${SCRIPT_HOME}/upgrade.log.old
chown -R ${DAEMON_USER} ${SYNOPKG_PKGDEST}
su - ${DAEMON_USER} -s /bin/sh -c "cd ${SCRIPT_HOME} ; . upgrade.sh"
mv ${SCRIPT_HOME}/upgrade.sh ${SCRIPT_HOME}/upgrade.sh.old
exit 0
fi
#updates may also overwrite our native binaries
if [ "${SYNO_CPU_ARCH}" == "x86_64" ]; then
#Intel synos need rwojo's glibc version shim for inotify support (https://github.com/wojo/synology-x86-glibc-2.4-shim)
cp ${SYNOPKG_PKGDEST}/bin/synology-x86-glibc-2.4-shim.so ${OPTDIR}/lib
else
cp -f ${SYNOPKG_PKGDEST}/bin/libjtux.so ${OPTDIR}
cp -f ${SYNOPKG_PKGDEST}/bin/jna-3.2.5.jar ${OPTDIR}/lib
cp -f ${SYNOPKG_PKGDEST}/bin/libffi.so.* ${OPTDIR}/lib
fi
#set appropriate Java max heap size
RAM=$((`free | grep Mem: | sed -e "s/^ *Mem: *\([0-9]*\).*$/\1/"`/1024))
if [ $RAM -le 128 ]; then
JAVA_MAX_HEAP=80
elif [ $RAM -le 256 ]; then
JAVA_MAX_HEAP=192
elif [ $RAM -le 512 ]; then
JAVA_MAX_HEAP=384
#CrashPlan's default max heap is 512MB
elif [ $RAM -gt 512 ]; then
JAVA_MAX_HEAP=512
fi
if [ $USR_MAX_HEAP -gt $JAVA_MAX_HEAP ]; then
JAVA_MAX_HEAP=${USR_MAX_HEAP}
fi
if [ $JAVA_MAX_HEAP -lt $JAVA_MIN_HEAP ]; then
#can't have a max heap lower than min heap (ARM low RAM systems)
$JAVA_MAX_HEAP=$JAVA_MIN_HEAP
fi
sed -i -r "s/(^${CFG_PARAM}=.*) -Xmx[0-9]+[mM] (.*$)/\1 -Xmx${JAVA_MAX_HEAP}m \2/" "${OPTDIR}/bin/${ENGINE_CFG}"
#disable the use of the x86-optimized external Fast MD5 library if running on ARM and QorIQ CPUs
#seems to be the default behaviour now but that may change again
if [ "${SYNO_CPU_ARCH}" != "x86_64" ]; then
grep "^${CFG_PARAM}=.*c42\.native\.md5\.enabled" "${OPTDIR}/bin/${ENGINE_CFG}" > /dev/null \
|| sed -i -r "s/(^${CFG_PARAM}=\".*)\"$/\1 -Dc42.native.md5.enabled=false\"/" "${OPTDIR}/bin/${ENGINE_CFG}"
fi
#reset ownership of all files to daemon user, so that manual edits to config files won't cause problems
chown -R ${DAEMON_USER} ${SYNOPKG_PKGDEST}
chown -R ${DAEMON_USER} ${DAEMON_HOME}
#now edit the XML config file, which only exists after first run
if [ -f ${SYNOPKG_PKGDEST}/conf/my.service.xml ]; then
#allow direct connections from CrashPlan Desktop client on remote systems
#you must edit the value of serviceHost in conf/ui.properties on the client you connect with
#users report that this value is sometimes reset so now it's set every service startup
sed -i "s/<serviceHost>127\.0\.0\.1<\/serviceHost>/<serviceHost>0\.0\.0\.0<\/serviceHost>/" "${SYNOPKG_PKGDEST}/conf/my.service.xml"
#this change is made only once in case you want to customize the friends' backup location
if [ "${MANIFEST_PATH_SET}" != "True" ]; then
#keep friends' backup data outside the application folder to make accidental deletion less likely
sed -i "s%<manifestPath>.*</manifestPath>%<manifestPath>${MANIFEST_FOLDER}/backupArchives/</manifestPath>%" "${SYNOPKG_PKGDEST}/conf/my.service.xml"
echo "MANIFEST_PATH_SET=True" >> ${SYNOPKG_PKGDEST}/syno_package.vars
fi
#since CrashPlan version 3.5.3 the value javaMemoryHeapMax also needs setting to match that used in bin/run.conf
sed -i -r "s%(<javaMemoryHeapMax>)[0-9]+[mM](</javaMemoryHeapMax>)%\1${JAVA_MAX_HEAP}m\2%" "${SYNOPKG_PKGDEST}/conf/my.service.xml"
else
echo "Wait a few seconds, then stop and restart the package to allow desktop client connections." > "${SYNOPKG_TEMP_LOGFILE}"
fi
if [ "${CRON_LAUNCHED}" == "True" ]; then
[ -e /var/packages/${SYNOPKG_PKGNAME}/enabled ] || touch /var/packages/${SYNOPKG_PKGNAME}/enabled
fi
if [ "${SYNO_CPU_ARCH}" == "x86_64" ]; then
su - ${DAEMON_USER} -s /bin/sh -c "LD_PRELOAD=${SYNOPKG_PKGDEST}/lib/synology-x86-glibc-2.4-shim.so ${OPTDIR}/bin/${ENGINE_SCRIPT} start"
else
su - ${DAEMON_USER} -s /bin/sh -c "${OPTDIR}/bin/${ENGINE_SCRIPT} start"
fi
exit 0
;;
stop)
su - ${DAEMON_USER} -s /bin/sh -c "${OPTDIR}/bin/${ENGINE_SCRIPT} stop"
if [ "${CRON_LAUNCHED}" == "True" ]; then
[ -e /var/packages/${SYNOPKG_PKGNAME}/enabled ] || rm /var/packages/${SYNOPKG_PKGNAME}/enabled
fi
exit 0
;;
status)
PID=`/bin/ps w| grep "app=${APP_NAME}" | grep -v grep | awk '{ print $1 }'`
if [[ -n "$PID" ]]; then
exit 0
else
exit 1
fi
;;
log)
echo "${LOG_FILE}"
exit 0
;;
esac
Changelog:
- 0022 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
- 0021 Updated CrashPlan to version 3.5.2
- 0020 Fixes for DSM 4.2
- 018 Updated CrashPlan PRO to version 3.4.1
- 017 Updated CrashPlan and CrashPlan PROe to version 3.4.1, and improved in-app update handling
- 016 Added support for Freescale QorIQ CPUs in some x13 series Synology models, and installer script now downloads native binaries separately to reduce repo hosting bandwidth, PowerQUICC PowerPC processors in previous Synology generations with older glibc versions are not supported
- 015 Added support for easy scheduling via cron – see updated Notes section
- 014 DSM 4.1 user profile permissions fix
- 013 implemented update handling for future automatic updates from Code 42, and incremented CrashPlanPRO client to release version 3.2.1
- 012 incremented CrashPlanPROe client to release version 3.3
- 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
- 005 added warning to restart daemon after 1st run, and improved upgrade process again
- 004 updated to CrashPlan 3.2.1 and improved package upgrade process, forced binding to 0.0.0.0 each startup
- 003 fixed ownership of /volume1/crashplan folder
- 002 updated to CrashPlan 3.2
- 001 intial public release

This isn`t possible from the Synology where all other backup-files are living??
These are container-files. Big files – mine are 1TB each! But inside the 3TB-Volume are only a couple of GB. So it would take ages to upload and keep them updated. It makes no sense to backup whole iSCSI-Volumes. Even you could mount it read-only from within the synology – chances are, you would have a volume that is not understood by the synology. In my case, it would be HFS+.
Thanks for this package. Installation works on my Synology DS412+.
Now, CrashPlan updated to 3.5.3 (UI on the PC) but on the NAS it is still 3.5.2 and backup is not working anymore. System seems to be locked. CrashPlan wants to update in loop… Locally (PC) but the package on NAS remain 3.5.2. On the welcome screen of UI I’ve a ‘impossible to connect to the remote engine continue YES | NO ’
Is there any update of the Linux package on the NAS to come from you side ?
Or any help to patch this issue will be appreciated.
Best, David / France
You did follow the “Stop/Start-procedere after an update”-advice above?
“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). You will need to wait several minutes in the event of this happening before you take action, because the update script tries to restart CrashPlan 10 times at 10 second intervals. After this, you simply start the package again in Package Center and my scripts will fix the update, then run it. One final package restart is required before you can connect with the CrashPlan Desktop client (remember to update that too).”
Thank you for the fast reply. The backup is now working. However I still have CrashPlan 3.5.2-0021 installed on my NAS and (CrashPlan desktop 3.5.3 on Windows 7.).
How can I update the linux engine to 3.5.3 ?
Please see detailed screenshots here: http://xdatacenter.net/tmp/cp/
Remark, I only have Java SE Embedded 6 available has a package. (not Java SE Embedded 7) don’t know if it can be a source of problem?
Thanks again for your help.
The package version displayed in DSM Package Centre will not update when an in-app update happens. To see for sure which version your NAS is running, use the CP client on your computer to manage the NAS as usual, then double click on the CrashPlan house logo in the corner. In the prompt, type ‘version’.
Just gave you a donation for your excellent work on this project. Have you ever considered accepting Bitcoin? (hint, hint)
A couple of constructive comments that might help others.
Although some consider it unsafe to run services as root unless absolutely necessary, I found it necessary. I keep a number of restricted-access files on my Synology, and CrashPlan running as user ‘crashplan’ would never back them up because it could not read them. I also for various reasons could not simply add them to the crashplan group. I ended up hacking the install to run CrashPlan as root, and now it happily backs up all my files. However if you have any other workaround for this, I’d be glad to hear it.
If anyone else wants to run it as root (including myself if I forget how I did this, which happens often), here are some steps and some gotchas.
Modify /var/packages/CrashPlan/scripts/start-stop-status.sh. Around line 160 in my file, it tests for the architecture before launching. I am using an Intel-based Synology, so architecture is x86_64. Thus, the line that launches CrashPlan is the next line (161 in my file). I commented out that line, and by experimentation and debugging and trial-and-error, I found these lines work:
export HOME=’/var/services/homes/crashplan’
export JAVA_HOME=’/volume1/@appstore/java6/jre’
/bin/sh -c “LD_PRELOAD=${SYNOPKG_PKGDEST}/lib/synology-x86-glibc-2.4-shim.so ${OPTDIR}/bin/${ENGINE_SCRIPT} start”
[... I have a feeling I'm already leaving something out...]
Gotcha: When running as root, CrashPlan will write its identity file to /var/lib/crashplan/.identity, which it could not do previously. Then, as you noted above (and which I was happy to find when trying to debug this), it gets confused between that file and the one it wrote previously as the ‘crashplan’ user in /var/services/homes/crashplan/.crashplan/.identity. Solution: delete the latter file, and then re-adopt the computer.
[Continuing the post on running crashplan as root] I did forget the section on stopping Crashplan. It is similar. Comment out the ‘su – …’ line and add three lines as shown below:
# su – ${DAEMON_USER} -s /bin/sh -c “${OPTDIR}/bin/${ENGINE_SCRIPT} stop”
export HOME=’/var/services/homes/crashplan’
export JAVA_HOME=’/volume1/@appstore/java6/jre’
${OPTDIR}/bin/${ENGINE_SCRIPT} stop
Hi – thanks so much for this. Got it installed a few months ago and it was working wonderfully until recently and I can’t seem to figure out what broke/how to fix it. I’m running the 3.5.3 client on a Mac (it updates itself automatically I believe) and 3.5.2 on my DS1811+ and the main two issues are:
1. it seems to “forget” what it is supposed to back up. I have trimmed it down to only 2 folders in my testing but when I fire up the client it immediately starts “scanning…” as though it doesn’t know what it should be doing. When I get the emailed status report from Crashplan it indicates that I am trying to back up 145GB when in fact I have about 1.5TB selected in the headless client.
2. the client will usually crash after a few minutes saying that it was “disconnected from the backup engine.”
It’s frustrating because it is still backing up small bits of what I have selected at the scheduled times but I already had backed up about 850GB and am worried that I may lose all of that data on the CP servers.
thanks for any advice – happy to dig up log files or whatever helps.
Cheers,
Reid
That sounds like your headless client on the NAS does not have enough RAM to work with. On my 1812+ it has been modified to use up to 2.5GB and is happily running along now with several TB as backup Source and several incoming backups. Check some older comments for explanations how to change the amount of RAM dedicated to CrashPlan/Java.
Will you be able to support the new DS213j at some time in the future? It runs the Marvell_ARMADA_370 so I dont get the option for Crashplan in your package.
Majorly bummed after buying my DS213j to _then_ find it wont run your headless Crashplan :(
The 213 a great starter unit, will be very popular because of the price point.
Love your work, genius.
I’ve tried to compile the various dependencies for the Armada 370 CPU but I have no way of testing them unfortunately. Can you try installing this on your DS213j via Package Center:
http://packages.pcloadletter.co.uk/downloads/crashplan3.5.3-merged-0022.spk
Does CrashPlan start? Can you check the log files in an SSH session:
cat /volume1/@appstore/CrashPlan/log/engine_error.log | morecat /volume1/@appstore/CrashPlan/log/engine_output.log | more
If it runs, can you check that it is able to detect real-time changes to the filesystem? Does it list another file to be backed up immediately in the CrashPlan console when you add a new file to a monitored folder?
I installed the package manually and adopted an account (Crashplan+) that was running elsewhere. Unfortunatately the service crashes quite frequently (every few minutes). I have about 160GB to backup. According to the specs the 213j has 512MB of RAM. Is this not enough? If not then am I sol? Could a cron script to restart it help?
BTW Do you still need someone to provide feedback on the Serviio package on the 213j?
Followed up by email…
@iamroddo
512MB does not sound like much.
What do the logs say, that can help you shed some light on the issue?
First, Thanks!
I’m running this package on my s213+. The package updated to 3.5.3 on the ds213+ but, the program on my windows 7 machine is still at 3.5.2. Everything is working fine. Nonetheless, should I update the windows program to 3.5.3? I only use the windows program to interface with the ds213+, ie, I don’t use the program to backup my windows machine.
thanks again.
Hal
I also used to have big problems to get CrashPlan to work on my DS 411 + II, but after increasing Heap Size to 1024 Mb and set the start / stop using Cronjob Editor everything has worked 100%. One month without any problems what so ever.
Thanks for a great package!
Pingback: Synology DiskStation Network Attached Storage (NAS) | Ben Black's Blog
Pingback: My Family’s PC/Mac Backup Strategy | Ben Black's Blog
Hi,
after the increasing of virtual memory CrashPlan works fine until sunday. In the last days it stops few minutes after the full scanning of 3:00AM and after few files backed up. The engine_error.log is empty. I inspected the others log files but I didn’t found anything that seems to be an error message.
When I restart the engine via the http interface (Packages Center) it starts and it seems to work fine.
Any idea? Maybe I can send you sole log files?
Thank you for your answer and for the great job you do.
m
I just installed CrashPlan on my DS1812+, and now I have 62 java processes running. Is this normal or what’s going on?
Okay, so I found a similar question in a previous comment above, and your answer to it. However, the java processes do not have the same process ID.
Does the same thing happen if you uninstall my Java package and use the one Synology provides for Intel systems?
After i upgraded yor package for java i get: CrashPlan has been disconnected from the backup engine, and it seems it dosent upload any files eighter anymore, what do i do? (DS2413)
Ok, i installed Java from “Java Manager” instead with “jdk-6u45-linux-i586.bin”. But with the same results, it won’t upload anymore. =/
I uninstalled “java manager” and installed your java again.
One thing i noticed is that crachplan package restarts itself also over and over.
I wondering, can this be a ram/memory issue? (I just bought 2GB more ram that i wil get in a week or so, hope it helps)
Very likely yes.
Hello Patters. CrashPlan has now released CrashPlan PROe 3.5.4. Do we need to wait for you to release a Synology package that corresponds with that version to update a Synology NAS running CrashPlan PROe server or can we just use the latest syno package you have available and install the CrashPlan upgrade file via the Web Interface of the CrashPlan PROe server like I’m used to doing on the other CrashPlan PROe servers I managed (not running on Synology NAS hardware)?
I have updated CrashPlan 3.5.3 packages for CP+, CPPRO, and CPPROe. They’re all ready (including for Armada 370) but I’m waiting for feedback about whether the realtime filesystem watching for Armada 370 is working before I release (I had to compile a lot with no testing possible).
I will take a look at the CrashPlan PROe Server package after that, but it hasn’t been updated in a long while, plus I shall need to merge all the separate installer scripts like I did for all my other packages.
Good news for DS213j owners – I have been able to cross compile the binary dependencies necessary to support the Armada 370 CPU, complete with working real time backup! Thanks to iamroddo for testing.
hello, i updated to the new 3.5.3 crashplan package today and now I can no longer connect to the service on the synology from either my windows or mac computers. I’ve checked the ui.properties files, the service host IP address is correct an un-commented, and the port is set to 4243 and uncommented as well. I’ve manually stopped and restarted the service on the NAS, but still no joy.
Also tried removing and re installing crashplan completely.
I’m using the synology-provided java package.
Any suggestions?
ok, did a little more troubleshooting on this.
I can connect to the service successfully until I pause a running backup- once I’ve done that, I can’t connect again until the crashplan service has been stopped and restarted on the synology
anything? I had no problems for over a year with the older package, problems started immediately with 3.5.3 . . . .
Hi Patters
Whats the latest synology OS version on which crashplan package works ?
The latest – 4.2
Patters i know this is probably not the right section for this request, however I think others would find an interest in this as well. do you think you could get the FOG server install to work on the synology NAS? http://www.fogproject.org/ i’ve been reading up on it and it would be an awesome addition to these awesome boxes.
I am also having issues with the crashplan package. Port 4242 is open (tested with telnet), but port 4243 not, not even on localhost. The backups are not working as crashplan client show an outdated ip …
Is it just me having these issues ?
Glad to provide extra info, running on DS713+
Hi there! No problems here, I just wanted to say a big “thank you” for creating and maintaining this package. I have been using it for years on my ds 411+ now. Since data keeps getting more and more, I even outgrew the 1GB RAM, but with an upgraded 4GB bar, it runs perfectly. Thanks again!
If you have a bitcoin address, I’d love to drop a small donation. If you don’t know what it is,check http://reddit.com/r/bitcoin
Regards,
Luiz
Set this up on a DS412+ about two months ago and everything was working wonderfully until last week. We had to physically move the unit, and since we got it back up and running in the other room, the CrashPlan Pro package will silently shut off after 10 to 30 minutes of inactivity and the desktop client will disconnect. If I go back into the control panel and turn the package back on, it behaves normally again until it suddenly stops.
I checked the error log (the system one, accessed via SSH) and it was completely empty. Nothing interesting in the system activity log or the standard activity log, either.
Any ideas on how I could troubleshoot the issue? Running the 3.5.3 desktop client, with the 3.5.3-0022 package on the DiskStation. I tried uninstalling and reinstalling the package but no change.
For about the past two months now this has no longer worked for me. CrashPlan starts, and runs for somewhere between 2 and 5 minutes, and then restarts. It is making no progress with my backups and just chewing up resources. I have a DS-1512+ with 3GB RAM, and 1GB allocated to Java.
The logs are just a continuous loop like this:
Crashplan started
Starting backup to Crashplan Central: NN files and (NN GB) to back up
Scanning for files to back up
Backup scheduled to always run
Crashplan started
…
Does anyone have any idea how to diagnose this?
How much data is there in your backup set (total amount)
I made more backup sets with chunks of the complete backup, running smoothly after doing that.
i’ve got lots of backups sets- I’ve had those set up since I first installed crashplan– they worked fine until 3.5.3 was installed.
3.5.3 package appears to be flat out broken in some instances at least.
I find even if I pause the backup it still crashes. 3.5.3 seems pretty broken.
is there any way to revert to the old package? the old version worked perfectly for me for over a year, haven’t been able to upload a single bit of data to crashplan with 3.5.3.
http://img29.imageshack.us/img29/30/efz7.jpg
Ive decided to just install crashplan manually by following this guide step by step :
http://forum.synology.com/wiki/index.php/CrashPlan_Headless_Client#Making_CrashPlan_work_with_non_US-ASCII_characters
worked like a charm !
I hope in the near future patters will get support from Crashplan, or Crashplan will add their own package.
Both Synology and Crashplan seem to have it on their agenda :
argh, may have found the problem- when I saw the repeated crashes and restarts in the log today, I decided to check my syno_package.vars file again- I had edited that file before since I do have lots of data being backed up. the file had been reset to the default with the heap size line commented out. i could have sworn that i’d uninstalled/reisntalled crashplan on the nas before without that file resetting to defaults- is that something you need to re-do after reinstalling, patters?
anyway, hopefully that’s all the problem was . . . is there any way to delete posts on here? lol
Ok, i upgraded my ram (2 gig more, so now i have 4gig total) DS2413+
But its restarting itself over and over now and then, and it still won’t upload files.
Also the UI i have on my computer shuts down saying it loses contact with crashplan at random times (i suppose thats when it restarts) What can i do?
How much heap size did you address to the java process? And how much data do you try to backup??
did you try to resize the heap size??
I think I have found why the latest version keeps crashing. It seems like the heap is 512M even though I set it higher in the syno_package.vars file. I see this in app.log:
JavaOptions = [-Dfile.encoding=UTF-8, -Dapp=CrashPlanService, -DappBaseName=CrashPlan, -Xms20m, -Xmx512m, …
while my syno_package.vars says:
USR_MAX_HEAP=2048M
Anyone know how to fix this? Thanks.
Hi Patters, this solutions works very wel on my new Synology DS213+ (with the Freescale QorIQ P1022 PPC CPU)
Many thanks for your easy implementation and useable installation description!
I have not changed anything in any file (don’t know how to change the heap size), only thing i tried to do is to uninstall Java, then install it again. I have lots of backup sets for different things, some are small around 1-500 hundred gig and some are big, the biggest is 2.4TB and most are 1.5TB (14 sets) DS2413+
Ops, this should have been a reply to “Dinges” last post, seems i cant remove and post it where it should myself.
Ametz,
Change the heap size (discribed in the “notes” from the opening post) and the backup will start to run.. btw, a backup of 2,4T will use a very large amount of memory to backup. But it will do with 4 Gb of physical memory..
I don’t know how to do that SSH thing, is there a program somewhere like an explorer that can open it instead, just like a normal folder? So i can edit that way?
There is a package called 3th party init. I think with that one you can do it.
But SSH cannot be more simple! Download “putty” (freeware), connect to the NAS, and change the settings file! Nothing more to do..
Seems im in with putty, it lokks like an old dos promt =/
Almost right… its linux.. but the principle is the same..
editing of the file is done by the command “vi”.
Google for the key-strokes to change the text in “vi”
I can’t even find the file (dont know hot to “browse”), and i can’t find a youtube vids of the procedure eighter. =/
Get “WinSCP” and use SSH mode… it’s a pretty steep learning curve using PuTTY and having to command-line everything. WinSCP is a familiar FTP-type interface and would let you download the files, edit them locally and send them back (although be very careful with this – use Notepad++ or TED Notepad to edit, not the default Windows notepad, as it will very likely mess up the files).
Kevin with that program i get:
connection has been unexpectedly closed. server sent command exit status 255
Cannot initialize SFTP protocol. Is the host running a SFTP server?
Change the protocol to SSH instead of SFTP.
There is only 3 to choose from: SFTP, SCP and FTP
Sorry – SCP protocol, not SFTP. My mistake!
Thats better, it was 512, i changed to 1024, should that be ok or do i need to add more? 1536 perhaps?
Ok that did not seem to work, even if i’m changing to 1536 and restart the ds2413 crashplan still shuts down, startup and shuts down again after 2-3 min over and over.
Ametz, that’s what I was seeing. In my case the setting in syno_package.vars was having no effect. Instead, I edited /volume1/@appstore/CrashPlan/bin/run.conf, and changed the -Xmx512m setting in the SRV_JAVA_OPTS line. That has worked for me; running 24 hours now without a restart, for the first time in weeks.