UPDATE – CrashPlan For Home (green branding) was retired by Code 42 Software on 22/08/2017. See migration notes below to find out how to transfer to CrashPlan for Small Business on Synology at the special discounted rate.
CrashPlan is a popular online backup solution which supports continuous syncing. With this your NAS can become even more resilient, particularly against the threat of ransomware.
There are now only two product versions:
- Small Business: CrashPlan PRO (blue branding). Unlimited cloud backup subscription, $10 per device per month. Reporting via Admin Console. No peer-to-peer backups
- Enterprise: CrashPlan PROe (black branding). Cloud backup subscription typically billed by storage usage, also available from third parties.
The instructions and notes on this page apply to both versions of the Synology package.
CrashPlan is a Java application which can be difficult to install on a NAS. Way back in January 2012 I decided to simplify it into a Synology package, since I had already created several others. It has been through many versions since that time, as the changelog below shows. Although it used to work on Synology products with ARM and PowerPC CPUs, it unfortunately became Intel-only in October 2016 due to Code 42 Software adding a reliance on some proprietary libraries.
Licence compliance is another challenge – Code 42’s EULA prohibits redistribution. I had to make the Synology package use the regular CrashPlan for Linux download (after the end user agrees to the Code 42 EULA). I then had to write my own script to extract this archive and mimic the Code 42 installer behaviour, but without the interactive prompts of the original.
Synology Package Installation
- In Synology DSM’s Package Center, click Settings and add my package repository:
- The repository will push its certificate automatically to the NAS, which is used to validate package integrity. Set the Trust Level to Synology Inc. and trusted publishers:
- Now browse the Community section in Package Center to install CrashPlan:
The repository only displays packages which are compatible with your specific model of NAS. If you don’t see CrashPlan in the list, then either your NAS model or your DSM version are not supported at this time. DSM 5.0 is the minimum supported version for this package, and an Intel CPU is required. - Since CrashPlan is a Java application, it needs a Java Runtime Environment (JRE) to function. It is recommended that you select to have the package install a dedicated Java 8 runtime. For licensing reasons I cannot include Java with this package, so you will need to agree to the licence terms and download it yourself from Oracle’s website. The package expects to find this .tar.gz file in a shared folder called ‘public’. If you go ahead and try to install the package without it, the error message will indicate precisely which Java file you need for your system type, and it will provide a TinyURL link to the appropriate Oracle download page.
- To install CrashPlan PRO you will first need to log into the Admin Console and download the Linux App from the App Download section and also place this in the ‘public’ shared folder on your NAS.
- If you have a multi-bay NAS, use the Shared Folder control panel to create the shared folder called public (it must be all lower case). On single bay models this is created by default. Assign it with Read/Write privileges for everyone.
- If you have trouble getting the Java or CrashPlan PRO app files recognised by this package, try downloading them with Firefox. It seems to be the only web browser that doesn’t try to uncompress the files, or rename them without warning. I also suggest that you leave the Java file and the public folder present once you have installed the package, so that you won’t need to fetch this again to install future updates to the CrashPlan package.
- CrashPlan is installed in headless mode – backup engine only. This will configured by a desktop client, but operates independently of it.
- The first time you start the CrashPlan package you will need to stop it and restart it before you can connect the client. This is because a config file that is only created on first run needs to be edited by one of my scripts. The engine is then configured to listen on all interfaces on the default port 4243.
CrashPlan Client Installation
- Once the CrashPlan engine is running on the NAS, you can manage it by installing CrashPlan on another computer, and by configuring it to connect to the NAS instance of the CrashPlan Engine.
- Make sure that you install the version of the CrashPlan client that matches the version running on the NAS. If the NAS version gets upgraded later, you will need to update your client computer too.
- The Linux CrashPlan PRO client must be downloaded from the Admin Console and placed in the ‘public’ folder on your NAS in order to successfully install the Synology package.
- By default the client is configured to connect to the CrashPlan engine running on the local computer. Run this command on your NAS from an SSH session:
echo `cat /var/lib/crashplan/.ui_info`
Note those are backticks not quotes. This will give you a port number (4243), followed by an authentication token, followed by the IP binding (0.0.0.0 means the server is listening for connections on all interfaces) e.g.:
4243,9ac9b642-ba26-4578-b705-124c6efc920b,0.0.0.0
port,--------------token-----------------,binding
Copy this token value and use this value to replace the token in the equivalent config file on the computer that you would like to run the CrashPlan client on – located here:
C:\ProgramData\CrashPlan\.ui_info (Windows)
“/Library/Application Support/CrashPlan/.ui_info” (Mac OS X installed for all users)
“~/Library/Application Support/CrashPlan/.ui_info” (Mac OS X installed for single user)
/var/lib/crashplan/.ui_info (Linux)
You will not be able to connect the client unless the client token matches on the NAS token. On the client you also need to amend the IP address value after the token to match the Synology NAS IP address.
so using the example above, your computer’s CrashPlan client config file would be edited to:
4243,9ac9b642-ba26-4578-b705-124c6efc920b,192.168.1.100
assuming that the Synology NAS has the IP 192.168.1.100
If it still won’t connect, check that the ServicePort value is set to 4243 in the following files:
C:\ProgramData\CrashPlan\conf\ui_(username).properties (Windows)
“/Library/Application Support/CrashPlan/ui.properties” (Mac OS X installed for all users)
“~/Library/Application Support/CrashPlan/ui.properties” (Mac OS X installed for single user)
/usr/local/crashplan/conf (Linux)
/var/lib/crashplan/.ui_info (Synology) – this value does change spontaneously if there’s a port conflict e.g. you started two versions of the package concurrently (CrashPlan and CrashPlan PRO) - As a result of the nightmarish complexity of recent product changes Code42 has now published a support article with more detail on running headless systems including config file locations on all supported operating systems, and for ‘all users’ versus single user installs etc.
- You should disable the CrashPlan service on your computer if you intend only to use the client. In Windows, open the Services section in Computer Management and stop the CrashPlan Backup Service. In the service Properties set the Startup Type to Manual. You can also disable the CrashPlan System Tray notification application by removing it from Task Manager > More Details > Start-up Tab (Windows 8/Windows 10) or the All Users Startup Start Menu folder (Windows 7).
To accomplish the same on Mac OS X, run the following commands one by one:sudo launchctl unload /Library/LaunchDaemons/com.crashplan.engine.plist sudo mv /Library/LaunchDaemons/com.crashplan.engine.plist /Library/LaunchDaemons/com.crashplan.engine.plist.bak
The CrashPlan menu bar application can be disabled in System Preferences > Users & Groups > Current User > Login Items
Migration from CrashPlan For Home to CrashPlan For Small Business (CrashPlan PRO)
- Leave the regular green branded CrashPlan 4.8.3 Synology package installed.
- Go through the online migration using the link in the email notification you received from Code 42 on 22/08/2017. This seems to trigger the CrashPlan client to begin an update to 4.9 which will fail. It will also migrate your account onto a CrashPlan PRO server. The web page is likely to stall on the Migrating step, but no matter. The process is meant to take you to the store but it seems to be quite flakey. If you see the store page with a $0.00 amount in the basket, this has correctly referred you for the introductory offer. Apparently the $9.99 price thereafter shown on that screen is a mistake and the correct price of $2.50 is shown on a later screen in the process I think. Enter your credit card details and check out if you can. If not, continue.
- Log into the CrashPlan PRO Admin Console as per these instructions, and download the CrashPlan PRO 4.9 client for Linux, and the 4.9 client for your remote console computer. Ignore the red message in the bottom left of the Admin Console about registering, and do not sign up for the free trial. Preferably use Firefox for the Linux version download – most of the other web browsers will try to unpack the .tgz archive, which you do not want to happen.
- Configure the CrashPlan PRO 4.9 client on your computer to connect to your Syno as per the usual instructions on this blog post.
- Put the downloaded Linux CrashPlan PRO 4.9 client .tgz file in the ‘public’ shared folder on your NAS. The package will no longer download this automatically as it did in previous versions.
- From the Community section of DSM Package Center, install the CrashPlan PRO 4.9 package concurrently with your existing CrashPlan 4.8.3 Syno package.
- This will stop the CrashPlan package and automatically import its configuration. Notice that it will also backup your old CrashPlan .identity file and leave it in the ‘public’ shared folder, just in case something goes wrong.
- Start the CrashPlan PRO Synology package, and connect your CrashPlan PRO console from your computer.
- You should see your protected folders as usual. At first mine reported something like “insufficient device licences”, but the next time I started up it changed to “subscription expired”.
- Uninstall the CrashPlan 4.8.3 Synology package, this is no longer required.
- At this point if the store referral didn’t work in the second step, you need to sign into the Admin Console. While signed in, navigate to this link which I was given by Code 42 support. If it works, you should see a store page with some blue font text and a $0.00 basket value. If it didn’t work you will get bounced to the Consumer Next Steps webpage: “Important Changes to CrashPlan for Home” – the one with the video of the CEO explaining the situation. I had to do this a few times before it worked. Once the store referral link worked and I had confirmed my payment details my CrashPlan PRO client immediately started working. Enjoy!
Notes
- The package uses the intact CrashPlan installer directly from Code 42 Software, following acceptance of its EULA. I am complying with the directive that no one redistributes it.
- The engine daemon script checks the amount of system RAM and scales the Java heap size appropriately (up to the default maximum of 512MB). This can be overridden in a persistent way if you are backing up large backup sets by editing /var/packages/CrashPlan/target/syno_package.vars. If you are considering buying a NAS purely to use CrashPlan and intend to back up more than a few hundred GB then I strongly advise buying one of the models with upgradeable RAM. Memory is very limited on the cheaper models. I have found that a 512MB heap was insufficient to back up more than 2TB of files on a Windows server and that was the situation many years ago. It kept restarting the backup engine every few minutes until I increased the heap to 1024MB. Many users of the package have found that they have to increase the heap size or CrashPlan will halt its activity. This can be mitigated by dividing your backup into several smaller backup sets which are scheduled to be protected at different times. Note that from package version 0041, using the dedicated JRE on a 64bit Intel NAS will allow a heap size greater than 4GB since the JRE is 64bit (requires DSM 6.0 in most cases).
- If you need to manage CrashPlan from a remote location, I suggest you do so using SSH tunnelling as per this support document.
- The package supports upgrading to future versions while preserving the machine identity, logs, login details, and cache. Upgrades can now take place without requiring a login from the client afterwards.
- If you remove the package completely and re-install it later, you can re-attach to previous backups. When you log in to the Desktop Client with your existing account after a re-install, you can select “adopt computer” to merge the records, and preserve your existing backups. I haven’t tested whether this also re-attaches links to friends’ CrashPlan computers and backup sets, though the latter does seem possible in the Friends section of the GUI. It’s probably a good idea to test that this survives a package reinstall before you start relying on it. Sometimes, particularly with CrashPlan PRO I think, the adopt option is not offered. In this case you can log into CrashPlan Central and retrieve your computer’s GUID. On the CrashPlan client, double-click on the logo in the top right and you’ll enter a command line mode. You can use the GUID command to change the system’s GUID to the one you just retrieved from your account.
- The log which is displayed in the package’s Log tab is actually the activity history. If you are trying to troubleshoot an issue you will need to use an SSH session to inspect these log files:
/var/packages/CrashPlan/target/log/engine_output.log
/var/packages/CrashPlan/target/log/engine_error.log
/var/packages/CrashPlan/target/log/app.log - When CrashPlan downloads and attempts to run an automatic update, the script will most likely fail and stop the package. This is typically caused by syntax differences with the Synology versions of certain Linux shell commands (like rm, mv, or ps). The startup script will attempt to apply the published upgrade the next time the package is started.
- Although CrashPlan’s activity can be scheduled within the application, in order to save RAM some users may wish to restrict running the CrashPlan engine to specific times of day using the Task Scheduler in DSM Control Panel:
Note that regardless of real-time backup, by default CrashPlan will scan the whole backup selection for changes at 3:00am. Include this time within your Task Scheduler time window or else CrashPlan will not capture file changes which occurred while it was inactive:
- If you decide to sign up for one of CrashPlan’s paid backup services as a result of my work on this, please consider donating using the PayPal button on the right of this page.
Package scripts
For information, here are the package scripts so you can see what it’s going to do. You can get more information about how packages work by reading the Synology 3rd Party Developer Guide.
installer.sh
#!/bin/sh
#--------CRASHPLAN installer script
#--------package maintained at pcloadletter.co.uk
DOWNLOAD_PATH="http://download2.code42.com/installs/linux/install/${SYNOPKG_PKGNAME}"
CP_EXTRACTED_FOLDER="crashplan-install"
OLD_JNA_NEEDED="false"
[ "${SYNOPKG_PKGNAME}" == "CrashPlan" ] && DOWNLOAD_FILE="CrashPlan_4.8.3_Linux.tgz"
[ "${SYNOPKG_PKGNAME}" == "CrashPlanPRO" ] && DOWNLOAD_FILE="CrashPlanPRO_4.*_Linux.tgz"
if [ "${SYNOPKG_PKGNAME}" == "CrashPlanPROe" ]; then
CP_EXTRACTED_FOLDER="${SYNOPKG_PKGNAME}-install"
OLD_JNA_NEEDED="true"
[ "${WIZARD_VER_483}" == "true" ] && { CPPROE_VER="4.8.3"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
[ "${WIZARD_VER_480}" == "true" ] && { CPPROE_VER="4.8.0"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
[ "${WIZARD_VER_470}" == "true" ] && { CPPROE_VER="4.7.0"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
[ "${WIZARD_VER_460}" == "true" ] && { CPPROE_VER="4.6.0"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
[ "${WIZARD_VER_452}" == "true" ] && { CPPROE_VER="4.5.2"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
[ "${WIZARD_VER_450}" == "true" ] && { CPPROE_VER="4.5.0"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
[ "${WIZARD_VER_441}" == "true" ] && { CPPROE_VER="4.4.1"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
[ "${WIZARD_VER_430}" == "true" ] && CPPROE_VER="4.3.0"
[ "${WIZARD_VER_420}" == "true" ] && CPPROE_VER="4.2.0"
[ "${WIZARD_VER_370}" == "true" ] && CPPROE_VER="3.7.0"
[ "${WIZARD_VER_364}" == "true" ] && CPPROE_VER="3.6.4"
[ "${WIZARD_VER_363}" == "true" ] && CPPROE_VER="3.6.3"
[ "${WIZARD_VER_3614}" == "true" ] && CPPROE_VER="3.6.1.4"
[ "${WIZARD_VER_353}" == "true" ] && CPPROE_VER="3.5.3"
[ "${WIZARD_VER_341}" == "true" ] && CPPROE_VER="3.4.1"
[ "${WIZARD_VER_33}" == "true" ] && CPPROE_VER="3.3"
DOWNLOAD_FILE="CrashPlanPROe_${CPPROE_VER}_Linux.tgz"
fi
DOWNLOAD_URL="${DOWNLOAD_PATH}/${DOWNLOAD_FILE}"
CPI_FILE="${SYNOPKG_PKGNAME}_*.cpi"
OPTDIR="${SYNOPKG_PKGDEST}"
VARS_FILE="${OPTDIR}/install.vars"
SYNO_CPU_ARCH="`uname -m`"
[ "${SYNO_CPU_ARCH}" == "x86_64" ] && SYNO_CPU_ARCH="i686"
[ "${SYNO_CPU_ARCH}" == "armv5tel" ] && SYNO_CPU_ARCH="armel"
[ "${SYNOPKG_DSM_ARCH}" == "armada375" ] && SYNO_CPU_ARCH="armv7l"
[ "${SYNOPKG_DSM_ARCH}" == "armada38x" ] && SYNO_CPU_ARCH="armhf"
[ "${SYNOPKG_DSM_ARCH}" == "comcerto2k" ] && SYNO_CPU_ARCH="armhf"
[ "${SYNOPKG_DSM_ARCH}" == "alpine" ] && SYNO_CPU_ARCH="armhf"
[ "${SYNOPKG_DSM_ARCH}" == "alpine4k" ] && SYNO_CPU_ARCH="armhf"
[ "${SYNOPKG_DSM_ARCH}" == "monaco" ] && SYNO_CPU_ARCH="armhf"
[ "${SYNOPKG_DSM_ARCH}" == "rtd1296" ] && SYNO_CPU_ARCH="armhf"
NATIVE_BINS_URL="http://packages.pcloadletter.co.uk/downloads/crashplan-native-${SYNO_CPU_ARCH}.tar.xz"
NATIVE_BINS_FILE="`echo ${NATIVE_BINS_URL} | sed -r "s%^.*/(.*)%\1%"`"
OLD_JNA_URL="http://packages.pcloadletter.co.uk/downloads/crashplan-native-old-${SYNO_CPU_ARCH}.tar.xz"
OLD_JNA_FILE="`echo ${OLD_JNA_URL} | sed -r "s%^.*/(.*)%\1%"`"
INSTALL_FILES="${DOWNLOAD_URL} ${NATIVE_BINS_URL}"
[ "${OLD_JNA_NEEDED}" == "true" ] && INSTALL_FILES="${INSTALL_FILES} ${OLD_JNA_URL}"
TEMP_FOLDER="`find / -maxdepth 2 -path '/volume?/@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"
PUBLIC_FOLDER="`synoshare --get public | sed -r "/Path/!d;s/^.*\[(.*)\].*$/\1/"`"
#dedicated JRE section
if [ "${WIZARD_JRE_CP}" == "true" ]; then
DOWNLOAD_URL="http://tinyurl.com/javaembed"
EXTRACTED_FOLDER="ejdk1.8.0_151"
#detect systems capable of running 64bit JRE which can address more than 4GB of RAM
[ "${SYNOPKG_DSM_ARCH}" == "x64" ] && SYNO_CPU_ARCH="x64"
[ "`uname -m`" == "x86_64" ] && [ ${SYNOPKG_DSM_VERSION_MAJOR} -ge 6 ] && SYNO_CPU_ARCH="x64"
if [ "${SYNO_CPU_ARCH}" == "armel" ]; then
JAVA_BINARY="ejdk-8u151-linux-arm-sflt.tar.gz"
JAVA_BUILD="ARMv5/ARMv6/ARMv7 Linux - SoftFP ABI, Little Endian 2"
elif [ "${SYNO_CPU_ARCH}" == "armv7l" ]; then
JAVA_BINARY="ejdk-8u151-linux-arm-sflt.tar.gz"
JAVA_BUILD="ARMv5/ARMv6/ARMv7 Linux - SoftFP ABI, Little Endian 2"
elif [ "${SYNO_CPU_ARCH}" == "armhf" ]; then
JAVA_BINARY="ejdk-8u151-linux-armv6-vfp-hflt.tar.gz"
JAVA_BUILD="ARMv6/ARMv7 Linux - VFP, HardFP ABI, Little Endian 1"
elif [ "${SYNO_CPU_ARCH}" == "ppc" ]; then
#Oracle have discontinued Java 8 for PowerPC after update 6
JAVA_BINARY="ejdk-8u6-fcs-b23-linux-ppc-e500v2-12_jun_2014.tar.gz"
JAVA_BUILD="Power Architecture Linux - Headless - e500v2 with double-precision SPE Floating Point Unit"
EXTRACTED_FOLDER="ejdk1.8.0_06"
DOWNLOAD_URL="http://tinyurl.com/java8ppc"
elif [ "${SYNO_CPU_ARCH}" == "i686" ]; then
JAVA_BINARY="ejdk-8u151-linux-i586.tar.gz"
JAVA_BUILD="x86 Linux Small Footprint - Headless"
elif [ "${SYNO_CPU_ARCH}" == "x64" ]; then
JAVA_BINARY="jre-8u151-linux-x64.tar.gz"
JAVA_BUILD="Linux x64"
EXTRACTED_FOLDER="jre1.8.0_151"
DOWNLOAD_URL="http://tinyurl.com/java8x64"
fi
fi
JAVA_BINARY=`echo ${JAVA_BINARY} | cut -f1 -d'.'`
source /etc/profile
pre_checks ()
{
#These checks are called from preinst and from preupgrade functions to prevent failures resulting in a partially upgraded package
if [ "${WIZARD_JRE_CP}" == "true" ]; then
synoshare -get public > /dev/null || (
echo "A shared folder called 'public' could not be found - note this name is case-sensitive. " >> $SYNOPKG_TEMP_LOGFILE
echo "Please create this using the Shared Folder DSM Control Panel and try again." >> $SYNOPKG_TEMP_LOGFILE
exit 1
)
JAVA_BINARY_FOUND=
[ -f ${PUBLIC_FOLDER}/${JAVA_BINARY}.tar.gz ] && JAVA_BINARY_FOUND=true
[ -f ${PUBLIC_FOLDER}/${JAVA_BINARY}.tar ] && JAVA_BINARY_FOUND=true
[ -f ${PUBLIC_FOLDER}/${JAVA_BINARY}.tar.tar ] && JAVA_BINARY_FOUND=true
[ -f ${PUBLIC_FOLDER}/${JAVA_BINARY}.gz ] && JAVA_BINARY_FOUND=true
if [ -z ${JAVA_BINARY_FOUND} ]; then
echo "Java binary bundle not found. " >> $SYNOPKG_TEMP_LOGFILE
echo "I was expecting the file ${PUBLIC_FOLDER}/${JAVA_BINARY}.tar.gz. " >> $SYNOPKG_TEMP_LOGFILE
echo "Please agree to the Oracle licence at ${DOWNLOAD_URL}, then download the '${JAVA_BUILD}' package" >> $SYNOPKG_TEMP_LOGFILE
echo "and place it in the 'public' shared folder on your NAS. This download cannot be automated even if " >> $SYNOPKG_TEMP_LOGFILE
echo "displaying a package EULA could potentially cover the legal aspect, because files hosted on Oracle's " >> $SYNOPKG_TEMP_LOGFILE
echo "server are protected by a session cookie requiring a JavaScript enabled browser." >> $SYNOPKG_TEMP_LOGFILE
exit 1
fi
else
if [ -z ${JAVA_HOME} ]; then
echo "Java is not installed or not properly configured. JAVA_HOME is not defined. " >> $SYNOPKG_TEMP_LOGFILE
echo "Download and install the Java Synology package from http://wp.me/pVshC-z5" >> $SYNOPKG_TEMP_LOGFILE
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. " >> $SYNOPKG_TEMP_LOGFILE
echo "Download and install the Java Synology package from http://wp.me/pVshC-z5" >> $SYNOPKG_TEMP_LOGFILE
exit 1
fi
if [ "${WIZARD_JRE_SYS}" == "true" ]; then
JAVA_VER=`java -version 2>&1 | sed -r "/^.* version/!d;s/^.* version \"[0-9]\.([0-9]).*$/\1/"`
if [ ${JAVA_VER} -lt 8 ]; then
echo "This version of CrashPlan requires Java 8 or newer. Please update your Java package. "
exit 1
fi
fi
fi
}
preinst ()
{
pre_checks
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, " >> $SYNOPKG_TEMP_LOGFILE
echo "which was \"${WGET_URL}\" " >> $SYNOPKG_TEMP_LOGFILE
echo "Alternatively, you may download this file manually and place it in the 'public' shared folder. " >> $SYNOPKG_TEMP_LOGFILE
exit 1
fi
fi
done
exit 0
}
postinst ()
{
if [ "${WIZARD_JRE_CP}" == "true" ]; then
#extract Java (Web browsers love to interfere with .tar.gz files)
cd ${PUBLIC_FOLDER}
if [ -f ${JAVA_BINARY}.tar.gz ]; then
#Firefox seems to be the only browser that leaves it alone
tar xzf ${JAVA_BINARY}.tar.gz
elif [ -f ${JAVA_BINARY}.gz ]; then
#Chrome
tar xzf ${JAVA_BINARY}.gz
elif [ -f ${JAVA_BINARY}.tar ]; then
#Safari
tar xf ${JAVA_BINARY}.tar
elif [ -f ${JAVA_BINARY}.tar.tar ]; then
#Internet Explorer
tar xzf ${JAVA_BINARY}.tar.tar
fi
mv ${EXTRACTED_FOLDER} ${SYNOPKG_PKGDEST}/jre-syno
JRE_PATH="`find ${OPTDIR}/jre-syno/ -name jre`"
[ -z ${JRE_PATH} ] && JRE_PATH=${OPTDIR}/jre-syno
#change owner of folder tree
chown -R root:root ${SYNOPKG_PKGDEST}
fi
#extract CPU-specific additional binaries
mkdir ${SYNOPKG_PKGDEST}/bin
cd ${SYNOPKG_PKGDEST}/bin
tar xJf ${TEMP_FOLDER}/${NATIVE_BINS_FILE} && rm ${TEMP_FOLDER}/${NATIVE_BINS_FILE}
[ "${OLD_JNA_NEEDED}" == "true" ] && tar xJf ${TEMP_FOLDER}/${OLD_JNA_FILE} && rm ${TEMP_FOLDER}/${OLD_JNA_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}/${CP_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 1024M if you're backing up extremely large volumes of files" >> ${SYNOPKG_PKGDEST}/syno_package.vars
echo "#USR_MAX_HEAP=1024M" >> ${SYNOPKG_PKGDEST}/syno_package.vars
echo >> ${SYNOPKG_PKGDEST}/syno_package.vars
cp ${TEMP_FOLDER}/${CP_EXTRACTED_FOLDER}/scripts/CrashPlanEngine ${OPTDIR}/bin
cp ${TEMP_FOLDER}/${CP_EXTRACTED_FOLDER}/scripts/run.conf ${OPTDIR}/bin
mkdir -p ${MANIFEST_FOLDER}/backupArchives
#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}
[ "${WIZARD_JRE_CP}" == "true" ] && echo JAVACOMMON=${JRE_PATH}/bin/java >> ${VARS_FILE}
[ "${WIZARD_JRE_SYS}" == "true" ] && echo JAVACOMMON=\${JAVA_HOME}/bin/java >> ${VARS_FILE}
cat ${TEMP_FOLDER}/${CP_EXTRACTED_FOLDER}/install.defaults >> ${VARS_FILE}
#remove temp files
rm -r ${TEMP_FOLDER}/${CP_EXTRACTED_FOLDER}
#add firewall config
/usr/syno/bin/servicetool --install-configure-file --package /var/packages/${SYNOPKG_PKGNAME}/scripts/${SYNOPKG_PKGNAME}.sc > /dev/null
#amend CrashPlanPROe client version
[ "${SYNOPKG_PKGNAME}" == "CrashPlanPROe" ] && sed -i -r "s/^version=\".*(-.*$)/version=\"${CPPROE_VER}\1/" /var/packages/${SYNOPKG_PKGNAME}/INFO
#are we transitioning an existing CrashPlan account to CrashPlan For Small Business?
if [ "${SYNOPKG_PKGNAME}" == "CrashPlanPRO" ]; then
if [ -e /var/packages/CrashPlan/scripts/start-stop-status ]; then
/var/packages/CrashPlan/scripts/start-stop-status stop
cp /var/lib/crashplan/.identity ${PUBLIC_FOLDER}/crashplan-identity.bak
cp -R /var/packages/CrashPlan/target/conf/ ${OPTDIR}/
fi
fi
exit 0
}
preuninst ()
{
`dirname $0`/stop-start-status stop
exit 0
}
postuninst ()
{
if [ -f ${SYNOPKG_PKGDEST}/syno_package.vars ]; then
source ${SYNOPKG_PKGDEST}/syno_package.vars
fi
[ -e ${OPTDIR}/lib/libffi.so.5 ] && rm ${OPTDIR}/lib/libffi.so.5
#delete symlink if it no longer resolves - PowerPC only
if [ ! -e /lib/libffi.so.5 ]; then
[ -L /lib/libffi.so.5 ] && rm /lib/libffi.so.5
fi
#remove firewall config
if [ "${SYNOPKG_PKG_STATUS}" == "UNINSTALL" ]; then
/usr/syno/bin/servicetool --remove-configure-file --package ${SYNOPKG_PKGNAME}.sc > /dev/null
fi
exit 0
}
preupgrade ()
{
`dirname $0`/stop-start-status stop
pre_checks
#if identity exists back up config
if [ -f /var/lib/crashplan/.identity ]; then
mkdir -p ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/conf
for FILE_TO_MIGRATE in ${UPGRADE_FILES}; do
if [ -f ${OPTDIR}/${FILE_TO_MIGRATE} ]; then
cp ${OPTDIR}/${FILE_TO_MIGRATE} ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_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}/../${SYNOPKG_PKGNAME}_data_mig
fi
done
fi
exit 0
}
postupgrade ()
{
#use the migrated identity and config data from the previous version
if [ -f ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/conf/my.service.xml ]; then
for FILE_TO_MIGRATE in ${UPGRADE_FILES}; do
if [ -f ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/${FILE_TO_MIGRATE} ]; then
mv ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/${FILE_TO_MIGRATE} ${OPTDIR}/${FILE_TO_MIGRATE}
fi
done
for FOLDER_TO_MIGRATE in ${UPGRADE_FOLDERS}; do
if [ -d ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/${FOLDER_TO_MIGRATE} ]; then
mv ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/${FOLDER_TO_MIGRATE} ${OPTDIR}
fi
done
rmdir ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/conf
rmdir ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig
#make CrashPlan log entry
TIMESTAMP="`date "+%D %I:%M%p"`"
echo "I ${TIMESTAMP} Synology Package Center updated ${SYNOPKG_PKGNAME} to version ${SYNOPKG_PKGVER}" >> ${LOG_FILE}
fi
exit 0
}
start-stop-status.sh
#!/bin/sh
#--------CRASHPLAN start-stop-status script
#--------package maintained at pcloadletter.co.uk
TEMP_FOLDER="`find / -maxdepth 2 -path '/volume?/@tmp' | head -n 1`"
MANIFEST_FOLDER="/`echo $TEMP_FOLDER | cut -f2 -d'/'`/crashplan"
ENGINE_CFG="run.conf"
PKG_FOLDER="`dirname $0 | cut -f1-4 -d'/'`"
DNAME="`dirname $0 | cut -f4 -d'/'`"
OPTDIR="${PKG_FOLDER}/target"
PID_FILE="${OPTDIR}/${DNAME}.pid"
DLOG="${OPTDIR}/log/history.log.0"
CFG_PARAM="SRV_JAVA_OPTS"
JAVA_MIN_HEAP=`grep "^${CFG_PARAM}=" "${OPTDIR}/bin/${ENGINE_CFG}" | sed -r "s/^.*-Xms([0-9]+)[Mm] .*$/\1/"`
SYNO_CPU_ARCH="`uname -m`"
TIMESTAMP="`date "+%D %I:%M%p"`"
FULL_CP="${OPTDIR}/lib/com.backup42.desktop.jar:${OPTDIR}/lang"
source ${OPTDIR}/install.vars
source /etc/profile
source /root/.profile
start_daemon ()
{
#check persistent variables from syno_package.vars
USR_MAX_HEAP=0
if [ -f ${OPTDIR}/syno_package.vars ]; then
source ${OPTDIR}/syno_package.vars
fi
USR_MAX_HEAP=`echo $USR_MAX_HEAP | sed -e "s/[mM]//"`
#do we need to restore the identity file - has a DSM upgrade scrubbed /var/lib/crashplan?
if [ ! -e /var/lib/crashplan ]; then
mkdir /var/lib/crashplan
[ -e ${OPTDIR}/conf/var-backup/.identity ] && cp ${OPTDIR}/conf/var-backup/.identity /var/lib/crashplan/
fi
#fix up some of the binary paths and fix some command syntax for busybox
#moved this to start-stop-status.sh from installer.sh because Code42 push updates and these
#new scripts will need this treatment too
find ${OPTDIR}/ -name "*.sh" | 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%#!$/bin/sh%" "${FILE_TO_EDIT}"
sed -i -r "s%(^\s*)(/bin/cpio |cpio ) %\1/${OPTDIR}/bin/cpio %" "${FILE_TO_EDIT}"
sed -i -r "s%(^\s*)(/bin/ps|ps) [^w][^\|]*\|%\1/bin/ps w \|%" "${FILE_TO_EDIT}"
sed -i -r "s%\`ps [^w][^\|]*\|%\`ps w \|%" "${FILE_TO_EDIT}"
sed -i -r "s%^ps [^w][^\|]*\|%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
#use this daemon init script rather than the unreliable Code42 stock one which greps the ps output
sed -i "s%^ENGINE_SCRIPT=.*$%ENGINE_SCRIPT=$0%" ${OPTDIR}/bin/restartLinux.sh
#any downloaded upgrade script will usually have failed despite the above changes
#so ignore the script and explicitly extract the new java code using the chrisnelson.ca method
#thanks to Jeff Bingham for tweaks
UPGRADE_JAR=`find ${OPTDIR}/upgrade -maxdepth 1 -name "*.jar" | tail -1`
if [ -n "${UPGRADE_JAR}" ]; then
rm ${OPTDIR}/*.pid > /dev/null
#make CrashPlan log entry
echo "I ${TIMESTAMP} Synology extracting upgrade from ${UPGRADE_JAR}" >> ${DLOG}
UPGRADE_VER=`echo ${SCRIPT_HOME} | sed -r "s/^.*\/([0-9_]+)\.[0-9]+/\1/"`
#DSM 6.0 no longer includes unzip, use 7z instead
unzip -o ${OPTDIR}/upgrade/${UPGRADE_VER}.jar "*.jar" -d ${OPTDIR}/lib/ || 7z e -y ${OPTDIR}/upgrade/${UPGRADE_VER}.jar "*.jar" -o${OPTDIR}/lib/ > /dev/null
unzip -o ${OPTDIR}/upgrade/${UPGRADE_VER}.jar "lang/*" -d ${OPTDIR} || 7z e -y ${OPTDIR}/upgrade/${UPGRADE_VER}.jar "lang/*" -o${OPTDIR} > /dev/null
mv ${UPGRADE_JAR} ${TEMP_FOLDER}/ > /dev/null
exec $0
fi
#updates may also overwrite our native binaries
[ -e ${OPTDIR}/bin/libffi.so.5 ] && cp -f ${OPTDIR}/bin/libffi.so.5 ${OPTDIR}/lib/
[ -e ${OPTDIR}/bin/libjtux.so ] && cp -f ${OPTDIR}/bin/libjtux.so ${OPTDIR}/
[ -e ${OPTDIR}/bin/jna-3.2.5.jar ] && cp -f ${OPTDIR}/bin/jna-3.2.5.jar ${OPTDIR}/lib/
if [ -e ${OPTDIR}/bin/jna.jar ] && [ -e ${OPTDIR}/lib/jna.jar ]; then
cp -f ${OPTDIR}/bin/jna.jar ${OPTDIR}/lib/
fi
#create or repair libffi.so.5 symlink if a DSM upgrade has removed it - PowerPC only
if [ -e ${OPTDIR}/lib/libffi.so.5 ]; then
if [ ! -e /lib/libffi.so.5 ]; then
#if it doesn't exist, but is still a link then it's a broken link and should be deleted first
[ -L /lib/libffi.so.5 ] && rm /lib/libffi.so.5
ln -s ${OPTDIR}/lib/libffi.so.5 /lib/libffi.so.5
fi
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
elif [ $RAM -le 1024 ]; then
JAVA_MAX_HEAP=512
elif [ $RAM -gt 1024 ]; then
JAVA_MAX_HEAP=1024
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 PPC CPUs
#seems to be the default behaviour now but that may change again
[ "${SYNO_CPU_ARCH}" == "x86_64" ] && SYNO_CPU_ARCH="i686"
if [ "${SYNO_CPU_ARCH}" != "i686" ]; 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}"
#now edit the XML config file, which only exists after first run
if [ -f ${OPTDIR}/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>/" "${OPTDIR}/conf/my.service.xml"
#default changed in CrashPlan 4.3
sed -i "s/<serviceHost>localhost<\/serviceHost>/<serviceHost>0\.0\.0\.0<\/serviceHost>/" "${OPTDIR}/conf/my.service.xml"
#since CrashPlan 4.4 another config file to allow remote console connections
sed -i "s/127\.0\.0\.1/0\.0\.0\.0/" /var/lib/crashplan/.ui_info
#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>%" "${OPTDIR}/conf/my.service.xml"
echo "MANIFEST_PATH_SET=True" >> ${OPTDIR}/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%" "${OPTDIR}/conf/my.service.xml"
#make sure CrashPlan is not binding to the IPv6 stack
grep "\-Djava\.net\.preferIPv4Stack=true" "${OPTDIR}/bin/${ENGINE_CFG}" > /dev/null \
|| sed -i -r "s/(^${CFG_PARAM}=\".*)\"$/\1 -Djava.net.preferIPv4Stack=true\"/" "${OPTDIR}/bin/${ENGINE_CFG}"
else
echo "Check the package log to ensure the package has started successfully, then stop and restart the package to allow desktop client connections." > "${SYNOPKG_TEMP_LOGFILE}"
fi
#increase the system-wide maximum number of open files from Synology default of 24466
[ `cat /proc/sys/fs/file-max` -lt 65536 ] && 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
#ensure that Code 42 have not amended install.vars to force the use of their own (Intel) JRE
if [ -e ${OPTDIR}/jre-syno ]; then
JRE_PATH="`find ${OPTDIR}/jre-syno/ -name jre`"
[ -z ${JRE_PATH} ] && JRE_PATH=${OPTDIR}/jre-syno
sed -i -r "s|^(JAVACOMMON=).*$|\1\${JRE_PATH}/bin/java|" ${OPTDIR}/install.vars
#if missing, set timezone and locale for dedicated JRE
if [ -z ${TZ} ]; then
SYNO_TZ=`cat /etc/synoinfo.conf | grep timezone | cut -f2 -d'"'`
#fix for DST time in DSM 5.2 thanks to MinimServer Syno package author
[ -e /usr/share/zoneinfo/Timezone/synotztable.json ] \
&& SYNO_TZ=`jq ".${SYNO_TZ} | .nameInTZDB" /usr/share/zoneinfo/Timezone/synotztable.json | sed -e "s/\"//g"` \
|| SYNO_TZ=`grep "^${SYNO_TZ}" /usr/share/zoneinfo/Timezone/tzname | sed -e "s/^.*= //"`
export TZ=${SYNO_TZ}
fi
[ -z ${LANG} ] && export LANG=en_US.utf8
export CLASSPATH=.:${OPTDIR}/jre-syno/lib
else
sed -i -r "s|^(JAVACOMMON=).*$|\1\${JAVA_HOME}/bin/java|" ${OPTDIR}/install.vars
fi
source ${OPTDIR}/bin/run.conf
source ${OPTDIR}/install.vars
cd ${OPTDIR}
$JAVACOMMON $SRV_JAVA_OPTS -classpath $FULL_CP com.backup42.service.CPService > ${OPTDIR}/log/engine_output.log 2> ${OPTDIR}/log/engine_error.log &
if [ $! -gt 0 ]; then
echo $! > $PID_FILE
renice 19 $! > /dev/null
if [ -z "${SYNOPKG_PKGDEST}" ]; then
#script was manually invoked, need this to show status change in Package Center
[ -e ${PKG_FOLDER}/enabled ] || touch ${PKG_FOLDER}/enabled
fi
else
echo "${DNAME} failed to start, check ${OPTDIR}/log/engine_error.log" > "${SYNOPKG_TEMP_LOGFILE}"
echo "${DNAME} failed to start, check ${OPTDIR}/log/engine_error.log" >&2
exit 1
fi
}
stop_daemon ()
{
echo "I ${TIMESTAMP} Stopping ${DNAME}" >> ${DLOG}
kill `cat ${PID_FILE}`
wait_for_status 1 20 || kill -9 `cat ${PID_FILE}`
rm -f ${PID_FILE}
if [ -z ${SYNOPKG_PKGDEST} ]; then
#script was manually invoked, need this to show status change in Package Center
[ -e ${PKG_FOLDER}/enabled ] && rm ${PKG_FOLDER}/enabled
fi
#backup identity file in case DSM upgrade removes it
[ -e ${OPTDIR}/conf/var-backup ] || mkdir ${OPTDIR}/conf/var-backup
cp /var/lib/crashplan/.identity ${OPTDIR}/conf/var-backup/
}
daemon_status ()
{
if [ -f ${PID_FILE} ] && kill -0 `cat ${PID_FILE}` > /dev/null 2>&1; then
return
fi
rm -f ${PID_FILE}
return 1
}
wait_for_status ()
{
counter=$2
while [ ${counter} -gt 0 ]; do
daemon_status
[ $? -eq $1 ] && return
let counter=counter-1
sleep 1
done
return 1
}
case $1 in
start)
if daemon_status; then
echo ${DNAME} is already running with PID `cat ${PID_FILE}`
exit 0
else
echo Starting ${DNAME} ...
start_daemon
exit $?
fi
;;
stop)
if daemon_status; then
echo Stopping ${DNAME} ...
stop_daemon
exit $?
else
echo ${DNAME} is not running
exit 0
fi
;;
restart)
stop_daemon
start_daemon
exit $?
;;
status)
if daemon_status; then
echo ${DNAME} is running with PID `cat ${PID_FILE}`
exit 0
else
echo ${DNAME} is not running
exit 1
fi
;;
log)
echo "${DLOG}"
exit 0
;;
*)
echo "Usage: $0 {start|stop|status|restart}" >&2
exit 1
;;
esac
install_uifile & upgrade_uifile
[
{
"step_title": "Client Version Selection",
"items": [
{
"type": "singleselect",
"desc": "Please select the CrashPlanPROe client version that is appropriate for your backup destination server:",
"subitems": [
{
"key": "WIZARD_VER_483",
"desc": "4.8.3",
"defaultValue": true
}, {
"key": "WIZARD_VER_480",
"desc": "4.8.0",
"defaultValue": false
},
{
"key": "WIZARD_VER_470",
"desc": "4.7.0",
"defaultValue": false
},
{
"key": "WIZARD_VER_460",
"desc": "4.6.0",
"defaultValue": false
},
{
"key": "WIZARD_VER_452",
"desc": "4.5.2",
"defaultValue": false
},
{
"key": "WIZARD_VER_450",
"desc": "4.5.0",
"defaultValue": false
},
{
"key": "WIZARD_VER_441",
"desc": "4.4.1",
"defaultValue": false
},
{
"key": "WIZARD_VER_430",
"desc": "4.3.0",
"defaultValue": false
},
{
"key": "WIZARD_VER_420",
"desc": "4.2.0",
"defaultValue": false
},
{
"key": "WIZARD_VER_370",
"desc": "3.7.0",
"defaultValue": false
},
{
"key": "WIZARD_VER_364",
"desc": "3.6.4",
"defaultValue": false
},
{
"key": "WIZARD_VER_363",
"desc": "3.6.3",
"defaultValue": false
},
{
"key": "WIZARD_VER_3614",
"desc": "3.6.1.4",
"defaultValue": false
},
{
"key": "WIZARD_VER_353",
"desc": "3.5.3",
"defaultValue": false
},
{
"key": "WIZARD_VER_341",
"desc": "3.4.1",
"defaultValue": false
},
{
"key": "WIZARD_VER_33",
"desc": "3.3",
"defaultValue": false
}
]
}
]
},
{
"step_title": "Java Runtime Environment Selection",
"items": [
{
"type": "singleselect",
"desc": "Please select the Java version which you would like CrashPlan to use:",
"subitems": [
{
"key": "WIZARD_JRE_SYS",
"desc": "Default system Java version",
"defaultValue": false
},
{
"key": "WIZARD_JRE_CP",
"desc": "Dedicated installation of Java 8",
"defaultValue": true
}
]
}
]
}
]
Changelog:
- 0047 30/Oct/17 – Updated dedicated Java version to 8 update 151, added support for additional Intel CPUs in x18 Synology products.
- 0046 26/Aug/17 – Updated to CrashPlan PRO 4.9, added support for migration from CrashPlan For Home to CrashPlan For Small Business (CrashPlan PRO). Please read the Migration section on this page for instructions.
- 0045 02/Aug/17 – Updated to CrashPlan 4.8.3, updated dedicated Java version to 8 update 144
- 0044 21/Jan/17 – Updated dedicated Java version to 8 update 121
- 0043 07/Jan/17 – Updated dedicated Java version to 8 update 111, added support for Intel Broadwell and Grantley CPUs
- 0042 03/Oct/16 – Updated to CrashPlan 4.8.0, Java 8 is now required, added optional dedicated Java 8 Runtime instead of the default system one including 64bit Java support on 64 bit Intel CPUs to permit memory allocation larger than 4GB. Support for non-Intel platforms withdrawn owing to Code42’s reliance on proprietary native code library libc42archive.so
- 0041 20/Jul/16 – Improved auto-upgrade compatibility (hopefully), added option to have CrashPlan use a dedicated Java 7 Runtime instead of the default system one, including 64bit Java support on 64 bit Intel CPUs to permit memory allocation larger than 4GB
- 0040 25/May/16 – Added cpio to the path in the running context of start-stop-status.sh
- 0039 25/May/16 – Updated to CrashPlan 4.7.0, at each launch forced the use of the system JRE over the CrashPlan bundled Intel one, added Maven build of JNA 4.1.0 for ARMv7 systems consistent with the version bundled with CrashPlan
- 0038 27/Apr/16 – Updated to CrashPlan 4.6.0, and improved support for Code 42 pushed updates
- 0037 21/Jan/16 – Updated to CrashPlan 4.5.2
- 0036 14/Dec/15 – Updated to CrashPlan 4.5.0, separate firewall definitions for management client and for friends backup, added support for DS716+ and DS216play
- 0035 06/Nov/15 – Fixed the update to 4.4.1_59, new installs now listen for remote connections after second startup (was broken from 4.4), updated client install documentation with more file locations and added a link to a new Code42 support doc
EITHER completely remove and reinstall the package (which will require a rescan of the entire backup set) OR alternatively please delete all except for one of the failed upgrade numbered subfolders in /var/packages/CrashPlan/target/upgrade before upgrading. There will be one folder for each time CrashPlan tried and failed to start since Code42 pushed the update - 0034 04/Oct/15 – Updated to CrashPlan 4.4.1, bundled newer JNA native libraries to match those from Code42, PLEASE READ UPDATED BLOG POST INSTRUCTIONS FOR CLIENT INSTALL this version introduced yet another requirement for the client
- 0033 12/Aug/15 – Fixed version 0032 client connection issue for fresh installs
- 0032 12/Jul/15 – Updated to CrashPlan 4.3, PLEASE READ UPDATED BLOG POST INSTRUCTIONS FOR CLIENT INSTALL this version introduced an extra requirement, changed update repair to use the chrisnelson.ca method, forced CrashPlan to prefer IPv4 over IPv6 bindings, removed some legacy version migration scripting, updated main blog post documentation
- 0031 20/May/15 – Updated to CrashPlan 4.2, cross compiled a newer cpio binary for some architectures which were segfaulting while unpacking main CrashPlan archive, added port 4242 to the firewall definition (friend backups), package is now signed with repository private key
- 0030 16/Feb/15 – Fixed show-stopping issue with version 0029 for systems with more than one volume
- 0029 21/Jan/15 – Updated to CrashPlan version 3.7.0, improved detection of temp folder (prevent use of /var/@tmp), added support for Annapurna Alpine AL514 CPU (armhf) in DS2015xs, added support for Marvell Armada 375 CPU (armhf) in DS215j, abandoned practical efforts to try to support Code42’s upgrade scripts, abandoned inotify support (realtime backup) on PowerPC after many failed attempts with self-built and pre-built jtux and jna libraries, back-merged older libffi support for old PowerPC binaries after it was removed in 0028 re-write
- 0028 22/Oct/14 – Substantial re-write:
Updated to CrashPlan version 3.6.4
DSM 5.0 or newer is now required
libjnidispatch.so taken from Debian JNA 3.2.7 package with dependency on newer libffi.so.6 (included in DSM 5.0)
jna-3.2.5.jar emptied of irrelevant CPU architecture libs to reduce size
Increased default max heap size from 512MB to 1GB on systems with more than 1GB RAM
Intel CPUs no longer need the awkward glibc version-faking shim to enable inotify support (for real-time backup)
Switched to using root account – no more adding account permissions for backup, package upgrades will no longer break this
DSM Firewall application definition added
Tested with DSM Task Scheduler to allow backups between certain times of day only, saving RAM when not in use
Daemon init script now uses a proper PID file instead of Code42’s unreliable method of using grep on the output of ps
Daemon init script can be run from the command line
Removal of bash binary dependency now Code42’s CrashPlanEngine script is no longer used
Removal of nice binary dependency, using BusyBox equivalent renice
Unified ARMv5 and ARMv7 external binary package (armle)
Added support for Mindspeed Comcerto 2000 CPU (comcerto2k – armhf) in DS414j
Added support for Intel Atom C2538 (avoton) CPU in DS415+
Added support to choose which version of CrashPlan PROe client to download, since some servers may still require legacy versions
Switched to .tar.xz compression for native binaries to reduce web hosting footprint - 0027 20/Mar/14 – Fixed open file handle limit for very large backup sets (ulimit fix)
- 0026 16/Feb/14 – Updated all CrashPlan clients to version 3.6.3, improved handling of Java temp files
- 0025 30/Jan/14 – glibc version shim no longer used on Intel Synology models running DSM 5.0
- 0024 30/Jan/14 – Updated to CrashPlan PROe 3.6.1.4 and added support for PowerPC 2010 Synology models running DSM 5.0
- 0023 30/Jan/14 – Added support for Intel Atom Evansport and Armada XP CPUs in new DSx14 products
- 0022 10/Jun/13 – Updated all CrashPlan client versions to 3.5.3, compiled native binary dependencies to add support for Armada 370 CPU (DS213j), start-stop-status.sh now updates the new javaMemoryHeapMax value in my.service.xml to the value defined in syno_package.vars
- 0021 01/Mar/13 – Updated CrashPlan to version 3.5.2
- 0020 21/Jan/13 – 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 30/Jan/12 – intial public release
PC LOAD LETTER 
I do have a password set on my archives (option 2). I also have the same problems with the 3.5.3 – 1364274000353 client (showing password thing). Another thing is that now i get the message: “unable to backup – no archive encryption key” and can’t set i anyway.Backups won’t run anymore.
Somebody got the solution for this?
Ok while im on here…
– I cant backup friends while they are not my internal network… for some reason it only connects to my synology with the private IP and not the public
– is it possible to configure the crashplan to upload multiple files instead on one file at a time. I hoping then it would upload more
thanks
Thanks a lot for your work with keeping Crashplan working on Synology NAS’s !!
Hi,
Since last update, I could not connect anymore on CrashPlan.
@Jos > I can’t follow your instructions because the mentionned folder only appear after the installation is finished. When the EULA is on screen the folder /yourvolume/@appstore/CrashPlan/ does not exist yet.
Regards
Forgive me, I managed to connect but I’m still in 3.5.3
yeah in my earlier posts I still don’t have 3.6.3. do you have in your client now showing an archive password area?
Hi all, I just made a new package version for 3.6.3. However, even though my own NAS was already running 3.6.3, when I upgraded to the 0026 package, CrashPlan seemed to have destroyed all the metadata. It behaved as if it had never done the initial backup.
I then completely removed the whole package, re-installed it and adopted my old computer record. Then it started working again. Incidentally I also experienced the 3.6.3 client asking for a password immediately after adoption (which I had not configured). It let me use the password for my CrashPlan+ account, and it hasn’t asked again since.
So, since it seems like a bumpy upgrade, can a few people try it out and let me know whether you too had to uninstall and re-adopt your computer? I don’t want to push the update via Package Center if it screws up everyone’s install.
http://packages.pcloadletter.co.uk/downloads/crashplan3.6.3-merged-0026.spk
I just manually installed the 3.6.3 package you put up and it works great. Doesn’t ask for that password thing anymore.
I tried to “upgrade in place” with your new package and lost all my backups, including incoming backups. My clients are all running 3.6.3 (including the DiskStation client, which automatically upgraded). Adopting did not bring the archives back and I’m having to restart a 400+ GB backup. DS710+.
Sorry to hear that. Before you re-seed, I’d recommend that you raise a support ticket to find out why you can’t adopt the existing backup set. They may be able to reinstate it. I suggest that anyone with large backup sets copies their
/volume1/@appstore/CrashPlanfolder before attempting this upgrade, just in case.Is there a Crash Plan Pro image we can test with as well? I cannot remember if the non-pro version will work.
THanks.
http://packages.pcloadletter.co.uk/downloads/crashplanpro3.6.3-merged-0026.spk
Looks like it is working; had to adopt the computer, and it is in process of synchronizing file information. I will advise on any issues. Thanks, Patters, for the great program.
Update with specifics. All is working fine.
1. Uninstalled Crash Plan Version 3.5.3-0025
2. Rebooted DS1511
3. Installed Synology Java 7
4. Rebooted DS1511
5. Manually installed CrashPlan Pro
6. Prompted me to Adopt computer from UI; Log file shows Computer identifer changed (assuming this is after the adoption process); Scanning for files started at 8:59 a.m.; Sync block information at 9:03 a.m.
7. All appears well; backed up successfully.
I just did the manual install. Didn’t really care about my old stuff, not much backed up. Uninstalled 3.5.3. Manual installed 3.6.3. Stopped it. Started it and it wouldn’t start. Uninstalled 3.6.3 and reinstalled. Stopped, Started and it worked this time. Now I am able to backup to my 1513+ from another PC again. I had two backing up to the 1513+ and one continued to backup to it while the other would not after either the 1513+ took the update or the client backing up to the 1513+ took the update. Now they both appear to be backing up like I would expect. Thanks!
Hey, Patters,
Big fan, thanks for your work! Is it intentional that http://packages.pcloadletter.co.uk still lists 3.5.3 as the current version, so that people have to do this upgrade manually?
–Tom
It was because I was a bit concerned about data loss so I wanted a few people to test it before publishing it. Seems ok though.
Will 3.6.3 be available for the built-in upgrade in the next few days? Thank you for making these!
Wasted some time when DS 3.5.3 crashed for me on DS 214 and on reinstall had all kinds of connection issues. Pile 3.6.3 update and I was deep. Manual install worked great for me with no comments. Everything back on line. Thanks patters!
I successfully installed 3.6.3 package on synology (upgrade from 3.5.3). no data loss/no adoption. One thing i did before install, i stopped crashplan service. Thanks for your work, Patters.
Hi, i try the update and like you he say that no inital backup have been made, but he delete the backup archive so i don’t have to adopted my computer but all files have to be transferred …
(Thanks for your job)
Thanks Patters.. I have successfully updated to 3.6.3 and now no more Archive Password.. awesome work!!!
Upgraded and it worked, no need to uninstall or adopt. My installation was still at 3.5.3 before doing the SPK upgrade.
Also, I’m running DSM 5.0 Beta and had crashplan windows cliente version 3.6.3 installed prior the upgrade.
Installed manually, it seems to not see the old backup but being that I am just starting this it was no big deal as I set a new backup and things seem to work as they should. No more annoying password screen. Thank you!!!
Works perfectly without needing to remove the 3.5 version! Thank you so much!!!!
I manually installed the 3.6.3 package. No issue here and no need to adopt. I stopped the 3.5.3 package first before the install. I am using a DS412+ with the latest DSM4.3 version (whatever that is).
Thank you!
Installed manually. Updated Java. Rebooted the Diskstation. Works fine so far. No adoption issues. DS413j
I updated manually. I stopped v3.5.3 before I do that. Everything went smoothly. No loss of data, no need to adopt. My NAS is DS412+ with DSM 4.3 (latest update).
Thank you!
I just manually installed the 3.6.3 package you posted as well. I stopped the CrashPlan service prior to updating and it worked perfectly.
Thanks Patters!
Hi there, first thank you for your efforts! Its been very comfortable to have this packages to rollout crashplan to NASes.
I had crashplan 3.5.3 running on a couple of latest DSM4.3 Intel NASes until the CP3.6.3 Update was starting to rollout. The headless Clients tryed to update and failed and whent down.
After a bit of waiting for an update of you I managed to manually install your 3.6.3 merge package sucessfully. BUT after that, there seemed to be an minor update from Crashplan which changed the FileVersion of the Update, and the Client was again trying to update and failed that.
In the protocolls I also see that there is a line which tells, that synology repairs the update file in @appstore/Crashplan/update …
After that the client tries to start endless :-(
Do you have an idea or fix for that.
Thankfull greetings, David.
I uninstalled the previous 3.5.3 version, then manually installed from the above link. CrashPlan asked once for my password to CrashPlan+ and for the archive encryption key and then I successfully adopted the computer. It all works fine now.
I had difficulty upgrading in place. Originally, I did not stop or uninstall the service. I simply uploaded the update manually. The result was that I could not connect from my windows desktop. It used to be that when this would occur, I would get an error from the client saying it was unable to connect and asked if I wanted to retry. This time the green splash screen stayed up indefinitely. I then completely uninstalled the package, rebooted, reinstalled and then rebooted. I had to adopt the computer and I did get a password prompt during the adoption process. It is currently synchronizing file information, but appears it will function normally from here.
Manually installed the spk on both of my 1512+ boxes and it upgraded in place just fine. The first upgraded and started automatically with no issue, the second didn’t auto-start but ran just fine once I started it manually. No oddities with passwords or lost backup files, and now my desktop machines can finally back up again to more than just CP Central.
Probably just me, but any reason why I wouldn’t be able to see just “CrashPlan” (basic)?
I am seeing CrashPlan PRO and CrashPlan PROe, but not the basic version.
The Package Manager is showing 8 packages in all (under the ‘Community’ tab). Am running a DS213J with DSM 4.3-3810.
Try refreshing
Well, it’s been a frustrating day for me so far regarding Crashplan. Hopefully this will help someone else save many hours. First thing I learned is that version 3.5.3 won’t stay connected to version 3.6.3 and vice versa. I have several machines backing up to each other (LAN and WAN), and it was driving me crazy trying to figure out why some machines wouldn’t connect to others. They would connect for a split second, then disconnect. Turns out it was this version mismatch! (e.g. Windows 3.6.3 couldn’t stay connected to 3.5.3 running on my NAS, but another host running Windows 3.5.3 had no problem regardless of LAN/WAN).
I also manually updated the Synology CrashPlan version using the spk provided above and it worked perfectly. The Archive password box went away, and now my machines are able to connect to each other. It looks like there’s an update delay counter built in to the clients since 1 of my machines automatically upgraded to 3.6.3 but the other ones haven’t yet. I haven’t found the command to force an upgrade, but installing 3.6.3 over the older version seems to work fine (Windows hosts).
did you loose any of your files uploaded to crashplan after the upgrade if the Synology crashplan to 3.6.3?
thanks
No, nothing lost, and backups were as they left them (I’m still mid uploading to CrashPlan Central.
My Synology CrashPlan client eventually went into block synchronization and “found” the existing backup (the sync process went overnight so I’m not sure how long it actually took). I did lose my inbound backups completely, but they were much smaller than the 400+ GB outbound one.
Thanks for the update.
I just got a new DS1513+ and in the process of setting up your CrashPlan package on the new DiskStation, I discovered the manifestPath in my.service.xml is set to /volume1/@appstore/CrashPlan/backupArchives/, and not /volume1/crashplan/backupArchives/. This is the incoming backups folder, correct? That may explain why I had to start all of my incoming backups over. Could you take a look at your 3.6.3-0026 scripts and let me know if you need any other info? This is a brand new installation of the package on the DS1513+. I haven’t removed anything from my old DS710+, although I have stopped the package so my files won’t get unsynchronized. Both are on DSM 5.0-4418 Update 1. Is there any other reason your installation script would have chosen the @appstore path? (i.e., permissions issue with existing /volume1/crashplan/ folder, which it turns out hasn’t been modified since 20131207). I did try to delete the shared folder on the 1513 entirely and do a second install from scratch, with the same result (/volume1/@appstore/CrashPlan/ selected as manifestPath).
If this is indeed what happened, the next thing I would need to do is move the backupArchives folder from the 710 to the 1513, and any necessary support files to point CrashPlan to the right places on my new DiskStation. I kept the identical folder structure, just a different host name. And I would like the incoming backups to be in the “correct” folder tree /volume1/crashplan/backupArchives/.
Thanks for your help and for a great job with this package!
Hello:
I am using a DS412+ with DSM 4.3-3827
I create a public folder (FYI had to rename my Public folder to public). I installed Java SE 6 (1.6.0_38-0021) by downloading from Oracle to the public folder and then installing your Java SE for Embedded 6 package.
I then installed Crashplan 3.5.3 from within DSM (from your feed) and it seems to be “running”. I stopped and restarted. Then installed 3.5.3 on a client PC.
I could not directly edit the ui.properties file to enter the IP address of my Synology (kept saying it was being used/open in a program) and had to restart the client PC into Safe Mode in order to edit that file.
After all that, whenever I open Crash Plan on the client PC, IT DOES NOT CONNECT to the Synology (“Unable to connect to the backup engine”).
I went back through a few pages of these comments, I find one guy with possibly the same problem, but I don’t see any fixes.
Out of curiousity, I uninstalled Crash Plan on the Synology and also on the client and then installed the 3.6.3 file you listed for testing and installed 3.6.3 on the client as well and then edited that ui.properties file again (in safe mode again). and same problem.
Any suggestions of anything further to do? I don’t know how to use SSH but if I have to, I’ll do some learning if I need to use that to access the machine to do anything further.
Thanks!!
Are both the Synology NAS and your client machine running the same version of CrashPlan?
Yes. I used the same version for both, when I tried 3.5.3 and when I tried 3.6.3
I have a DS411+II (Intel Atom D525, 1GB RAM) with about 170GB backed up to CrashPlan.
I just manually upgraded to patters’ 3.6.3 package, everything was flawless for me. Full marks to patters
There is definitely some (minor?) incompatibility with a 3.5.x client and 3.6.x server … so lesson for the future, be careful when client and server are out of sync. I’m sure CrashPlan would not support such an installation. It would be nice if their client software, on startup, recognized the server version and auto-updated (or at least warned of the difference).
I’ve installed 3.6.3. I had to go and re-change the ui.properties file to point to the headless server from the client, and the file was no longer in the same location but easy enough to find.
I am however struggling with one of two clients. One client is a “friend” and has no problems accessing the server, and the backup is running as we speak. The second location is using the same username and that unfortunately isn’t working. Whilst it can find the “diskstation” server location, which shows up “green”, once you start the back-up to that destination it somehow says it cannot access it “backup location is not accessible”. I’ve tried to reset the location from the client end, as well as starting and stopping the server end, but no joy unfortunately.
Unfortunately I cannot help you with the question around accessing previous archives, because I have purged my entire server prior to the upgrade.
Well I’ve managed to get the other client to work by generating a new global unique identifier through the command “GUID new”. That seemed to do the trick and all is backing-up. I realise not having to reconnect old archives has made the process that much easier. Still, 3.6 running and all looking fine.
D’oh, sorry about my last comment. I just read your post more carefully and see that you’re holding back on the auto-upgrade.
Installed 3.6.3 manually and it worked fine. When I connected the headless client it said “Adoption Complete!” because I had tried to re-adopt to solve the problem on 3.5.3 a couple of days ago before I realized that I needed 3.6.3.
Let me know if it’d help if I sent any logs.
I have now added another 2GB RAM in my Synology 1513+ so now have 4GB. Its currently using around 30%. Is there any advantage in letting CrashPlan use more memory. If so do I do via the GUI client or is there a value I can change in the config?
thanks
Oh im using USR_MAX_HEAP=2048M
Dino – can you explain how to change the max_heap? Thanks.
Hi Jack,
it is in the syno_package.vars file under editing /volume1/@appstore/CrashPlan/ you will probably see that its already set and the # is removed.
Hi Patters,
Thanks a lot for the good work! I installed your Crashplan package but had not yet time to try it really.
However after updating last night to the latest DSM, and trying right after to update Crashplan package, the Synology showed the message that Java was not properly installed (I installed it properly before, as instructed by your Crashplan package and it used to work, but it seems that the latest DSM update erased the Java_home var…). Right after this error message was displayed and that the update failed, Crashplan fully disappeared from my installed packages page and is nowhere to be found anymore.
Would you be able to let me know what steps I have to take to manually uninstall everything from the Crashplan package, and from the Java install? (I have an ARM Syno)
Thanks a lot!!
Cheers
I have already applied the Java update from Oracle. I applied the Crashplan update successfully using your spk file. It says 3.5.3 in the Package Center, but it says 3.6.3 in the logs and the 3.6.3 engine on my laptop connects to it. The 3.5.3 engine on another PC connects successfully too to the higher version (the reverse didn’t work).
i had issues conecting, reinstalled, tweaked .conf files etc.
In the end I really thing it’s all related to a dsm update. Reinstall java and ipkg before messing anything up.
I have done a fresh installation of 3.6.3 (ie no upgrade from 3.5.*) on a DS214+ as below:
1) Upgrad DSM to 5.0 update 1 (beta).
2) Installed Java 7 from “Packet Center” -> “Java Manager” -> jdk-7u51-linux-arm-vfp-sflt.tar.gz (ie *not* from PC Load Letter).
> java -version
java version “1.7.0_51”
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) Client VM (build 24.51-b03, mixed mode)
3) Installed 3.6.3. The service is running (+ answers to the CrashPlan Desktop from another computer).
Questions:
A) Must I use Java from “PC Load Letter” or can I use the generic Java 7 in DSM 5.0 (ie directly from Oracle) as in p2 above.
B) I get the “Archive Password Required”. How do I remove this question ?
(I am new to Synology products but I have used CrashPlan for several years on 5+ computers)
Hi Doublem,
I’m new here, and in mostly the same boat as you. Long-time CrashPlan user, but only on Windows. I’m also new to Synology and just setup my DS412+ as follows:
– Followed instructions to install Java SE for Embedded 6 from pcloadletter’s repository (his site had said that Intel users are stuck at version 6, not sure if that’s still current)
– Installed CrashPlan from his repo
– Restarted the NAS
– Installed CrashPlan 6.3.6 on Windows PC and edited the ui.properties file, then connected
Now, I see the same “Archive Password Required” screen as you, and I’ve tried to set it, but it just disconnects from the CrashPlan service and closes the app.
I’ve also since upgraded to DSM 5.0 beta, then update 1.
I have been able to adopt old archives of my “Friends” and get them to resume backing up.
I have all my steps in a Word doc if that would be helpful, though I don’t think I’m any better off than you. And I’m interested to know if I should be on Java 7 from Synology instead of 6 from pcloadletter.
I realized that I was still on the community-packaged 3.5.3-0025 from pcloadletter, and the Windows clients were on 3.6.3, which probably explains the issues. I “manually installed” the 3.6.3 pkg that was mentioned above (http://packages.pcloadletter.co.uk/downloads/crashplan3.6.3-merged-0026.spk) after copying my backupArchive folder just in case. After the upgrade, I no longer receive the “Archive Password Required” message, and my previously-working backups resumed automatically.
There was one Windows client that had not been working at all with the Synology CrashPlan 3.5.3, and after the upgrade, and then restarting the CrashPlan service on the client, it began backing up immediately.
I think I’m in good shape now, and will see how things go – might still do the RAM upgrade to 3GB if it seems sluggish or the service restarts on its own. My total backup archive is under 100GB.
Thanks for all the hard work here, patters.
hi,
I’ve just noticed that my crashplan was in a stopped state. I started it again which took a while then looked at the logs. I see that crashplan has done some upgrade from central.crashplan.com:443 version 1388556100363. then once it installed crashplan stopped. now that I’ve started in the client it’s doing cache: pruning versions (deep) with a percentage and time left? anyone had this.. I’ll let you know what happens when its finished this process.
Dino,
Mine stopped too after the upgrade, but I could not re-connect my client until I edited the properties.ui file on the Synology. I had to uncomment the service host line as well as adding the Synology IP address back.
I’m new to Crashplan, but have to wonder how often an upgrade is pushed out to the engine. Also wondering if there is a way to disable the auto upgrade.
Hopefully, someone will chime in with answers to your and my questions… :-)
I had a small issue here on my DS411+II after the engine auto-updated to 1388556100363.
Per the log, download and install of the upgrade were successful and the engine stopped. The engine did not automatically restart; not sure if this is normal/expected behavior.
Where it gets weird is when I went to manually start the CrashPlan service (via the DSM interface), the start up script seemed to get stuck in a loop … specifically the upgrade.sh kept starting and stopping the engine every 10-15 seconds. I eventually figured out what was up, logged in and killed the upgrade.sh PID. I then re-started CrashPlan service via DSM and everything came up normally.
The version string of the running server is “3.6.3 – 1388556100363 (2014-01-01T06:01:40:363+0000)” so all seems well.
I think the issue might be on the CrashPlan upgrade.sh side of the equation. It seemed like their methodology of determining ‘is the service shut down’ was not working well. I base this on the contents of the many bin/restart.*.log files created when the start up loop was occurring.
Anyway, it seems like the upgrade to this version is not totally smooth but easily fixed in my case.
I think I ran into something of the same.
I ran into an issue after the adoption, where CP would run for a short while on the NAS but then it would stop. Rebooting the NAS again solved that problem for me.
Also, I noticed a new CrashPlanEngine.pid in the /volume1/@appstore folder, whereas after the final reboot it now resides in /volume1/@appstore/CrashPlan.
That indicates that the ride wasn’t entirely smooth.
thanks nosaj and john… seems to have done what it needed to do and running fine now. i’ll keep an eye on it. I running version 3.6.3 – 1388556100363 (2014-01-01T06:01:40:363+0000)
Pretty sure I had the same problem: the log said “Crashplan started…” at least twice a minute. I’d already stopped and started Crashplan a couple of times, but I tried again while I was trying to figure out how to kill the upgrade.sh PID and then Crashplan started working normally.
Joining other DS412+ that have some issues, my installation is still not working properly, even with 3.6.3 (http://packages.pcloadletter.co.uk/downloads/crashplan3.6.3-merged-0026.spk). I have a backup that sums up to about 800Gb (+500k files), that has reached 100% only a few times, but requiring manual interaction (see below).
Summarizing what is happening:
1. I start by installing Crashplan, stopping the server, editing bin/run.conf and synology_vars to increase the RAM heap (I now have 2Gb of RAM, so I’ve set it to 1536Mb), and starting the server again
2. Using the mac CrashPlan client I can connect to the headless client, login, and adopt the previous backup. From there it indexes all the files and backs up the files to the server.
3. The issue is that eventually the headless client *will* crash and *does not* start again – I have to remove CrashPlan and reinstall, back to step one. It’s the only way I can get a backup done again.
4. CrashPlan crashed a lot more when I had only 1Gb of RAM. It wasn’t until I increased the RAM heap value to 1024Gb that it could successfully start backing up files before crashing while still indexing. With 2Gb I can get all the files backed up, but eventually it crashes (always before it starts a new backup iteration).
I’d be very appreciative if someone (patters? :/) would give some pointers here – the package is awesome and crazy not to have officially installed (I’ve sent feedback to Synology asking for this), but it’s frustrating not having it working at all.
Thanks
More details (not updated with my 2Gb RAM upgrade) on this thread:
http://forum.synology.com/enu/viewtopic.php?f=190&t=75580
So does this mean that every time Code42 releases an automatic update, this package on the Synology will break and we will have to wait for a new package from you? Is there anyway to disable the automatic upgrade process from Code42? I’ve never liked software that pushes updates without you having to confirm that you want it installed.
Same question here – can automatic update be disabled?
Also – Is it nessecary to upgrade to Crashplan Pro and not the “basic” version that I have a license for? The package that is listed installs the Pro version – but I always used the basic version which I signed up for with paid subscription.
Thank you for your efforts/suppport here !
My package is still showing 3.5.3 – 0023, but when I did a version command it was showing that the Engine was running 3.6.3. Updated the console software and modified the UI file to point to the Synology and everything has been running as expected. If your scripts handled the automatic update are we better off just leaving the package where it is instead of updating?
thanks for all the work on this Patters
Regarding the prevention of Crashplan making unattended and automated updates.
If there is no way to configure it to prevent this – does anyone know from which web address it downloads the updates? Then I thought I could block that address in my firewall (for the IP address of the Synology only).
Thanks again to Patters for the efforts !
Crashplan stopped working on my DS1813+. (Like many above, Crashplan is updating itself to 3.6.3 over the internet.) My understanding is that if I install build 0026, this should solve the problem. (Can you confirm this?) Unfortunately, build 0025 is the only one available in the package repository. Do you know when the repository will be updated? I’d like to avoid having to manually update to future versions, which I would have to do if I manually install the linked 0026 build above.
Thanks for creating the package!
I had a previously working 3.5.3 Crashplan installation on Synology with Java 6 that had been installed using the pcloadletter repository. My clients had auto-updated to 3.6.3 and stopped being able to connect to the Synology remotely a couple of days ago. I opened Synology Package Manager, stopped the Crashplan service, manually installed the 3.6.3 SPK, restarted the Crashplan service on Synology and everything started up syncing again no problem. Thanks! Very smooth and painless. Took about 2 minutes.
Do you have the updated ProB and ProE clients…I have all of my clients synologies all just failed with the mis match, versions, updates etc. Ugh. If you can provide the spk on Prob & E – I can test some of our low volume data clients.
Note to add…I see if I go in the package updater, the ProE client appears updated in your site to 3.6.1.4-0025. The client console updated by CP shows 3.6.1.4 on first open- but still cannot connect. Was there a change that requires Java 7 now perhaps? I still have Java 6.
I’m trying to run the uninstall script from the current “CrashPlanPRO_3.6.3_Linux.tgz” archive, but I get, “ash: ./uninstall.sh: not found”
I have verified that the uninstall.sh file is in the folder I am typing the command from.
Hello
Crashplan on the desktop is updated. It now asks om authentification password and after filling in it closes.
Heeelp, will there be a update for ds212 synology?
Crashplan does noy work anymore. It updated itaelf on the desktop. It now askes om password authentification and after filling in it closes the application.
Engine keeps running.
Help how to i get crashplan working? Is there a update needed?
Crashplan 3.5.3-0025 i there a new version in the synology app installer?
Thanks
Tried this upgrade package…and I keep getting the “Cannot connect to backup engine” from the client.
/etc/init$ netstat -an | grep ‘:424.’
tcp 0 0 0.0.0.0:4242 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:4243 0.0.0.0:* LISTEN
Do I need to get the 127.0.0.1 on port 4243 or?
How can I tell if CrashPlan is actually running? The log shows only “started” events – and never anything else? Manually stopping the service does not show in log? I looks like it starts up and then fails/crashes silently?
I 02/27/14 10:04PM CrashPlan started, version 3.6.3, GUID XXX
I 02/27/14 10:07PM CrashPlan started, version 3.6.3, GUID XXX
I 02/27/14 10:32PM CrashPlan started, version 3.6.3, GUID XXX
I 02/27/14 10:36PM CrashPlan started, version 3.6.3, GUID XXX
I 02/27/14 10:47PM CrashPlan started, version 3.6.3, GUID XXX
I 02/27/14 10:58PM CrashPlan started, version 3.6.3, GUID XXX
….
Thanks,
Lars
Lars, I had the exact same issue after the update automatically installed. I fixed mine by editing the ui.properties file in the /volume1/@appstore/Crashplan/conf directory. Change the line #servicehost=127.0.0.1 to servicehost=yoursynologyip where your synologyip equals the ip address of your Synology device and you remove the “#” symbol. Somehow the upgrade reset that value back to the default on my Synology.
Hope that helps… :-).
Hi Brad and thank you for the tip ! So basically I need to put in the IP of the Synology – and not 127.0.0.1 which is the loopback address? Will give it a try for sure.
I do have the servicehost set for the Synology IP on the client – but this is on the server side !
Thanks again.
Hi Brad (and others…)
I guess there are no two completely equal setups/configurations on our different Synology diskstations. I was about to try the suggestions from Brad listed above – and decided to clean-up my Synology before going ahead.
I ended up getting it to work and adopt perfectly before attempting the tweak from Brad.
Here is what I did:
1) Uninstalled CrashPlan
2) Uninstalled Java 7 Embedded
3) Re-enabled guest account (was disabled – but can’t remember when I did this)
4) Deleted “shared folder” named “backup archives” (folder was empty – probably left from previous installation)
5) Rebooted Syno
6) Installed Java 6 (not 7) Embedded
7) Rebooted Syno
8) Installed Crashplan 3.6.3-0026 (Manual Installation with package from Patters – crashplan3.6.3-merged-0026.spk)
9) Rebooted Syno
10) Uninstalled Crashplan on client computer (Win 8 64 Bit)
11) Downloaded 32 bit Crashplan from http://www.pcworld.com/product/954422/crashplan-32-bit-version-.html. (I did this since I have read about problems regarding 64 bit client with 32 bit serverside install. And regardsless of which installpackage I download from Crashplan website I get exactly the same file even though I request 32 bit version. Maybe the installer Works for both and sort it out during install – which Means I end up with 64 bit version).
12) Installed Crashplan on Win 8 PC.
13) Edited the #Servicehost from 127.0.0.1 to the IP of my Synology – and removed “#” of course
14) Started Client, started adoption process – entered the encryption password
15) Everything works now – currently waiting for “Synchronizing” to complete (600GB archive)
What made it work?
I have no idea. Once Synchronizing is complete I will reboot everything and make sure it starts up as expected.
What comes next?
Nothing – if it works don’t fix it :-)
On my x-mas wish list? A trick/tweak/hack to prevent Crashplan from auto updating again. Maybe block some web address where is searches for updates?
Thanks to Patters for the work on the packages.
Epilog…..
So for “kicks” I tried installing 3.6.3 client from Crashplan website on my Win 8 Pro 64 Bit. It installs as 64Bit version (regardsless if I click to download 32 bit version – and the filename/size is also an exact match). That version does NOT work/communicate with Patters Synology package.
So – get the 3.5.3 version (32 Bit):
http://www.pcworld.com/product/954422/crashplan-32-bit-version-.html
….and install that one. It will automatically update to 3.6.3 – and will continue to work afterwards (I guess it is 32 bit since it works with Patters 3.6.3 Synology package).
Hello Brad,
I had same issue (client cannot connect to the Synology service), but after I updated the Mac client and made the change in the Synology service ui.properties config file everything work flawlessly again.
Thank you for the tip.
Regards,
Peter
Thanks Brad and Lars. I had exactly the same issue, and resolved with changing the ui.properties file as Brad suggested.
Hey Lars,
Thanks for taking the time to post your complete list of debugging steps. I followed everything, and am now at 1.8% synchronized out of a large ~1TB backup. Was worried that I’d lose everything and have to re-do everything…but it works. BTW, to help others, here are a few tips that helped me:
Synology logfile Path: /volume1/@appstore/CrashPlan/log
(remember to log in as root, not admin)
Update /volume1/@appstore/CrashPlan/syno_package.vars file to uncomment and increase USR_MAX_HEAP from 512M to 1024M (for large backups)
Previous (64-bit) Win8 file location: C:\Program Files\CrashPlan\
New (32-bit) Win8 file location: C:\Program Files (x86)\CrashPlan\
after crashplan auto update to 3.6.3 on my synology, backups where off. I updated my client to 3.6.3 to and no way to connect to the server.
So, i updated on the syno throught a manual update with the 3.6.3 pkg. no problem with the update and restart. Backup to crashplan servers was ok, but not way to connect to local backups or friends ones.
after investigating, the crashplan account on the syno has been recreated with the update and the new account was not allowed to access to backup archive folders. after updating ownerships and restart package, everything was working again.
I managed to get most of our clients synologies working, I had to remove the java 6, reinstall it again. Then it seems to eventually kick in after a few start/stop of the CP package. This was using the ProE clients. Had to make sure the linux version matched what was on the PC that had the console and at times w/o rhyme or reason and a few attempts – it worked. I have one still not able to work, and is the ProB version. I even removed all, put 3.5.3 back on and still cannot get the console to connect to the synology linux part…this one I am stumped on.
After installing manual the package 3.6.3 it works fine now. Thankt
First of all, thanks for the great work.
I have a DS412+ running DSM4.3 and backup to CrahsPlan. I also act as a backup service for my family – 4 different machines geographically spread running windows 7, 8.1 and MacOSX 10.8.mumble. CrashPlan rolled out updates to the windows 8.1 client and one of the MacOSX clients first and both stopped working. My DS412+ was still running 3.5.3 at that point. A re-install on the MacOSX client recovered completely and resumed backing up with the previous archives. The windows 8.1 client refused to cooperate after many failed attempts including reinstalls of the CrashPlan client. The failure was manifest related and CrashPlan’s solution was to upgrade both server and client.
When CrashPlan pushed out the update to my DS412+, all backups ceased and the CrashPlan package on my DS412+ stopped. I was able to restart it, but it could act as neither a client to CrashPlan central nor as a service for my family.
It took some time, but I now have everything working though my clients have started their backups from scratch.
To recover, I used Bushwakers 1511 steps (thanks for that) but since my DS is intel, I’m still on Java 6:
0. Before going through this, on my ds, I made a backup copy of /volume1/crachplan/backupArchives
1. Uninstalled Crash Plan
2. Uninstalled Java 6
3. Rebooted
4. Re-Installed Java 6 (pcloadletter says we must use v6 for Intel. See: https://pcloadletter.co.uk/2011/08/23/java-package-for-synology/)
5. Rebooted my ds412+
7. Manually Installed the 3.6.3 CrashPlan package posted here http://packages.pcloadletter.co.uk/downloads/crashplan3.6.3-merged-0026.spk
8. Waited a minute
9. Stopped CrashPlan
10. Started CrashPlan
11. Connected my Linux client to my DS backup engine.
12. Logged in my account
13. Selected “adopt computer” to resume my DS backups.
Note: My linux client which connects to the DS412+ backup engine was also not working after upgrade to 3.6.3. CrashPlanDesktop splashscreen displayed for a few seconds and then nothing. ps shows CrashPlanDesktop was running. The problem and work around is found here: https://support.code42.com/CrashPlan/Latest/Troubleshooting/CrashPlan_Client_Closes_In_Some_Linux_Installations
Note: I’m running KDE, no GNOME nor GNOME repository, and my client is 3.6.3, but the problem/workaround still applied.
Hopefully this will save others some headache.
Awesome. Worked like a charm (from a Windows client) too!
Hi, I have installed the merged package but it only installs the pro version, when will the standard package be released please? I have lost the 3.5.3 client installer, so I cannot reinstall since trying to go to v3.6.3 and now I cannot backup.
Kevin….the link is listed earlier in this thread:
http://packages.pcloadletter.co.uk/downloads/crashplan3.6.3-merged-0026.spk
Backup broken due the automatic update of the package on Syno. Tried to manual install the merged 3.6.3, no success. Tried to upgrade win7 GUI to 3.6.3, no success. Deleted everything (syno pkg, java, GUI from PC) and done a fresh install, java7 in public, java syno pkg, 3.5.3 from the repo, 3.5.2 client to window, edited the ui.conf to point to my NAS, no success…I’m kind of stuck, any idea to gain my access back? The last working setup was java7, 3.5.3 syno pkg, 3.5.3 GUI, paying customer bakcing up to the cloud.
One more strange thing: installed the 3.5.3 but it says 3.6.3. Still runs despite the fact the service has been stopped and disabled, crashplan tray icon disabled as well.
DS1512+ with password protection – upgrade successful no issues
For me manual update went smoothly. Only needed to reboot my DS1512+ afterwards and all machines started backing-up again. IMHO you can put this build in the syno appstore.
Another data point here, my synology crashplan install automatically installed update to 3.6.3, after which I could not view crashplan from my windows PC client. Also, looked like crashplan didn’t back up files in the last few days.
Like others have said, after upgradinge to 3.6.3 it looks like the user “crashplan” had its file permissions reset and the “ui.properties” file was reset as well. I did the following steps and it appears to have fixed my issues:
-Verified CrashPlan on my synology was running 3.6.3 by logging into the synology gui, going to package center, under installed selected crashplan, and clicked view Log, saw “CrashPlan started, version 3.6.3”
-Stopped crashplan package (not sure if necessary)
-Updated user “crashplan” to have the correct file permissions, done through the synology ui
-Updated the “ui.properties” file, used Putty to telenet in (enabled terminal services through synology ui), logged in under the root username (enabled the admin account, root password same as admin). Used “vi” text editor on /volume1/@appstore/Crashplan/conf/ui.properties
Changed the line #servicehost=127.0.0.1 to the synology box IP address, removed #
Saved file.
-Restarted crashplan package (not sure if necessary)
-Shut down and re-started the crashplan client on my windows PC, noticed it started upgrading to 3.6.3, after installing, the splashscreen says 3.6.3.
Now it appears to all work, backing up the latest files as we speak.
Smitty220 and others, thanks very much for the instructions. Resetting the permissions for the user crashplan and then changing the ui.properties file as recommended did the trick and 3.6.3 is up and running again. So currently running it on Patters’ version 3.5.3-0022. I did have to reset the ui.properties a couple of times as it would loop like Lars mentioned above giving CrashPlan started, version 3.6.3, GUID XXX then silently crashing and restarting. This is on a DS 1511+ running Patters’ Java 6.
Patters, any idea if those of us who got automatically upgraded and fixed the problem in this way should let it run as is or update it to your latest version? Thanks for the great work as always!
I am not sure why, but for some reason I am getting the following error.
Any insight into why the Crashplan servers are being blocked?
http://go.lilrkt.com/image/1I3a3a3t1A0o
It looks from my experiments that the only way to actually increase the ulimit value (max open files) would be to change the package to have it running as the root user. When I have some time I will make this change and publish that update properly via DSM Package Manager.
Hi patters, my Synology still shows the 3.5.3 package and I’m actually not certain 3.6.3 has been released. Have you already published this new version with Package Center?
Seems 3.6.3 is actually running, but Package Center is still showing 3.5.3
Hi Patters, I have followed all instructions from various people. I have the server upgraded and it appears t o be running and backing up. My issue is that I cannot connect a client to the headless server. Any ideas?
No idea what I have done, but got it working again. Thanks to Petters and everyone else on this board. Great Support.
Hi,
is it possible to run, CrashPlan and CrashPlan Proe client on one NAS together?! Or is this not possible?!
Regards
Can someone maybe me answer this question?!
I don’t think so. From memory the start stop script looks for a process running containing the text CrashPlanEngine, which all versions use – so things would get mixed up.
Okay :(
So I must find a Backup Solution for friends who can Backup her files on my NAS. Maybe you know a friendly Software which can does this?! I search for something, which is also so Easy do configure?!
Hello,
I have a sinology DS713+. I recently upgraded the crash station software and then received an email several days later saying that no backups had taken place. I tried to reconnect from my desktop software. It showed that crash station had no connection to the cloud storage. I read through some blogs and found that you had a manual install of 3.6.3. I installed this and know I cannot connect to anything. I tried uninstalling and reinstalling to no avail. I did update my client to 3.6.3 as well and changed the setting to point to the headless client. I noticed that crash station also does not have any logs on the sinology anymore. Need some help here.
I just wanted to add that I did get this working finally. The missing step was rebooting the DS713+. I uninstalled, rebooted and then reinstalled and everything worked. Just a question. I used the manual install of 3.6.3 that you had a link to above. Any idea when this version of the software will be in the package installer?
The latest crash plan release 3.6.3 has java built in. Do we know if this will work in the sinology environment and if so, could you update the package in the package download center?
Can someone please leave a summary on how to repair a 3.6.3 that restarts 3 times per minutes and silently crash as well? Please write it in novice language, because i’m not a linux guru :-(
Hi all
Anybody who can help me? Crashplan hasn’t been working for 10 days now :o(
Hey BroderOle –
I had pretty much the same thing going on, and traced it back to the fact my backups were growing too large (numerous small files & directories). Once I increased the default heap size from 512M to 1024M, this specific problem went away. Since CrashPlan’s support pages no longer show this when you search, here’s my raw notes assembled from several internet sites for the whole thing:
CrashPlan runs out of memory and crashes
Matt O.
posted this on Jan 06 02:04 PM
Edited by Xander B. on June 19th, 2013
Affects CrashPlan+, CrashPlanPRO, CrashPlanPROe, all platforms
Summary In some cases a large file selection (>1TB or 1 million files) can cause CrashPlan to run out of memory and crash. Symptoms include:
* When opening the desktop application, users see “Can’t connect to Backup Engine” message.
* Desktop application (UI) crashes repeatedly while scanning files.
* Unpredictable application behavior.
Adjusting the maximum amount of memory allocated to the CrashPlan service can resolve this.
DiagnosisOutlined below is the process for confirming that memory usage is leading to the symptoms described above by looking at the CrashPlan application logs and for raising the maximum amount of memory that CrashPlan has access to.
1. Navigate to the log folder for your operating system:
* Windows XP: C:\Documents and Settings\All Users\Application Data\CrashPlan\log
* Windows Vista, 7, 8: C:\ProgramData\CrashPlan\Log
* Mac OS X: /Library/Logs/CrashPlan
* Linux (default): /usr/local/crashplan/log
* Solaris (default): /opt/sfw/crashplan/log
2. Open each service.log.# file in a text editor and look for the phrase “OutOfMemoryError”:
[09.23.12 22:33:02.273 ERROR QPub-BackupMgr backup42.service.backup.BackupController] OutOfMemoryError occurred…RESTARTING! message=OutOfMemoryError in BackupQueue!
3. If you this message, adjust the maximum amount of memory that CrashPlan can use at one time.
Path: /volume1/@appstore/CrashPlan/log
Need to log in as root, not admin, to accomplish changes: ssh -l root 192.168.1.174 (put your Synology device’s IP address here)
Linux / Solaris
1. Stop the backup engine
2. Using your favorite Terminal based editor, edit the below line in /usr/local/crashplan/bin/run.conf
3. Edit to something larger such as 768, 896, 1024, 2048. i.e. -Xmx1024m
* This sets the maximum amount of memory that CrashPlan can use. CrashPlan will not use that much until it needs it.
* As a rule of thumb set about a gigabyte RAM for every terabyte in the file selection.
* For example, if you’re backing up 1 terabyte of data set the -Xmx value to 1024 like so: -Xmx1024m
4. Start the backup engine
However, it kept overwriting run.conf file with bad 512 value. Then found this:
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.
I know this is a jumble of stuff, but it’s what I did to fix (and later re-fix) my Synology CrashPlan backup. I hope you can find something helpful in here.