5 hours ago, Djoss said:

 

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.

 

Thanks for the quick response! 

 

I realize Crashplan being slow known, but since I am seeing a very specific issue I want to be sure I am diligent.  I know myself and being complacent with known problems has caused me to miss opportunities.  

 

Is my specific issue, where Crashplan only utilizes only 1 core (out of 4 assigned) considered part of the known error?  The reason I ask is I've seen a lot of posts about "high CPU" however nothing about not utilizing multiple cores properly.  Maybe the de-dup or compression process is single threaded?

I will check with Crashplan, but if anyone else has ideas or has this problem let me know.  I mean its very possible I hosed a configuration somewhere since I'm a n00b

Hello! I've gone and mucked something up and I hope you can help.

 

I originally had a WHS 2011 box backed up with CrashPlan Home, I've since built a new server using Unraid and migrated to CrashPlan Pro via the docker app and adopted the WHS 2011 backup successfully. It was working fine for a month, no troubles.

 

However, in building my VM to host the WHS 2011 server so my windows clients can continue to backup to it, I had to move some of the vdisks around to better make use of my cache drive. To do that, I needed to bring down the array and thus the dockers - I moved the vdisks successfully and re-started the array, however the CrashPlan docker container did not come back up.

 

I monkeyed with it a bit, and decided it was best to just delete the container and re-install. This worked and the webgui came to life and asked for my user id and password, then mentioned that it was a new device (because I deleted the files in the appdirectory) and if I'd like to replace a device, which I did. However, after skipping the file transfer portion of the process it begins to transfer settings at which point it asks for the user credentials again - that part fails with the message "Unable to sign in. Unknown error."

 

If I try to restart the container, the service will no longer start and just sits in a crashplan service starting loop (according to the log).

 

I do notice that Cod42 has mentioned changes on their website, so it may be on their end and I'm chasing my tail, but any help is appreciated!

11 hours ago, Michael_P said:

Hello! I've gone and mucked something up and I hope you can help.

 

I originally had a WHS 2011 box backed up with CrashPlan Home, I've since built a new server using Unraid and migrated to CrashPlan Pro via the docker app and adopted the WHS 2011 backup successfully. It was working fine for a month, no troubles.

 

However, in building my VM to host the WHS 2011 server so my windows clients can continue to backup to it, I had to move some of the vdisks around to better make use of my cache drive. To do that, I needed to bring down the array and thus the dockers - I moved the vdisks successfully and re-started the array, however the CrashPlan docker container did not come back up.

 

I monkeyed with it a bit, and decided it was best to just delete the container and re-install. This worked and the webgui came to life and asked for my user id and password, then mentioned that it was a new device (because I deleted the files in the appdirectory) and if I'd like to replace a device, which I did. However, after skipping the file transfer portion of the process it begins to transfer settings at which point it asks for the user credentials again - that part fails with the message "Unable to sign in. Unknown error."

 

If I try to restart the container, the service will no longer start and just sits in a crashplan service starting loop (according to the log).

 

I do notice that Cod42 has mentioned changes on their website, so it may be on their end and I'm chasing my tail, but any help is appreciated!

You can look at the following files, located under the "log" directory in your app data folder:

• engine_error.log
• engine_output.log
• service.log.0

Here's the logs

Service Logs.zip

13 hours ago, Michael_P said:

Here's the logs

Service Logs.zip

According to the logs, the engine is not starting because it cannot find a file.

You tried to re-install with an empty app data folder and it didn't fix the issue?

Yes, the only way to get it to service start is to remove it, delete the CrashPlanPRO folder in appdata then re-install. Then, if the container is stopped and re-started it gets stuck in the loop again.

6 minutes ago, Michael_P said:

Yes, the only way to get it to service start is to remove it, delete the CrashPlanPRO folder in appdata then re-install. Then, if the container is stopped and re-started it gets stuck in the loop again.

 

Maybe you could try the following:

• Stop the container.
• Start an archive maintenance.  See: https://support.code42.com/Administrator/5/Monitoring_and_managing/Archive_maintenance#Add_a_job_to_the_archive_maintenance_queue
• Remove your app data.
• Start the container.

Same result, attempting to take over another device ends up with the second login prompt which ends in "unable to sign in unknown error" - restarting the container just loops the crashplan engine starting

 

11 hours ago, Michael_P said:

Same result, attempting to take over another device ends up with the second login prompt which ends in "unable to sign in unknown error" - restarting the container just loops the crashplan engine starting

 

Are you restarting the container after the backup completes?

If I attempt to take over an existing device (the old container's backups), it asks me to re-enter my credentials, which fails to the unable to sign in unknown error message. If I restart the container it loops crashplan engine starting and the webui says unable to connect to engine.

 

If i delete the appdata CrashPlanPRO folder, it will start and ask to setup again - if I choose to add a new device, it completes the backup and is OK until the container is restarted which loops the crashplan engine starting message in the log and the unable to connect to engine in the UI

I've tried everything I can think of and I just can't make it run again after restarting the container.

On 5/12/2018 at 5:18 PM, Michael_P said:

I've tried everything I can think of and I just can't make it run again after restarting the container.

I would suggest you to contact CrashPlan support.  Just don't say you are running CP in a container

Keep us updated if you got a solution.

Well they weren't able to help, their "tool" already knew I was running it under unraid so their suggestion is to use a supported OS..

17 minutes ago, Michael_P said:

Well they weren't able to help, their "tool" already knew I was running it under unraid so their suggestion is to use a supported OS..

So let's restart from the beginning:  Are you using default container settings?  Did you try to completely remove the container and re-install it from scratch (again, with default settings)?

24 minutes ago, Michael_P said:

Well they weren't able to help, their "tool" already knew I was running it under unraid so their suggestion is to use a supported OS..

By the way, did you sent any log or they were able to get them remotely?

I didn't send them any files, just described the issue in the trouble ticket (only mentioned the errors, and that it was a Linux OS). He said his "tools" show the device is running unraid and they don't support it.

 

I've tried removing and re-installing the container, deleting the CrashPlanPRO folder in appdata before re-installing the container. I've tried changing the password in CrashPlan just to make sure it wasn't a weird character. I've tried the defaults, i've tried allocating more memory (32G at one point), i've tried different network settings.

 

No matter what i've tried, it won't start again if it stop the container.

 

The log mentions a 000005.ldb file it can't find, is that significant as the only ldb file I can find is a 000003.ldb?

 

Do you think it's permissions related?

Hiya. 

I updated to 6.5.2 this afternoon and have the following error when I head to the Crashplan UI:

Code42 wasn't able to upgrade but will reattempt in an hour.

When it reattempts, it fails again.

Unfortunately, I don't know if the error appeared before I updated from unRAID 6.5.1 as I didn't check immediately before I upgraded. 

It wasn't there yesterday (when I was on 6.5.1), though.

2 hours ago, Michael_P said:

I didn't send them any files, just described the issue in the trouble ticket (only mentioned the errors, and that it was a Linux OS). He said his "tools" show the device is running unraid and they don't support it.

 

I've tried removing and re-installing the container, deleting the CrashPlanPRO folder in appdata before re-installing the container. I've tried changing the password in CrashPlan just to make sure it wasn't a weird character. I've tried the defaults, i've tried allocating more memory (32G at one point), i've tried different network settings.

 

No matter what i've tried, it won't start again if it stop the container.

 

The log mentions a 000005.ldb file it can't find, is that significant as the only ldb file I can find is a 000003.ldb?

 

Do you think it's permissions related?

I don't think it's a permission issue.  If with default settings it doesn't work, there is something else.

Are you running the latest stable version of unRAID?

 

I will update the docker image to include the new CP version.  Maybe this version will fixe your issue...

3 hours ago, jademonkee said:

Hiya. 

I updated to 6.5.2 this afternoon and have the following error when I head to the Crashplan UI:

Code42 wasn't able to upgrade but will reattempt in an hour.

When it reattempts, it fails again.

Unfortunately, I don't know if the error appeared before I updated from unRAID 6.5.1 as I didn't check immediately before I upgraded. 

It wasn't there yesterday (when I was on 6.5.1), though.

 

That's not really an issue.  It just means that I need to provide a new docker image that include the latest CP version

I'm working on this...

New image version available.

11 hours ago, Djoss said:

 

That's not really an issue.  It just means that I need to provide a new docker image that include the latest CP version

I'm working on this...

Oh haha. I thought it updated itself.

Thanks so much!

I removed the container, deleted the entire appdata share, re-created the appdata share, re-installed the container, same issue. It's cursed.

7 hours ago, Michael_P said:

I removed the container, deleted the entire appdata share, re-created the appdata share, re-installed the container, same issue. It's cursed.

Before restarting the container, did you check the content of the appdata folder to see if the missing file is there before the restart?

 

Also, in the past there was a user with a really strange issue (with another container) and re-creating the docker image (/mnt/user/system/docker/docker.img) fixed it.  If you want to try that, you need to disable Docker under Settings->Docker.  Note that you can re-install your container easily with the Community Applications plugin, be showing the previously installed apps.

On 3/5/2018 at 1:55 PM, egtrev said:

Hi, I'm migrating from Crashplan Home and want to make sure I do it correctly.

 

I'm currently using gfjardim Crashplan Docker.

I backup to Crashplan Cloud and I also backup to a local unassigned unRAID USB device.

Does this docker support backing up to an unRAID unassigned device?

If so do I need to setup the path so the docker will list it as a backup location?

 

 

I've finally went ahead and moved to Crashplan for Business and this Docker.

I'm a bit stuck and unsure what to do next, I'm following the guide at Github for taking over an existing backup, I'm at this step:

6. Update the file selection by re-adding your files. Do not unselect missing items yet.

 

All I see is a missing icon by all my files, how do I re-add them? I don't see that option.

Old backup file path was mnt/user and new dockers file path seems to be root/storage/mnt/user

 

Any help is appreciated

38 minutes ago, egtrev said:

 

I've finally went ahead and moved to Crashplan for Business and this Docker.

I'm a bit stuck and unsure what to do next, I'm following the guide at Github for taking over an existing backup, I'm at this step:

6. Update the file selection by re-adding your files. Do not unselect missing items yet.

 

All I see is a missing icon by all my files, how do I re-add them? I don't see that option.

Old backup file path was mnt/user and new dockers file path seems to be root/storage/mnt/user

 

Any help is appreciated

When using default container settings, you need to re-select you files that are now under /storage.  It's not obvious to see, but you can scroll down if you don't see the folder.