[Support] Djoss - CrashPlan PRO (aka CrashPlan for Small Business)

[daemian]

17 hours ago, Djoss said:

How much data do you backup? 

1.4TB

[Djoss]

4 hours ago, daemian said:

1.4TB

I guess that the size of the cache depends on size of your backup and the number of files.  My cache size is 165MB, but my backup size is only 256GB.

Maybe you can get output from other users to compare.  You can also have a quick chat with CP support team to see if they think it's an expected size.

[severanced]

I'm hoping that you can help. I've been going through this great topic and trying various things to fix this. I installed CrashPlanPRO as a migration from CrashPlan. I finally got my first backup to work and when I woke up I saw a bunch of errors in the docker for having run out of memory. I edited the memory for a maximum of 3072, restarted and (not sure if any of this is related). Crashplan won't fully start up. The logs show a constant "CrashPlanEngine is starting". I saw others were having this issue so I ran the command I saw there:

 

"docker exec CrashPlanPRO /usr/glibc-compat/sbin/ldconfig" 

 

it ran once I started the docker with no errors, but didn't seem to fix the issue. I restarted the docker a few times. I increased the memory, then removed the maximum memory as well, all to no avail.

 

Here is a sample of my log file:

 

 

Is there something I'm doing wrong? 

 

Thanks so much for your help and this docker.

[Djoss]

6 minutes ago, severanced said:

I'm hoping that you can help. I've been going through this great topic and trying various things to fix this. I installed CrashPlanPRO as a migration from CrashPlan. I finally got my first backup to work and when I woke up I saw a bunch of errors in the docker for having run out of memory. I edited the memory for a maximum of 3072, restarted and (not sure if any of this is related). Crashplan won't fully start up. The logs show a constant "CrashPlanEngine is starting". I saw others were having this issue so I ran the command I saw there:

 

"docker exec CrashPlanPRO /usr/glibc-compat/sbin/ldconfig" 

 

it ran once I started the docker with no errors, but didn't seem to fix the issue. I restarted the docker a few times. I increased the memory, then removed the maximum memory as well, all to no avail.

 

Here is a sample of my log file:

 

 

Is there something I'm doing wrong? 

 

Thanks so much for your help and this docker.

 

You probably made a typo in the max memory value.  It should be 3072M, not 3072.

[severanced]

59 minutes ago, Djoss said:

 

You probably made a typo in the max memory value.  It should be 3072M, not 3072.

 

It was as simple as that. Thanks so much!

[zero_koop]

I seem to have run into a hiccup in migrating from CrashPlan Home.  The new docker seems to be trying to reupload everything.

Setting up the new docker seemed to go without a hitch except when I first logged into the new docker it asked me for my archive key and after I entered it the docker just jammed up for a long time.  I waited about an hour and then restarted the docker.  But the next time it seemed to go through the setup fine.  However, because of the change from /data to /storage I think it caused some problems.  I didn’t realize the change until a day later and since my backups were setup to nightly it tried to run a backup overnight and that’s when it realized no files were there (in the old /data location).  So I’ve now added the new file path (/storage) and now it sees the files.  I followed the directions to NOT deselect the old path yet, but I think maybe it’s too late because it already ran a backup once and when it didn’t find the files in /data it may have deleted them from the online backup (?).

So now it says that my highest priority Backup Set (526 GB) has 224 GB to go and will take 11 days to upload!  That’s not even my biggest backup set so I’d really like to avoid the month-long upload if possible at this point.  Any hope?  Thanks.

[Djoss]

1 hour ago, zero_koop said:

I seem to have run into a hiccup in migrating from CrashPlan Home.  The new docker seems to be trying to reupload everything.

Setting up the new docker seemed to go without a hitch except when I first logged into the new docker it asked me for my archive key and after I entered it the docker just jammed up for a long time.  I waited about an hour and then restarted the docker.  But the next time it seemed to go through the setup fine.  However, because of the change from /data to /storage I think it caused some problems.  I didn’t realize the change until a day later and since my backups were setup to nightly it tried to run a backup overnight and that’s when it realized no files were there (in the old /data location).  So I’ve now added the new file path (/storage) and now it sees the files.  I followed the directions to NOT deselect the old path yet, but I think maybe it’s too late because it already ran a backup once and when it didn’t find the files in /data it may have deleted them from the online backup (?).

So now it says that my highest priority Backup Set (526 GB) has 224 GB to go and will take 11 days to upload!  That’s not even my biggest backup set so I’d really like to avoid the month-long upload if possible at this point.  Any hope?  Thanks.

Do you see your files on http://crashplanpro.com/console?

[zero_koop]

58 minutes ago, Djoss said:

Do you see your files on http://crashplanpro.com/console?

I'm not sure, it says I have 2.1 TB usage, but I don't see where I can browse those files...  It's a bit confusing because it says 2.1 TB "usage" total, but then when I click on my user (I'm the only user) it says 2.4 TB "selected" with 19.9% backup status.

 

EDIT: I may have figured it out... when browsing the server on that console website I saw a list of excluded files which reminded me that I needed to exclude a bunch of ISO files in random folders that I didn't need to backup (I forgot to do that when I had to setup my backup folders again).  After deselecting those files it rescanned and now it's just saying that only 30 GB need to be backed up.  But it's saying that will only take 50 minutes so maybe it's just scanning those files for redundancy.  I'll repost if I have any more issues.

Edited May 5, 2018 by zero_koop

[zero_koop]

Well my two highest priority backup sets are uploaded successfully now, but unfortunately my third backup set (which is my largest - movies, etc.) seems to have started over.  It says 1TB remaining and estimates 75 days to complete.  I need to find a way to actually browse my uploaded files online to see what could possibly be missing from this set.

 

Edit: it is finished backing up now, so it only took another day or two.  I didn't get a chance to see which files it was backing up that got lost in the transfer.  Who knows, but all is good now.  Thanks for your docker Djoss!

Edited May 9, 2018 by zero_koop
update

[Djoss]

On 5/5/2018 at 8:25 PM, zero_koop said:

Well my two highest priority backup sets are uploaded successfully now, but unfortunately my third backup set (which is my largest - movies, etc.) seems to have started over.  It says 1TB remaining and estimates 75 days to complete.  I need to find a way to actually browse my uploaded files online to see what could possibly be missing from this set.

You can also use the restore functionality of CrashPlan.  This allows you to browse your data.

[Woodpusherghd]

I updated unRAID to 6.5.2 RC-1 (DVB version) and now the web GUI can't connect to the CrashPlan engine.  Anyone else on 6.5.2 RC-1? I tried restarting the docker but no luck. Any suggestions?

[Djoss]

7 hours ago, Woodpusherghd said:

I updated unRAID to 6.5.2 RC-1 (DVB version) and now the web GUI can't connect to the CrashPlan engine.  Anyone else on 6.5.2 RC-1? I tried restarting the docker but no luck. Any suggestions?

Do you have something in the container log?

[mbc0]

Hi, 

 

I am not sure if mine auto updated or not but it has stopped working just this last few days.. I have attached the logs :-)

 

 

crashplanlogs.rar

[Woodpusherghd]

12 hours ago, Djoss said:

Do you have something in the container log?

 The log is attached.  

CrashPlan Log.txt

[Djoss]

5 hours ago, mbc0 said:

Hi, 

 

I am not sure if mine auto updated or not but it has stopped working just this last few days.. I have attached the logs ?

 

 

crashplanlogs.rar

I would need the container's log.  Also, look at service.log.0 to see if there is any errors.

[Djoss]

2 hours ago, Woodpusherghd said:

 The log is attached.  

CrashPlan Log.txt

And what you have in engine_error.log and engine_output.log?  If nothing special, then we need to see what happen in service.log.0.

[mbc0]

Hi,

 

engine_error & engine_output are empty but have attached service.log.0 ?

 

 

crashplanlogservicelogs.rar

[mbc0]

Not sure what has happened but it has started working again ??

[Woodpusherghd]

In the engine_error log it shows:

 

/usr/local/crashplan/bin/startCrashPlanEngine.sh: source: line 10: can't open '/usr/local/crashplan/bin/run.conf'

 

[Djoss]

5 hours ago, mbc0 said:

Not sure what has happened but it has started working again ??

Great then :)

[Djoss]

57 minutes ago, Woodpusherghd said:

In the engine_error log it shows:

 

/usr/local/crashplan/bin/startCrashPlanEngine.sh: source: line 10: can't open '/usr/local/crashplan/bin/run.conf'

 

This file should be under bin/run.conf in your appdata.  Do you have it?  If yes, does it have to correct permission?s

[Woodpusherghd]

Cache/appdata/CrashplanPro/bin/run is an empty directory.  Hmmm, that's odd.  I'll try reinstalling from scratch, not using the template.

[Woodpusherghd]

That did the trick.  

[nuticles]

I wanted to toss a question out to the community regarding slow backup times in the Crashplan Pro container.  I realize its Crashplan itself, not the container which as been awesome.  Unfortunately I just had too much data to migrate, so I needed to start fresh.  Before I go on, I want to be sure I show my appreciation for the work on the container.

 

Keep in mind I've already attempted to self serve spending several hours on both Unraid, Crashplan and Docker.  Also keep in mind I'm a relative noob.  That said, here's a summary:

 

Issue:  Despite having 4 cores (2 Real & 2 HyperTHread) assigned Crashplan dances between core to core pinned each one at 100%, but never using more than 1 (effectively only using 25% assigned resources).  I assume the majority of processing is dedup, so I figured more efficient processor usage would help,  but I am not sure.  

 

Background:

- Dual 2650 Xeons (32 Cores) / 64 GB Memory.

- Verified Cores & HT Partners are correct.

- Glances shows 500% processor (odd) but dashboard still shows 100.

- Gave Crashplan 10GB of memory (verified its done properly).

- Set CPU to 100% on Crashplan Central Console for both both active and idle user.

- Average aka "effective bandwidth" = 4 mbits" out of 15 meg up.

 

Thoughts?

 

Thanks in advance!

[Djoss]

10 hours ago, nuticles said:

I wanted to toss a question out to the community regarding slow backup times in the Crashplan Pro container.  I realize its Crashplan itself, not the container which as been awesome.  Unfortunately I just had too much data to migrate, so I needed to start fresh.  Before I go on, I want to be sure I show my appreciation for the work on the container.

 

Keep in mind I've already attempted to self serve spending several hours on both Unraid, Crashplan and Docker.  Also keep in mind I'm a relative noob.  That said, here's a summary:

 

Issue:  Despite having 4 cores (2 Real & 2 HyperTHread) assigned Crashplan dances between core to core pinned each one at 100%, but never using more than 1 (effectively only using 25% assigned resources).  I assume the majority of processing is dedup, so I figured more efficient processor usage would help,  but I am not sure.  

 

Background:

- Dual 2650 Xeons (32 Cores) / 64 GB Memory.

- Verified Cores & HT Partners are correct.

- Glances shows 500% processor (odd) but dashboard still shows 100.

- Gave Crashplan 10GB of memory (verified its done properly).

- Set CPU to 100% on Crashplan Central Console for both both active and idle user.

- Average aka "effective bandwidth" = 4 mbits" out of 15 meg up.

 

Thoughts?

 

Thanks in advance!

 

Crashplan is known to be slow... you are not alone in this situation and a lot of people complain about that.

You can always chat with CrashPlan support team to see if they have something to propose that can improve your situation.