I just tested the windows client on a different machine and it's uploading at a similarly slow speed, so it's unlikely it's a client issue. I've also tested uploading to google drive and it's uploading at full speed so it's not an issue with my internet connection. I can only assuming they're throttling. Which really sucks.

Did you try to contact CrashPlan Pro support?

I will, but frankly I've had better luck with the community then I've had with Code42 so I decided to start here.

 

Anyways, thanks for the great container and the help. If they give me anything of use I'll post it here in case it's helpful to anyone else.

I don't think they're throttling:

 

11/21/17 03:10AM [NAS Backup] Completed backup to CrashPlan Central in 9 minutes: 1,771 files (458.60MB) backed up, 28.40MB encrypted and sent (Effective rate: 93.6Mbps)

 

Can't complain much about 93.6Mbps effective rate.

 

Is it possible that there's something else going on with your machine that's slowing down the compression & encryption? Maybe you've hit a batch of files that won't compress well?

 

I would definitely followup with Code42, and I think we'll all appreciate it if you were to post back anything you hear from them.

1 hour ago, FreeMan said:

I don't think they're throttling:

 

 

 

 

Can't complain much about 93.6Mbps effective rate.

 

Is it possible that there's something else going on with your machine that's slowing down the compression & encryption? Maybe you've hit a batch of files that won't compress well?

 

I would definitely followup with Code42, and I think we'll all appreciate it if you were to post back anything you hear from them.

 

I've tried it on two different machines, different OSes, with different files. Neither is hitting it's head on the RAM or processor, and I've tried disabling compression. The data being backed up is nearly incompressible anyway. Both were nearly maxing out my upload connection before the migration, now they're both under 2Mbps. The only two constants between the two machines are CrashPlan and my ISP. The only thing I can think of that I haven't tried is using a vpn to eliminate ISP throttling as an issue. **Just tried through a VPN. It didn't improve upload speed at all.

 

I don't know that CrashPlan is throttling. It's possible the server my clients connect to is saturated, or there's something else I'm just missing. I'm just running out of explanations outside of something on CrashPlan's end.

Edited November 22, 20178 yr by Fatal_Flaw

5 hours ago, denishay said:

Hi guys,

 

It took me a while to figure out why Crashplan wasn't maxing (or at least near-maxing) my upload capacity.

The thing is that Crashplan seem to have been developed with much lower connections in mind than the ones we have today.

 

• Stop the Crashplan docker

• Go to your appdata folder, navigate to your Crahsplan folder

• Edit the "my.service.xml" file in the "conf" folder

 

And change the following value to 1:

          <dataDeDupAutoMaxFileSizeForWan>1</dataDeDupAutoMaxFileSizeForWan>
 

• This will effectively disable the data de-duplication for any file larger than 1 byte for any backup done over the internet

• Start your Crashplan docker again

 

This always had me max my connection again. Otherwise, I rarely went beyond 2 MB/s. (currently happily going over 25 MB/s with that)

 

Kind regards,

Denis

Alright! Just edited the "my.service.xml" and it worked! Thanks @denishay! 

I'll preface this question by apologising if it has already been asked before.   I am just in the process of getting parts to build an UnRaid system and am researching the containers I will add once built. 

 

I currently have a Synology NAS and am running Crashplan Pro on a Windows machine via mapped shares.  I have used dockers on the NAS and have done the mapping of different folders so that the docker can access them.   Like this:

 

/volume1/Downloads - /downloads

/volume/TV Shows -  /TV Shows

etc...

 

I didn't see this mentioned in the documentation for this docker.   I only saw mappings for 2 different folders but no mention of needing mappings to all the folders that will need backing up.   Is this just inferred or does this docker not need them.

 

Thanks in advance for the help

Edited November 27, 20178 yr by go69cars
clarified questions

By default, the /storage folder inside the container is mapped to the /mnt/user folder on the host.

 

/mnt/user folder is the root of all shares on unRAID.  Thus you would normally have /mnt/user/downloads, /mnt/user/TV Shows, etc.  Inside the container, this would translate to /storage/downloads, /storage/TV Shows, etc.

Troubling email today...  https://support.code42.com/Release_Notes/CrashPlan_for_Small_Business_version_6.6

 

Quote

• Although using CrashPlan for Small Business on a headless computer and installing CrashPlan for Small Business on a NAS device are unsupported, previous versions of the CrashPlan for Small Business app would still function in these configurations. However, beginning with version 6.6.0, the CrashPlan for Small Business app does not function in either of these configurations.   

 

You beat me....well guess I better start reviewing my options again to move cloud backup solutions. I feel like I just did this recently but decided to stick with CrashPlan...that was a mistake. 

I think this is related to the "official" way to use CP on a headless computer:

 

https://support.code42.com/CrashPlan/4/Configuring/Use_CrashPlan_on_a_headless_computer

 

Not sure this will apply to the docker container... I will make sure to verify once the new version is available

May be a dumb question... but is it OK to let Crashplan back up the appdata share?  I ask mainly because there are so many warnings about appdata and permissions, etc.  Just want to be sure before backing up.

Edited November 28, 20178 yr by Lo Key

19 minutes ago, Lo Key said:

May be a dumb question... but is it OK to let Crashplan back up the appdata share?  I ask mainly because there are so many warnings about appdata and permissions, etc.  Just want to be sure before backing up.

 

I do it without issue.

Sub'd  

Can the Docker / is the Docker 64bit?  Assuming the Docker is a 64 bit linux desktop we should, hopefully, be OK. 

. 

May finally be time to move away from the older CP Docker 

Figured there'd be much more of a storm about the latest Code42 announcement...

 

8 hours ago, geonerdist said:

You beat me....well guess I better start reviewing my options again to move cloud backup solutions. I feel like I just did this recently but decided to stick with CrashPlan...that was a mistake. 

This is exactly how I'm feeling about the whole thing.

 

HUGE appreciation to everyone who's helped with support of the CP app & docker over the years, but it looks like it's getting to be time to move on.

2 hours ago, FreeMan said:

Figured there'd be much more of a storm about the latest Code42 announcement...

 

This is exactly how I'm feeling about the whole thing.

 

HUGE appreciation to everyone who's helped with support of the CP app & docker over the years, but it looks like it's getting to be time to move on.

 

Agreed, thanks to all those that have contributed to this. I suppose we shall just have to see how it unfolds. 

I'm having the same issue with Docker (on Synology DSM) deleting the container every time I shutdown/quit the container. Works fine while running though. Any ideas?

 

Update 12/4/17: Nvm, I see the "--rm" does it. Out of curiosity, what would be the value in having the container delete itself upon quitting/shutting down? Thanks!

Edited December 5, 20178 yr by Vitamin-J
My intelligence has returned.

23 hours ago, Vitamin-J said:

Update 12/4/17: Nvm, I see the "--rm" does it. Out of curiosity, what would be the value in having the container delete itself upon quitting/shutting down? Thanks!

 

In the context where the container should be always running, there is no value... I will update the documentation to remove this parameter since it creates some confusion.

might be missing someone anyone else getting the failed update message?

It's probably the update to the version 6.6.0.  I'm working on doing a new image with this version.

 

Could you check in /config/log/service.log.0 for the update URL?  It's basically a file that CP tries to download that contains the upgrade code.  I would look at it to make sure I don't miss anything.

16 hours ago, Lebowski said:

might be missing someone anyone else getting the failed update message?

Im getting the failed update message as well

 

14 hours ago, Djoss said:

It's probably the update to the version 6.6.0.  I'm working on doing a new image with this version.

 

Could you check in /config/log/service.log.0 for the update URL?  It's basically a file that CP tries to download that contains the upgrade code.  I would look at it to make sure I don't miss anything.

 

root@Tower:/mnt/cache/appdata/CrashplanPRO/conf# ls

adb/                 my.service.xml   service.login  ui.log.xml     ui_app.properties  upgradeui.properties

default.service.xml  service.log.xml  service.model  ui.properties  upgradeui.log.xml

 

Not seeing the files you asked about

Just now, wdelarme said:

 

root@Tower:/mnt/cache/appdata/CrashplanPRO/conf# ls

adb/                 my.service.xml   service.login  ui.log.xml     ui_app.properties  upgradeui.properties

default.service.xml  service.log.xml  service.model  ui.properties  upgradeui.log.xml

 

Not seeing the files you asked about

 

It's under log: /mnt/cache/appdata/CrashplanPRO/log/

6 minutes ago, Djoss said:

 

It's under log: /mnt/cache/appdata/CrashplanPRO/log/

Unable to download patch. url=https://download.crashplan.com/installs/linux/upgrade5/crashplansmb/1506661200660_4347.jar

This what you need?

2 minutes ago, wdelarme said:

Unable to download patch. url=https://download.crashplan.com/installs/linux/upgrade5/crashplansmb/1506661200660_4347.jar

This what you need?

Yes! Thanks you very much.