Jump to content
Djoss

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

776 posts in this topic Last Reply

Recommended Posts

Just curious if I'm the only one who can't get Crashplan to restore a file larger than about 900 MB.  I've worked with Crashplan, and they've been no help in resolving the issue.  It constantly tries to download the file, but then it stops, and says destination unavailable.  I'm about to cancel my crashplan subscription, since if I can't restore anything, it's not very helpful.   I've also tried restoring using Windows, and get the same problem....

Share this post


Link to post

I'm not having the restore issue.  Have you tried from a different network or computer? 

Share this post


Link to post
18 hours ago, Mikey160984 said:

I think, theres another update for Crashplan available.... maybe you can look into that...

Yes, a new Docker container image is now available :)

Share this post


Link to post

Mine just updated and now it seems to be stuck saying:

 

[CrashPlanEngine] starting...

Share this post


Link to post
2 minutes ago, PR. said:

Mine just updated and now it seems to be stuck saying:

 

[CrashPlanEngine] starting...

Can you look at /mnt/user/appdata/CrashPlanPRO/log/engine_error.log and /mnt/user/appdata/CrashPlanPRO/log/engine_output.log?

Share this post


Link to post

engine_error.log is reporting the following error over and over:

 

[main] INFO org.eclipse.jetty.util.log - Logging initialized @2687ms
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/usr/local/crashplan/lib/guice-4.2.2.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
[main] INFO org.reflections.Reflections - Reflections took 403 ms to scan 31 urls, producing 1526 keys and 7604 values

 

engine_output.log is reporting the following over and over:

 

CrashPlan arguments in use:
Executing CP Service
Launching CPService as system
JVM arguments in use:
-Dsun.jnu.encoding=UTF-8
-Dfile.encoding=UTF-8
-Dsun.net.inetaddr.ttl=300
-Dnetworkaddress.cache.ttl=300
-Dsun.net.inetaddr.negative.ttl=0
-Dnetworkaddress.cache.negative.ttl=0
-Dapp=CrashPlanService
-DappBaseName=CrashPlan
-Djna.nosys=true
-Djava.awt.headless=true
-DCrashPlan=CrashPlan
-Dnashorn.args=--no-deprecation-warning
-Djava.library.path=/usr/local/crashplan
-Djna.library.path=/usr/local/crashplan

 

Thanks

Share this post


Link to post

Ok this output looks normal (I have the same).

And in /mnt/user/appdata/CrashPlanPRO/log/service.log, do you see any errors?

Share this post


Link to post

Nothing is jumping out to me, but I have seen this:

 

[06.23.19 00:12:19.004 INFO  main         emory.UpgradeRetainMemoryMaxHeap] JOU:: Unable to update memory max heap size., INVALID_VALUE com.code42.core.CommandException: Unable to set -Xmx, invalid memory value (name=-Xmx, value=3G)
STACKTRACE:: INVALID_VALUE com.code42.core.CommandException: Unable to set -Xmx, invalid memory value (name=-Xmx, value=3G)
    at com.code42.javaoptions.JavaOptionUpdater.setOption(JavaOptionUpdater.java:182)
    at com.code42.service.maxheapmemory.MaxHeapMemoryUpdateJavaOption.updateJavaOption(MaxHeapMemoryUpdateJavaOption.java:39)
    at com.code42.service.maxheapmemory.UpgradeRetainMemoryMaxHeap.run(UpgradeRetainMemoryMaxHeap.java:34)
    at com.backup42.service.upgrade.UpgradeManager.runUpgrades(UpgradeManager.java:100)
    at com.backup42.service.upgrade.UpgradeManager.run(UpgradeManager.java:78)
    at com.backup42.service.CPService.checkUpgrade(CPService.java:1473)
    at com.backup42.service.CPService.start(CPService.java:655)
    at com.backup42.service.CPService.main(CPService.java:2051)

Share this post


Link to post

In your container's settings, did you set something for "Maximum Memory" ?

Share this post


Link to post
Posted (edited)

Yup,  there's '3G' in there which has been in there since I set it up in 2017, I have quite a lot of files and in the past Java would crash out with the default allocation (definitely did in Windows, can't remember about the Docker container version).

 

I removed the value and still saw the same issue (was still reporting '3G'), I've now set it to '1024M' which I believe is the default value and it seems to have started correctly, currently syncing blocks...

 

Fingers crossed!

 

Thanks

Edited by PR.

Share this post


Link to post

Ok, I will push a fix for this.

Share this post


Link to post

Set back to 3G this morning (it reported an out of memory crash with only 1024M) and all seems to be working again.

 

Thanks for the quick response!

Share this post


Link to post

Updated to the latest Docker image this morning and have been stuck with the message "Code42 cannot connect to its background service" ever since.

 

Error in service.log that appears to be looping as the service starts and restarts is:

 

[07.01.19 13:51:31.774 ERROR SMListener 0 p42.service.ClientServiceManager] CSM:: Service MaxHeapMemoryService failed while STARTING, INVALID_VALUE com.code42.core.CommandException: Unable to set -Xmx, invalid memory value (name=-Xmx, value=4G)
STACKTRACE:: INVALID_VALUE com.code42.core.CommandException: Unable to set -Xmx, invalid memory value (name=-Xmx, value=4G)
	at com.code42.javaoptions.JavaOptionUpdater.setOption(JavaOptionUpdater.java:182)
	at com.code42.service.maxheapmemory.MaxHeapMemoryUpdateJavaOption.updateJavaOption(MaxHeapMemoryUpdateJavaOption.java:39)
	at com.code42.service.maxheapmemory.MaxHeapMemoryService.handleJavaMemoryHeapMaxEvent(MaxHeapMemoryService.java:50)
	at com.code42.service.maxheapmemory.MaxHeapMemoryService.startUp(MaxHeapMemoryService.java:39)
	at com.google.common.util.concurrent.AbstractIdleService$DelegateService$1.run(AbstractIdleService.java:62)
	at com.google.common.util.concurrent.Callables$4.run(Callables.java:119)
	at java.base/java.lang.Thread.run(Unknown Source)

Resolved by setting a value for the Maximum Memory value, as suggested above. It was blank originally. 

Share this post


Link to post
Posted (edited)

Crashplan is so slow its a waste of time. this is after 1 month...

 

EEmbpOFl.png

 

200/200mbit dedicated fiber, no shaping, no aup, etc.

 

8420179381.png

Edited by eXtremeSHOK

Share this post


Link to post
Posted (edited)
9 hours ago, eXtremeSHOK said:

Crashplan is so slow its a waste of time. this is after 1 month...

 

[...]

This was discussed already in this thread if you search. You can edit the config file to disable de-duplicaiton and presto, Crashplan will use your max upload...  With a nice upload like you have, it's way faster than having Crashplan trying to guess what is necessary or not to upload, hence reducing the upload strongly.

 

Edit: you can also see that here: https://support.code42.com/CrashPlan/4/Configuring/Unsupported_changes_to_CrashPlan_de-duplication_settings

Edited by denishay

Share this post


Link to post

How long does it take to backup for the first time? Mine has been stuck in "preparing to backup" for about 2 hours now. I don't know what is going on.

 

Do you have to keep the webGUI open as well? I assume no as it wouldn't make sense but right now I am not sure why the backup has not started. I am doing the trial right now.

Share this post


Link to post

My crashplan has been saying "unable to connect to destination" for weeks, and I have no clue what changed. It's been fine for months without any interaction. Any ideas what I could check? I've tried restarting my whole server, restarting the docker itself, doing "rz, restart" in the internal crashplan console window. Nothing has made a difference.

Share this post


Link to post
On 8/30/2019 at 4:32 PM, razierklinge said:

My crashplan has been saying "unable to connect to destination" for weeks, and I have no clue what changed. It's been fine for months without any interaction. Any ideas what I could check? I've tried restarting my whole server, restarting the docker itself, doing "rz, restart" in the internal crashplan console window. Nothing has made a difference.

Try to look at /mnt/user/appdata/CrashPlanPRO/log/service.log.  You may have more details about the issue.

Share this post


Link to post
On 8/30/2019 at 2:35 PM, Ustrombase said:

How long does it take to backup for the first time? Mine has been stuck in "preparing to backup" for about 2 hours now. I don't know what is going on.

CrashPlan is slow... is you backup still stuck?

On 8/30/2019 at 2:35 PM, Ustrombase said:

Do you have to keep the webGUI open as well? I assume no as it wouldn't make sense but right now I am not sure why the backup has not started. I am doing the trial right now.

No, the GUI doesn't need to be opened.

Share this post


Link to post
23 hours ago, Djoss said:

Try to look at /mnt/user/appdata/CrashPlanPRO/log/service.log.  You may have more details about the issue.

So I'm seeing lots of stuff like this:
[08.30.19 23:09:58.735 INFO  erTimeoutWrk e42.messaging.peer.PeerConnector] PC:: Cancelling connection attempt due to timeout - pending connection=PendingConnection[timeout(ms) = 30000, startTime = Fri Aug 30 23:09:23 MST 2019, remotePeer = RemotePeer-[guid=4200, state=CONNECTING]; Session-null, pendingChannel = com.code42.messaging.network.nio.NioNetworkLayer$1@57340d4d][08.30.19 23:09:58.737 INFO  erTimeoutWrk 42.messaging.network.nio.Context] Channel became inactive. closedBy=THIS_SIDE, reason='Connect cancelled', channel=Context@1942087335[channelState=0], remote=[[4200@216.17.8.4:443(server)], transportPbK=X509.checksum(be4b2a71961d23dabb77ea3851a2fc8d)]
[08.30.19 23:10:23.738 INFO  re-event-2-4 abre.SabrePendingChannelListener] SABRE::Channel connect failed for guid 42, cause=io.netty.channel.ConnectTimeoutException: connection timed out: /162.222.41.12:443
[08.30.19 23:10:23.739 INFO  re-event-2-4 .handler.ChannelLifecycleHandler] SABRE:: Channel became inactive. closedBy=THIS_SIDE, channel=[id: 0xe810da0f], sessionState=RemotePeer-[guid=42, state=CONNECTING]; Session-[localID=916848385999105934, remoteID=0, closed=false, remoteIdentity=ENDPOINT, local=null, remote=null]
[08.30.19 23:11:13.740 INFO  erTimeoutWrk e42.messaging.peer.PeerConnector] PC:: Cancelling connection attempt due to timeout - pending connection=PendingConnection[timeout(ms) = 30000, startTime = Fri Aug 30 23:10:38 MST 2019, remotePeer = RemotePeer-[guid=4200, state=CONNECTING]; Session-null, pendingChannel = com.code42.messaging.network.nio.NioNetworkLayer$1@2259404e][08.30.19 23:11:13.740 INFO  erTimeoutWrk 42.messaging.network.nio.Context] Channel became inactive. closedBy=THIS_SIDE, reason='Connect cancelled', channel=Context@1972117142[channelState=0], remote=[[4200@216.17.8.47:4282]]
[08.30.19 23:12:13.743 INFO  erTimeoutWrk e42.messaging.peer.PeerConnector] PC:: Cancelling connection attempt due to timeout - pending connection=PendingConnection[timeout(ms) = 30000, startTime = Fri Aug 30 23:11:43 MST 2019, remotePeer = RemotePeer-[guid=4200, state=CONNECTING]; Session-null, pendingChannel = com.code42.messaging.network.nio.NioNetworkLayer$1@2a52b0f]
[08.30.19 23:12:13.743 INFO  erTimeoutWrk 42.messaging.network.nio.Context] Channel became inactive. closedBy=THIS_SIDE, reason='Connect cancelled', channel=Context@2116878626[channelState=0], remote=[[4200@216.17.8.48:4282]]

 

Here's the odd thing. I wiped out my install and even recreated docker.img. When I did all that I was able to login and say I wanted to replace an existing backup. It said it would pull my settings and have me login again, and THAT is when things go to shit. It sits on "Connecting..." indefinitely and those messages above are what I see in the logs. If I kill the docker and restart it I am unable to login and get "Unable to sign in cannot connect to server" messages. The only time I can login is if I wipe out my container config and start fresh.

 

I've gone into the container console and tried pinging the IPs it's unable to connect to and it seems to work fine. I'm very confused why this is suddenly broken.

 

Share this post


Link to post

I would try to contact CrashPlan support.  I think they can assign you to a different server.

Just don't tell them your are running CP in a container ;)

Share this post


Link to post
6 hours ago, Djoss said:

I would try to contact CrashPlan support.  I think they can assign you to a different server.

Just don't tell them your are running CP in a container ;)

Too late :( I contacted them last week and he said without any prompting from me that he could see I'm running the app in an unsupported version of Linux and that I would need to run it from a supported OS before he could provide any support.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.