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


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....

Link to comment
  • 2 weeks later...
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?

Link to comment

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

Link to comment

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)

Link to comment

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.
Link to comment
  • 2 weeks later...

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. 

Link to comment
  • 2 weeks later...
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
Link to comment
  • 1 month later...

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.

Link to comment

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.

Link to comment
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.

Link to comment
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.

Link to comment
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=[[[email protected]: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=[[[email protected]: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=[[[email protected]: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.

 

Link to comment
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.

Link to comment

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.