CrashPlan packages for Synology NAS

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-Windows

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.

UPDATE – For version 3.2 I also had to identify and then figure out how to compile Tim Macinta’s fast MD5 library, to fix the supplied libmd5.so on ARM systems (CrashPlan only distributes libraries for x86). I’m documenting that process here in case more libs are required in future versions. I identified it from the error message in log/engine_error.log and by running objdump -x libmd5.so. I could see that the same Java_com_twmacinta_util_MD5_Transform_1native function mentioned in the error was present in the x86 lib but not in my compiled libmd5.so from W3C Libwww. I took the headers from an install of OpenJDK on a regular Ubuntu desktop. I then used the Linux x86 source from the download bundle on Tim’s website – the closest match – and compiled it directly on the syno using the command line from a comment in another version of that source:
gcc -O3 -shared -I/tmp/jdk_headers/include /tmp/fast-md5/src/lib/arch/linux_x86/MD5.c -o libmd5.so

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!

CPPROe package info

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:

CrashPlan-update-repair

 

Installation

  • This package is for Marvell Kirkwood, Marvell Armada 370/XP, Intel and Freescale QorIQ/PowerQUICC PowerPC CPUs only, so please check which CPU your NAS has. It will work on an unmodified NAS, no hacking or bootstrapping required. It will only work on older PowerQUICC PowerPC models that are running DSM 5.0. It is technically possible to run CrashPlan on older DSM versions, 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 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.6.3_Linux.tgz"
[ "${SYNOPKG_PKGNAME}" == "CrashPlanPRO" ] && DOWNLOAD_FILE="CrashPlanPRO_3.6.3_Linux.tgz"
[ "${SYNOPKG_PKGNAME}" == "CrashPlanPROe" ] && DOWNLOAD_FILE="CrashPlanPROe_3.6.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`"
[ "${SYNO_CPU_ARCH}" == "x86_64" ] && SYNO_CPU_ARCH="i686"
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%(^\s*)nice -n%\1${SYNOPKG_PKGDEST}/bin/nice -n%" "${FILE_TO_EDIT}"
        sed -i -r "s%(^\s*)(/bin/ps|ps) [^\|]*\|%\1/bin/ps w \|%" "${FILE_TO_EDIT}"
        sed -i -r "s%\`ps [^\|]*\|%\`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
      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

    #move the Java temp directory from the default of /tmp
    grep "^${CFG_PARAM}=.*Djava\.io\.tmpdir" "${OPTDIR}/bin/${ENGINE_CFG}" > /dev/null \
     || sed -i -r "s%(^${CFG_PARAM}=\".*)\"$%\1 -Djava.io.tmpdir=${TEMP_FOLDER}\"%" "${OPTDIR}/bin/${ENGINE_CFG}"

    #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

    #delete any stray Java temp files
    find /tmp -name "jna*.tmp" -user ${DAEMON_USER} | while IFS="" read -r FILE_TO_DEL; do
      if [ -e ${FILE_TO_DEL} ]; then
        rm ${FILE_TO_DEL}
      fi
    done

    #increase the system-wide maximum number of open files from Synology default of 24466
    echo "65536" > /proc/sys/fs/file-max

    #raise the maximum open file count from the Synology default of 1024 - thanks Casper K. for figuring this out
    #http://support.code42.com/Administrator/3.6_And_4.0/Troubleshooting/Too_Many_Open_Files
    ulimit -n 65536

    if [ "${SYNO_CPU_ARCH}" == "x86_64" ]; then
      #Intel synos running older DSM need rwojo's glibc version shim for inotify support
      #https://github.com/wojo/synology-x86-glibc-2.4-shim
      GLIBC_VER="`/lib/libc.so.6 | grep -m 1 version | sed -r "s/^[^0-9]*([0-9].*[0-9])\,.*$/\1/"`"
      if [ "${GLIBC_VER}" == "2.3.6" ]; 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
    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:

  • 0027 Fixed open file handle limit for very large backup sets (ulimit fix)
  • 0026 Updated all CrashPlan clients to version 3.6.3, improved handling of Java temp files
  • 0025 glibc version shim no longer used on Intel Synology models running DSM 5.0
  • 0024 Updated to CrashPlan PROe 3.6.1.4 and added support for PowerPC 2010 Synology models running DSM 5.0
  • 0023 Added support for Intel Atom Evansport and Armada XP CPUs in new DSx14 products
  • 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
 
 
About these ads

2,208 thoughts on “CrashPlan packages for Synology NAS

  1. Mitchell

    Thanks Patters. I uninstalled Java 6 and Crashplan. I then did the DSM upgrade that just came out. I then installed Java 7 and reinstalled Crashplan. It started the backup. However, still, when I launch the CP Client, it kicks me off in about 30 seconds. Is anyone else having this problem? Any recommendations? Thanks. Mitchell

    Reply
    1. C Farley

      I have a DS412+ as well with the exact same problem.
      I have uninstalled everything, reinstalled everything, always with the same results.
      The crashplan package will not stay running.
      I have tried java 6, 7, & 8. All with the same results.
      This morning I updated to DSM 5.0-4458 Update 1. The problem continues.

      Everything worked fine with the crashplan package 0026. Since I upgraded to 0027 I have been unable to run the package.

      No backup for 10+ days now. Sweating here…

      Reply
      1. ZeusII

        How did you install java? Are you using the SPK from “community” or the official one from Synology?

        I had no problems using Java 7u51 but I’m using Java Manager from Synology.

      2. C Farley

        I originally had the Synology Java Manager, but switched to the “community” java when I started having this problem.
        I have now done a clean install of the Synology Java Manager, new download of jdk-7u51-linux-i586.gz, and a clean install of CPpro. Still having the same issue.
        CPpro package will not stay running for more than one or two seconds.

        I’m at a total loss to figure this out. It was working just fine in 0026.
        DS412+ with the latest DSM

      3. JohnV

        @C Farley
        I’ve had the same problem. The way I fixed was this:
        (timing is critical as CrashPlan runs for short while then stops, make sure to complete these while CP still runs)
        - remove the backup schedule if you have one (make sure it is always run). Settings->Backup->”Backup will run” ->Always

        - go to the backup selection selection, and add/remove a file to be backed up. (basically need to make a change) Backup->Files->Change

        - go to backup schedule screen and verify selection; Settings->Backup->”Verify Selection Every” -> NOW

        Now go back to Backup->Files and observe files being checked, etc.

        that solved my problem. Hope this helps.

    2. Peter

      Since my upgrade to DSM 5.0 and crashplan 3.6.3-0027 on my 1511+ I’ve had problems with backing up to crashplans servers.
      I Get an error in the client program “crashplan disconnected from backup engine”, and the program exits.
      I tried upgrading to Java 8, but that didn’t make any difference.
      I think the NAS connects to crashplans server, since I can see it in the log, on their web service.
      Th error happens during scanning of the files to be backed up, and i does repeatedly.
      The I noticed the ram usage allways reached 72% and the dropped simultaneously with the application crash.
      That made me wonder if the memory handling/usage in DSM 5.0 had changed, and i reached the maximum allocated to the crashplan service.
      My first thought was to order some more RAM (additional 2 GB, since I have the standard 1 GB), and that is on the way now.
      Then I realized, that it is possible to allow crashplan to use more than the standard 512 MB by editing the file
      “/volume1/@appstore/CrashPlan/syno_package.vars”
      I changed it to 720M
      And now the memoryload in the webinterface widget shows 82% and turned orange (screaming for more RAM).
      top btw shows:
      17580 1 crashpla S N 817m 82.3 0.0 /volume1/@appstore/java8/ejdk1.8.0/lin….

      But at least the crashplan client i still running, and continuing to scan 106.000+ files and counting.

      For now I’m just holding my breath, hoping for lack of RAM to be the solution.
      Regards
      Peter

      Reply
      1. Peter

        …And what a relief.
        For me it seemed to do the trick.
        DSM 5.0 must be a bit more hungry when it comes to memory.
        I do hope this will be helpful for others in here.

      2. Peter

        All of which is described above in the notes.

        Thanks for a beautiful piece of software btw.

      3. benstrousers

        Changing the heap size has worked for me previously. After the I upgraded to DSM5 the heap size reverts to 512.

      4. benstrousers

        For now I changed the max java heap size in the start-stop- status script to the max of what I wanted it to be, seems to be working. Any other ides?

    3. Nick Harvey

      Hi – I havent used Crashplan before, but am giving up an a 100gb backup to another Synology as it never completes! Does Crashplan have the ability to speedlimit backups at certain times, so that the entire upload bandwidth is not hogged during the working day?

      Reply
    1. C Farley

      Guido, Does your crashplan package have anything in the ‘Logs’?
      I lost all my records when uninstalling and re-installing, but I was wondering if there was anything useful there.
      You can view more detailed notes in the folder DISKSTATION\crashplan\log\engine_error.log
      Are you using crashplan Pro?

      Reply
      1. Chris

        Hi,

        Same here: updated the box to DSM 5, installed Java 8 and CrashPlan is closed after a couple of seconds (tried increasing memory, to no avail). That’s what I see in the logs by the VM (part of it):

        #
        # A fatal error has been detected by the Java Runtime Environment:
        #
        # SIGSEGV (0xb) at pc=0×00006524, pid=16654, tid=1561998448
        #
        # JRE version: Java(TM) SE Embedded Runtime Environment (8.0-b132) (build 1.8.0-
        # Java VM: Java HotSpot(TM) Embedded Client VM (25.0-b70 mixed mode linux-arm )
        # Problematic frame:
        # C 0×00006524
        #
        # Core dump written. Default location: /volume1/@appstore/CrashPlan/core or core
        #
        # If you would like to submit a bug report, please visit:
        # http://bugreport.sun.com/bugreport/crash.jsp
        # The crash happened outside the Java Virtual Machine in native code.
        # See problematic frame for where to report the bug.
        #

        This message is printed lots of time for different threads. Any ideas?

      2. John B.

        @Chris – there have been a few posts about problems with Java 8. Try one of the older versions, 7 or 6.

    1. C Farley

      Vincent, which diskstation do you have? Which crashplan are you running e.g. PRO?
      Thanks for sharing your success.
      I am still dead in the water after doing what you describe with my 412+ running CPPro

      Reply
  2. C Farley

    I don’t want to come off as an ungrateful jerk, but….
    I have tried all combinations of Java (“community” vs Oracle, 6, 7, & 8) and fresh installs of 0027 CrashPlanPro, and nothing works. The CP package shows “Running” for one second and then changes to “Stopped”. It is not running long enough to even click “Stop”.
    I’m dead in the water now for two weeks. It seems that at least a few other people have had the same problem.

    Could the 0026 CrashPlanPro be put back up on the Package share please?

    Reply
    1. C Farley

      Just out of curiosity, I installed the plain version of CrashPlan (not PRO) and had the same results as above.

      Reply
      1. Mitchell

        I would like to try the have you download from the non-java site. Can you tell me where to get it? Thanks.

      2. C Farley

        I appreciate all advice, and the humor.
        I uninstalled all java, then restarted.
        Installed java from oracle and CPPro then restarted.
        The problem continues unchanged.

        I see that others with the 412+ are having the same issue.
        My 412+ is fairly new, purchased in February. Anyone else?
        It is the INTEL Atom 2.13 GHz processor with 1 GB of memory.
        The RAM usage is typically around 12-15% so it’s not a low memory issue.

      3. Mitchell

        Me too, unfortunately. Is there a series of steps that we would all execute in sequence, that is exhaustive, that could facilitate the debugging process, and, provide insights that could be helpful in solving the problem?

      4. John B.

        Is there a DS 412+ user out there that has got this running?
        If so, please specify which versions of hardware and software (DSM, CP/CPPro and Java).

        I have a DS 411+II with:
        * DSM 5.0-4458-Update 1
        * CrashPlan 3.6.3-0027
        * Oracle Java Manager running Java 7.0.51-0021

        I use backup sets in order to conserve memory and reduce the total number of files processed in one go.

      5. C Farley

        I’m so glad to see that apparently it isn’t just me and my ineptitude that broke CP.
        No solutions for me yet.
        Just to add to the system info I have the 412+ with DSM 5.0-4458 Update 1, I have tried all the variants and combinations of java and crashplan.

      6. C Farley

        Just for laughs, I installed DSM Update 2 this morning to see if that would fix the problem.
        Uninstalled java & CPPro, rebooted, installed patters java 7 and CPPro.
        The same problem continues. Unchanged.
        I’m a Linux idiot, if anyone has any more advanced troubleshooting tips I could try, I sure would appreciate hearing from you. I’m at 18 days without cloud backup :(

        The patters CPPro package was the major factor for me in deciding to buy Synology…

      7. Don Anderson

        Bummer, I was really hoping that would address it.

        Is there a log file that at least can be viewed to see where it is failing? For me, no log entries are made in package manager or in the devices log.

        Thanks
        Don

  3. Don Anderson

    Same with me. I have a 412+ and tried to update to 0027 and since then crash plan will not staying running. I have tried uninstalled and reinstalling a number of times, rebooting, etc.. but it hasn’t made a difference. Log files are empty. Any chance that 0026 can be made available?

    Thanks

    Reply
    1. bruno

      after stopping crashplan package, deleting synology java package, install patters java7 package + fresh download of java7 from Sun, everything seems to work fine now (~18h of running package)

      Reply
      1. bruno

        after 18h, everything goes wrong again and crashplan restarts every 2 or 3 mins…
        i willtry to delete java again…

  4. Bjorn

    I have your package running OK on a XPEnology computer, running DMS5 (quad avaton processes, 16gb ram). I’m using the crashplan server on the xpenology and sending the data to it from a client on the same network, 1gb speed.

    I have tried sending normal files on the samba share, and I get around 700mb/s while doing this, but when I’m using crashplan I get around 50mb/s (~6megabyte per second). Looking at the resource monitor, the disk utilization is around 10-20%, cpu at 4%, and memory at 1%. Ssh:in into the machine gives about the same info, the crashplan thread in top is around 4-5% and mostly in S state, meaning its sleeping.

    On the client side, there are no queues on the HDs, no threshing on the harddrives, the cpu is at a very low percent. Backing up to a local drive will go tremendously quicker.

    I have tried to change the nice level on the server from 19 to 0 to see if that did any difference, and it did not. I have made sure the throtteling on both the client and the server are of (no limits sending when present/away both LAN and WAN). Tried changed it on the client to 100kbs just to see that the change did take effect; they did. Only wierd part was that it was the WAN settings that took effect, not the LAN. And yes, they are on same network, same subnet, same router.

    Any thing that might be causing this? It should go faster, and it seems that both the client and the server are idling on both their sides.

    /Björn

    Reply
      1. Bjorn

        No, this isnt uploading to Crashplan, this is my pc (client) to my synology (server). On a normal non crashplan+ plan.

  5. Timbo

    Adding my experience – I had Crashplan running on my Diskstation on DSM 4, and upgraded to DSM 5, to find it didn’t work anymore. All that was required was to uninstall Crashplan, uninstall Java SE Embedded 7, then reinstall Java then Crashplan. Works great again.

    Reply
  6. huelsi

    I’ve successfully installed CrashPlan on my DSM 5 based NAS. Thanks for the great job and for providing the package & instructions. I’ve one question regarding the deletion of backed up files. Usually if files that have been backed up are deselected in the CP Client those files should be deleted from the CP servers. It seems though that this is not working. Although I’m getting a warning that those files be deleted they are actually not.

    Reply
  7. arash

    I’m curious if anyone else has fixed this issue.

    I’ve got Crashplan up and running on my NAS and it seems to be backing up fine, however the CrashPlan service stops after a few hours. When I check the log, it says the following:

    “Reason for stopping backup – Nothing to do”

    I’m not sure if thats the actual cause, but its frustrating as it requires me to login and restart the service. Any ideas?

    Reply
  8. schroeb

    DS 412+ here running fine on DSM 5.0-4458 Update 1, with Crashplan 3.6.3-0027 and Java 1.7.0_51-0023 (also from patters).

    My installation is currently handling a 2TB+ backup on Crashplan. Upgraded to 2GB RAM and adjusted the appropriate options to have the system use enough of it.

    Had a memory-leakish behaviour with Java 8 so I went back to 1.7.0, absolutely no issues since then.

    Reply
    1. C Farley

      Count yourself fortunate. I did a fresh uninstall, restart, install, this morning as I do most mornings, and still nothing.
      What “options” are you changing for memory usage.
      Thanks for your input!

      Reply
    2. Bjorn

      Have your tried to send files through your crashplan-client from your PC to your DS412? EI just use Crashplan localy and do computer to computer? If so, what speed do you get, and what kind of network do you have? I’m trying to get a benchmark on how fast it should be. I’m getting very (compared to normal file copy) slow speeds.

      Reply
      1. Alexander

        Doing local backups, from a Windows PC to the Synology, or between two Synologies, will display speeds up to 120 Mbps, and I’m on a Gigabit LAN.
        Keep in mind that CrashPlan does encryption, compression and data deduplication. In other words, it does more than a simple file copy, hence cannot reach the full speed of your LAN.

      2. Bjorn

        You sort of have a point there, but I’m running this on a xpeology (ordinary PC, 4-core Avoton processor and 16gig ram), and I can see the CPU-load on my server-machine, and its at 4% doing this. Nor is the HD or the network maxed out, not even close. So its not stressing the server enough to choke it down to this low speed. Ergo, somthing else is making it go slow. Do your CPU and/or HD max out during your backups?

  9. 7bit

    Thanks a lot for your work! The packages are working great for me!! I am using DSM 5.0 Update 1 on a DS214play with Synology Java 1.7.0_51 and your Crashplan Home package.

    Working like a charm! Keep up the good work!

    Reply
  10. Anders Heilemann

    I trying to optimize my DS212j (ARM 1.2ghz – 256MB memory) on a 30/5mbit connection to handle as large crashplan backups as possible, so far I’ve set:
    Java heap size to 512MB
    De-Duplication to MINIMAL
    dataDeDupAutoMaxFileSizeForWan = 1 (http://goo.gl/4DXkn7)
    Compression to OFF
    Watch file system in real-time to Off
    (After initial backup I’ll set it to backup at night using a cron job to enable hibernation)

    Questions:
    1. – What happens if the heap size is bigger than the amount of physical memory? Does it start caching (slower backup, but still working?)
    2. – I’m using java 7 but wondering if java 6 or 8 might be lighter on memory usage (and if someone managed to fix the memory leak of java 8 as reported by schroeb above)
    2.5. – Perhaps some settings exist in Java to make it more memory efficient?
    3. – Crashplan is making identical backups from volume1 to volume2 and to the cloud, since only one backup is running simultanously, I don’t suppose two destinations take up more memory than one?

    Have anyone done other changes to improve the performance?

    Reply
  11. Aram G

    The first time I set this up it worked like magic, then Synology put out an update and it all went to hell. Since then, I was able to re install CP on the NAS drive but I am unable to configure it. Meanwhile, the backup files from the NAS disappeared from CP and I am still not sure it is not lost entirely.
    Any trouble shooting tips would be appreciated….

    Reply
  12. C Farley

    CrashPlanPro on DiskStation 412+ is back up and running!! That’s the good news.
    The less-than-good-news is that in order to make it work again, I had to downgrade my DSM to 4.3. The process was pretty easy, even for me, by following this great guide http://patrickscholten.com/downgrade-dsm-previous-version/

    The only downside that I see so far is that my DiskStation shows up as a new device on the CrashPlan portal. I did an “adopt a device” on the CP web interface. It says it will not have to do another initial backup if you do that. it appears to be picking up right where it left off 20 days ago.

    I recommend the downgrade! But it is a work around solution, SINCE I KNOW THAT CrashPlan 0026 DID WORK JUST FINE with DSM 5. But until a PROVEN CrashPlan package FOR DSM 5 comes out, I will not be upgrading DSM. (or if 0026 were made available I might go that route)
    For now the current 0027 package works with DSM 4.3, so I’m sticking with that.

    Reply
  13. Shane

    Hi guys. I had a problem when updating from 4.x to 5.x Looking at all of the info here I removed java and crashplan then reinstalled both. I have Java 1.6.0_38-0023 and Crashplan 3.6.3-0027 installed and working on my DS1512+. I had to adopt the data I had uploaded to Crashplan (I did two checks, not sure what the first one was called but the second was a block sync). The block sync did take a while as I have 6.5 TB in queue to be backed up (4.9 TB to go!) I am also backing up a family members data. I knew about updating the heap for Java and that had been done last year and the setting is still in place. All is working well for my own data and family members. I am currently running DSM 5.0-4458 Update 2. I do like the new look but like with Windows (insert version here) they have moved things around and am still getting used to it.

    On a side note, I use Chrome and ScriptSafe, has anyone seen when they login to DiskStation that the site refreshes for no reason? Maybe there is a setting in the new DSM that I have not see. 4.x did not do what 5.x is doing.

    I want to thank this community for all their input. I know there are still people out there that are having problems still but I see that there is so much help and everyone here is just awesome. It is good to see this type of communication. Glad I bought my Synology and to have all of this help here when needed.

    Reply
  14. Tim

    Hi all,
    I’m a novice to all this and I’m having trouble figuring out how to change the heap size. I can’t find the file that I’m supposed to modify to do this. Is this a hidden folder that I can only access through special means other the browsing through the file station? I’ve been searching for how to do this but it seems like most people already know how and nobody is asking the same question as me. I have about 2TB to backup from my DS1813+ and of course it keeps crashing and restarting. If somebody could point me in the right direction I’d really appreciate it.

    Reply
    1. patters Post author

      You need to log in to your syno using SSH (use PuTTY if you’re on a PC, or ssh root@1.2.3.4 from a terminal session on a Mac – where 1.2.3.4 is the IP of your NAS). Username is root, password is the same as the admin account one. Then you need to edit the file /volume1/@appstore/CrashPlan/syno_package.vars
      You will need some familiarity with the Unix text editor vi. You can Google this.

      Reply
      1. Tim

        First of all, I want to thank you for your work in behalf of everyone for making these packages and even making headless Crashplan even an option for us. What you’ve done is really cool and I appreciate it. I followed it all right through till this point. I think for me though, it’s getting to the point where Crashplan is becoming more work than it’s worth. Even when my server was a Win XP machine it seemed like I was constantly experiencing problems with it. Maybe if I followed the final additional steps necessary to get it working on the NAS it would be fine, but I can’t really justify the headache for me, as well as this being the only reason I’d need to upgrade my memory from 2gb. And then what happens when I need to back up more than 4tb? Anyway, yesterday I made the decision to move to a service that works easier and without Java. I went with Zoolz since it’s only $36 for a year so it’s not a big risk if I decide I don’t like it. So far so good, uploaded 116gb in about 18 hours. It would be nice to run the backup directly from the NAS but for me it’s not necessary. And I need an off-site backup purely as a safeguard against a local disaster so I don’t need much with versioning or immediate file recovery. Anyway, thanks again for the additional information so quickly. I wish as a business owner I had more time to try out some of this stuff, but sometimes I gotta cut my losses and move on!

    2. Shane

      Hi Tim. Do a search on this Web site for WinSCP. I posted something on here how to modify that file. It was a while ago but I found that using WinSCP instead of Putty is much easier.

      Reply
  15. Jason

    I had to upgrade from DSM 4.3 to DSM 5 because of the Heartbleed bug. I was running Java 1.7 and CP Pro 3.5.3 with no problems.

    After upgrading, I uninstalled Java and attempted to reinstall Java 7 using the latest download from Oracle, but they’ve moved to Update 55, while the package still looks for U51. According to http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html, U51 expires today (of all days).

    I tried installing Java 8, and CP Pro 3.6.3, but every time I try to start CP, the service just stops again, and the CPU goes 80-100% for a few minutes (java process being most of it). Any ideas? Or would it be possible to get the Java 7 package updated to U55?

    I’m running a DS211.

    Reply
      1. Jason

        Amazing. Thanks for the really quick turnaround on this. Once I installed Java 7 and rebooted the NAS (the key was to reboot it), Crashplan finally started working.

        For anyone else with the same issues: once I installed Java 7, CP would start for about 2 mins and then stop. Each time I restarted it, the same thing happened, until I rebooted the NAS.

  16. maximumfish

    I’m having a very similar issue to everyone else. DSM 4.3 on a DS1812+ shows Crashplan as running as it always has, but I thought I’d better check in to make sure it’s actually backing everything up before replacing a nearly-dead-but-not-yet-degraded disk. No connection. I checked my emailed backup reports (which I should really pay more attention to) to find that it hasn’t been backing up for over 60 days!

    Uninstalled/reinstalled Java to no avail. Uninstalled/reinstalled Crashplan and now every attempt to start it gives the “Wait a few seconds then stop and restart” message that you get when initially installing. Both DSM’s log and the package’s log folder are empty. Same thing happens with the ‘official’ Java install.

    Now my dilemma is do I replace the disk and hope that the rebuild runs without issue, or do I hold off until I can get Crashplan running and risk the disk dying in the meantime.

    Reply
    1. maximumfish

      All working again, should’ve tried a reboot before posting! And here was me thinking that “have you turned it off and on again” was a symptom of the Windows world.

      Reply
  17. franman

    After updating to Java 7 update 55 I have got the same issue with CP and DSM5. The packet starts for about 3 seconds and stops again.

    Reply
  18. Norm

    I have successfully installed Java1.7.0.55 (many thanks to Patters for the quick fix today)
    With CP 3.6.3.27 package installed and running.
    However, can not ever get CP on my Win8 PC to connect to the Synology unit. I have altered the properties.ui file to indicate the correct IP address.
    Am I missing any other step? CP simply stops at splash-screen and says “can’t connect to backup engine…retry?”

    Many thanks if anyone can suggest a fix.
    Using Synology DS214+ with DSM 5.0-4458 Update 2

    Reply
  19. G R

    Thanks patters for your work!

    I have Synology 713+ running CrashPlan 3.6.3-0027 with Java 1.7.0_51-0023 running on DSM 5.0-4458 Update 2.

    I have 3.4TB data to backup locally (through Gigabit LAN) and CrashPlan Central. CrashPlan recommends “Code42 typically recommends allocating 1 GB of memory per 1 TB of storage (or per 1 million files)”. It is working locally, but slow. I’m used to seeing ~35Mbps, but it is ~8Mbps once my data when about 3TB.

    When I attempted to raise the JAVA heap size to 4GB, I encounter an error.

    Error:
    Invalid maximum heap size: -Xmx4096m
    The specified size exceeds the maximum representable size.
    Error: Could not create the Java Virtual Machine.
    Error: A fatal exception has occurred. Program will exit.

    Reading through the JAVA SE embedded documentation, I found
    Solution:
    Using 32bit JVM therefore it can’t address more than 4GB (non inclusive). Try installing the 64 bit version

    Would using Java 8 give me 64 bit version I need to go above 4GB? I couldn’t find documentation on JAVA 8 that addressed this. Or is this a Synology implementation of JAVA issue?

    Reply
  20. Stephane

    Hi Patters,

    - DS213+
    - DSM 5.0-4458 Update 2
    - Java SE Embedded 7 (ejre-7u55-fcs-b13-linux-ppc-e500v2-headless-17_mar_2014.gz) from your package
    - CrashPlan 3.6.3-0027

    Impossible to get the client connected with my DS (backup engine issue).

    I stopped CrashPlan, re-started CrashPlan, rebooted the DS, uninstalled the client and re-installed it… Nothing nothing nothing works…

    Any idea ?

    Thanks in advance.

    Reply
    1. johnh5

      Same as Stephane, but DS1813+. INstalled Java 7 U55, restarted Crash Plan, and it connects and runs for a couple of minutes then crashes. Was working fine before the upgrade to DSM 5.

      Reply
  21. Peter

    I’ve used CrashPlan on other NAS platforms before but you have made the install EXTREMELY easy compared to my previous experience. Thanks for all your work!

    After successfully installing CrashPlan using your packages and connecting to the headless client on a DS412+ running DSM 5.0-4458 Update 2, I have noticed that there are certain system files that I am not able to backup because the crashplan daemon user account you create during the install is not in the root group. I understand that it is not advisable to run CrashPlan as root but is there a way to allow CrashPlan to backup files/directories owned by root and where the group owner of the file/directory is root?

    Thanks!

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s