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


1020 posts in this topic Last Reply

Recommended Posts

Thank you for this image, it has worked great for years.

 

After upgrading to the latest docker, however. And deleting the cache, Crashplan synchronizes with the destination server up to %54 or so and then there is this exception in log and synchronization starts at 0% again in a loop.

 

[04.12.21 13:00:03.736 WARN  er1WeDftWkr4 ssaging.peer.PeerSessionListener] PSL:: Invalid connect state during sessionEnded after being connected, com.code42.peer.exception.InvalidConnectStateException: RP:: Illegal DISCONNECTED state attempt, session is open RemotePeer-[guid=41, state=CONNECTED]; Session-[localID=1002437243897076021, remoteID=1002437243745158716, layer=Peer::Sabre, closed=false, expiration=null, remoteIdentity=STORAGE, local=172.17.0.6:45100, remote=162.222.41.249:4287]
STACKTRACE:: com.code42.peer.exception.InvalidConnectStateException: RP:: Illegal DISCONNECTED state attempt, session is open RemotePeer-[guid=41, state=CONNECTED]; Session-[localID=1002437243897076021, remoteID=1002437243745158716, layer=Peer::Sabre, closed=false, expiration=null, remoteIdentity=STORAGE, local=172.17.0.6:45100, remote=162.222.41.249:4287]
        at com.code42.messaging.peer.ConnectionStateMachine.setState(ConnectionStateMachine.java:106)
        at com.code42.messaging.peer.ConnectionStateMachine.updateState(ConnectionStateMachine.java:248)
        at com.code42.messaging.peer.RemotePeer.lambda$updateStateFromEvent$0(RemotePeer.java:415)
        at com.code42.messaging.peer.RemotePeer.updateState(RemotePeer.java:468)
        at com.code42.messaging.peer.RemotePeer.updateStateFromEvent(RemotePeer.java:415)
        at com.code42.messaging.peer.RemotePeer.onSessionEnded(RemotePeer.java:563)
        at com.code42.messaging.peer.PeerSessionListener.sessionEnded(PeerSessionListener.java:133)
        at com.code42.messaging.SessionImpl.notifySessionEnding(SessionImpl.java:239)
        at com.code42.messaging.mde.ShutdownWork.handleWork(ShutdownWork.java:27)
        at com.code42.messaging.mde.UnitOfWork.processWork(UnitOfWork.java:163)
        at com.code42.messaging.mde.UnitOfWork.run(UnitOfWork.java:147)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.base/java.lang.Thread.run(Unknown Source)

 

 

Link to post
  • Replies 1k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Yes, I will provide a new image with the new CrashPlan version integrated.   Thanks for reporting this.  This is currently the most efficient wait for me to know there is a new CrashPlan ver

Support for CrashPlan PRO (aka CrashPlan for Small Business) docker container   Application Name: CrashPlan PRO (aka CrashPlan for Small Business) Application Site: https://www.crashplan.com

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

Posted Images

On 4/8/2021 at 10:49 AM, brovue said:

 I have unable to connect like SPOautos posted.

 

thank you

 

Can you look at /mnt/user/appdata/CrashPlanPRO/log/service.log.0 to see if there is anything interesting (errors)?

Link to post
On 4/12/2021 at 4:45 PM, Jagadguru said:

Thank you for this image, it has worked great for years.

 

After upgrading to the latest docker, however. And deleting the cache, Crashplan synchronizes with the destination server up to %54 or so and then there is this exception in log and synchronization starts at 0% again in a loop.

 

[04.12.21 13:00:03.736 WARN  er1WeDftWkr4 ssaging.peer.PeerSessionListener] PSL:: Invalid connect state during sessionEnded after being connected, com.code42.peer.exception.InvalidConnectStateException: RP:: Illegal DISCONNECTED state attempt, session is open RemotePeer-[guid=41, state=CONNECTED]; Session-[localID=1002437243897076021, remoteID=1002437243745158716, layer=Peer::Sabre, closed=false, expiration=null, remoteIdentity=STORAGE, local=172.17.0.6:45100, remote=162.222.41.249:4287]
STACKTRACE:: com.code42.peer.exception.InvalidConnectStateException: RP:: Illegal DISCONNECTED state attempt, session is open RemotePeer-[guid=41, state=CONNECTED]; Session-[localID=1002437243897076021, remoteID=1002437243745158716, layer=Peer::Sabre, closed=false, expiration=null, remoteIdentity=STORAGE, local=172.17.0.6:45100, remote=162.222.41.249:4287]
        at com.code42.messaging.peer.ConnectionStateMachine.setState(ConnectionStateMachine.java:106)
        at com.code42.messaging.peer.ConnectionStateMachine.updateState(ConnectionStateMachine.java:248)
        at com.code42.messaging.peer.RemotePeer.lambda$updateStateFromEvent$0(RemotePeer.java:415)
        at com.code42.messaging.peer.RemotePeer.updateState(RemotePeer.java:468)
        at com.code42.messaging.peer.RemotePeer.updateStateFromEvent(RemotePeer.java:415)
        at com.code42.messaging.peer.RemotePeer.onSessionEnded(RemotePeer.java:563)
        at com.code42.messaging.peer.PeerSessionListener.sessionEnded(PeerSessionListener.java:133)
        at com.code42.messaging.SessionImpl.notifySessionEnding(SessionImpl.java:239)
        at com.code42.messaging.mde.ShutdownWork.handleWork(ShutdownWork.java:27)
        at com.code42.messaging.mde.UnitOfWork.processWork(UnitOfWork.java:163)
        at com.code42.messaging.mde.UnitOfWork.run(UnitOfWork.java:147)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.base/java.lang.Thread.run(Unknown Source)

Is it still doing that ?  Do you have more details in Tools->History ?

Link to post
52 minutes ago, Djoss said:

Is it still doing that ?  Do you have more details in Tools->History ?

Yes it is still doing it, but I noticed that there is destination maintenance running at the same time and some times showing in the status line. So I have decided to shut down CrashplanPRO for four days to give maintenance a chance to run unfettered.

Link to post
10 hours ago, Jagadguru said:

Yes it is still doing it, but I noticed that there is destination maintenance running at the same time and some times showing in the status line. So I have decided to shut down CrashplanPRO for four days to give maintenance a chance to run unfettered.


Ok, let me know if the issue persists after that.

Link to post

Started CrashplanPRO container up today and unfortunately it is still happening. It's now getting to 77% though. Here is the history:

 

I 04/14/21 05:46PM [CS Domains] Scanning for files completed in 12 minutes: 9 files (90GB) found
I 04/14/21 05:46PM [CrashPlan Docker Internal] Scanning for files to back up
I 04/14/21 05:58PM [CrashPlan Docker Internal] Scanning for files completed in 12 minutes: 179 files (360.10MB) found
I 04/18/21 10:19PM Code42 started, version 8.6.0, GUID 858699052691327104
I 04/18/21 10:49PM [CS Everything except Google Drive live mount, Trash and domains Backup Set] Scanning for files to back up
I 04/19/21 10:41AM [CS Everything except Google Drive live mount, Trash and domains Backup Set] Scanning for files completed in 11.9 hours: 800,863 files (3.20TB) found
I 04/19/21 10:41AM [CS Domains] Scanning for files to back up
I 04/19/21 10:52AM [CS Domains] Scanning for files completed in 12 minutes: 9 files (90GB) found
I 04/19/21 10:52AM [CrashPlan Docker Internal] Scanning for files to back up
I 04/19/21 11:04AM [CrashPlan Docker Internal] Scanning for files completed in 12 minutes: 180 files (363.10MB) found

 

The crash sometimes seems to coincide with the finish of a Scan for files. 

 

Now it says "Waiting for connection," although I can ping the destination server just fine from within the container.  

 

It also keeps saying  the service.log.0 pending restore cancelled

[04.19.21 19:58:18.081 INFO  3362_BckpSel tore.BackupClientRestoreDelegate] BC::stopRestore(): idPair=858699052691327104>41, selectedForRestore=false, event=STOP_REQUESTED canceled=false
[04.19.21 19:58:18.081 INFO  3362_BckpSel tore.BackupClientRestoreDelegate] BC::Not selected for restore
[04.19.21 19:58:18.081 INFO  3362_BckpSel tore.BackupClientRestoreDelegate] BC::0 pending restore canceled

Edited by Jagadguru
more info
Link to post

Hello All 

 

Quick question - I have re installed CrashPlan and set the storage location to /mnt/user/

 

When I try and do a restore even tho the share is open - CrashPlan says its read only. 

What am I missing? I assume a setting somewhere? 

 

image.thumb.png.619cacb32757900e04dc6da4007d91e1.png

Thanks 

Edited by IKWeb
Link to post
3 hours ago, IKWeb said:

Hello All 

 

Quick question - I have re installed CrashPlan and set the storage location to /mnt/user/

 

When I try and do a restore even tho the share is open - CrashPlan says its read only. 

What am I missing? I assume a setting somewhere? 

 

image.thumb.png.619cacb32757900e04dc6da4007d91e1.png

Thanks 

 

By default, the mapping of /storage is read-only.  If you want to restore to /storage, you need to edit the container settings and change /storage to be read/write (you need to enable advanced view to do this).

Link to post
On 4/19/2021 at 1:18 AM, PaulW08 said:

Is it just me or is there no my.service.xml anymore in the conf folder?

 

Trying to essentially turn deduplication off.

So still trying to find this file and it doesn't seem to exist. Have tried a clean install and same issue. My backups used to be pretty fast and max out my 40Mbps bandwidth, but now it seems like it's only uploading at 256Kbps.... Before in the past I was able to edit the my.service.xml and turn off deduplication and that would speed it up, but now it just seems like the file is completely gone.

Link to post
5 minutes ago, PaulW08 said:

So still trying to find this file and it doesn't seem to exist. Have tried a clean install and same issue. My backups used to be pretty fast and max out my 40Mbps bandwidth, but now it seems like it's only uploading at 256Kbps.... Before in the past I was able to edit the my.service.xml and turn off deduplication and that would speed it up, but now it just seems like the file is completely gone.

 

Yes, CrashPlan removed this file.  They always said its modification was not supported.... but they have taken a step further in recent versions.

Link to post
12 minutes ago, Djoss said:

 

Yes, CrashPlan removed this file.  They always said its modification was not supported.... but they have taken a step further in recent versions.

Ah bummer! Is there anything you think I can do or am I kind of SOL now?

Link to post
1 minute ago, PaulW08 said:

Ah bummer! Is there anything you think I can do or am I kind of SOL now?

I'm not aware of any other workaround...

But note that while the upload speed is lower, the amount of data to upload should also be much lower.

Link to post
18 minutes ago, Djoss said:

I'm not aware of any other workaround...

But note that while the upload speed is lower, the amount of data to upload should also be much lower.

Thanks for the reply. RIght now I'm sitting at 84,018 files (1TB) to do with 54.3 days remaining which doesn't seem normal vs what I was getting a few months ago.

 

I do see this in the logs:

 

21/04/2021 07:59:01 32 bpp, depth 24, little endian
21/04/2021 07:59:01 true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
21/04/2021 07:59:01 no translation needed
21/04/2021 07:59:01 Enabling NewFBSize protocol extension for client 127.0.0.1
21/04/2021 07:59:01 Using image quality level 6 for client 127.0.0.1
21/04/2021 07:59:01 Using JPEG subsampling 0, Q79 for client 127.0.0.1
21/04/2021 07:59:01 Using compression level 9 for client 127.0.0.1
21/04/2021 07:59:01 Enabling LastRect protocol extension for client 127.0.0.1
21/04/2021 07:59:01 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFECC)
21/04/2021 07:59:01 Using tight encoding for client 127.0.0.1
21/04/2021 07:59:02 client 6 network rate 314.6 KB/sec (29841.5 eff KB/sec)
21/04/2021 07:59:02 client 6 latency: 4.6 ms
21/04/2021 07:59:02 dt1: 0.0077, dt2: 0.1264 dt3: 0.0046 bytes: 41461
21/04/2021 07:59:02 link_rate: LR_LAN - 4 ms, 314 KB/s
21/04/2021 07:59:02 client_set_net: 127.0.0.1 0.0000
21/04/2021 07:59:03 active keyboard: turning X autorepeat off.

 

 

Is it basically saying my network upload rate is 314.6 KB/Sec?

Edited by PaulW08
Link to post
1 hour ago, PaulW08 said:

Thanks for the reply. RIght now I'm sitting at 84,018 files (1TB) to do with 54.3 days remaining which doesn't seem normal vs what I was getting a few months ago.

 

I do see this in the logs:

 

21/04/2021 07:59:01 32 bpp, depth 24, little endian
21/04/2021 07:59:01 true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
21/04/2021 07:59:01 no translation needed
21/04/2021 07:59:01 Enabling NewFBSize protocol extension for client 127.0.0.1
21/04/2021 07:59:01 Using image quality level 6 for client 127.0.0.1
21/04/2021 07:59:01 Using JPEG subsampling 0, Q79 for client 127.0.0.1
21/04/2021 07:59:01 Using compression level 9 for client 127.0.0.1
21/04/2021 07:59:01 Enabling LastRect protocol extension for client 127.0.0.1
21/04/2021 07:59:01 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFECC)
21/04/2021 07:59:01 Using tight encoding for client 127.0.0.1
21/04/2021 07:59:02 client 6 network rate 314.6 KB/sec (29841.5 eff KB/sec)
21/04/2021 07:59:02 client 6 latency: 4.6 ms
21/04/2021 07:59:02 dt1: 0.0077, dt2: 0.1264 dt3: 0.0046 bytes: 41461
21/04/2021 07:59:02 link_rate: LR_LAN - 4 ms, 314 KB/s
21/04/2021 07:59:02 client_set_net: 127.0.0.1 0.0000
21/04/2021 07:59:03 active keyboard: turning X autorepeat off.

 

 

Is it basically saying my network upload rate is 314.6 KB/Sec?

 

No, these logs are not related to CrashPlan, but to the VNC connection for the UI.

 

In CrashPlan, you can look at Tools->History.  You should see the "effective rate".  The should give you an indication of how effective is the deduplication.

Link to post
8 minutes ago, Djoss said:

 

No, these logs are not related to CrashPlan, but to the VNC connection for the UI.

 

In CrashPlan, you can look at Tools->History.  You should see the "effective rate".  The should give you an indication of how effective is the deduplication.

Thanks for that. Looks like it's only 2.1 Mbps. Welp I guess I have a decision to make to stay on Crashplan or look for something else. Thanks for all your help with this!

Link to post
7 hours ago, Djoss said:

 

By default, the mapping of /storage is read-only.  If you want to restore to /storage, you need to edit the container settings and change /storage to be read/write (you need to enable advanced view to do this).


Hello @Djoss thank you for taking the time to reply. When I look at advance settings I cant see what option would be to make that location writable. 

Are you able to advise, or let me if I can find some help docs only to read though? 

Many Thanks  

Link to post
47 minutes ago, IKWeb said:


Hello @Djoss thank you for taking the time to reply. When I look at advance settings I cant see what option would be to make that location writable. 

Are you able to advise, or let me if I can find some help docs only to read though? 

Many Thanks  

When you edit the container settings, there is a toggle at the upper-right corner that allows you to switch to the Advanced View.  Once in that view, you will be able to click the Edit button of the "Storage" setting.  In this new window, you can change the "Access Mode" to "Read/Write".

Link to post

Yes, after further investigation it is definitely the crash above that is causing me to loose connectivity to Crashplan's server. The crash breeks the messaging system with code42 and then because of that TLS breaks down with this error:

 

[04.21.21 19:08:52.440 INFO  re-event-2-3 .handler.ChannelExceptionHandler] SABRE:: Decoder issue in channel pipeline! msg=com.code42.messaging.MessageException: Message exceeded maximum size. Size=20975080. cause=com.code42.messaging.MessageException: Message exceeded maximum size. Size=20975080. Closing ctx=ChannelHandlerContext(EXCEPTION, [id: 0x6ddd77d8, L:/172.17.0.8:43432 - R:/162.222.41.249:4287])

 

And this problem started immediately after I was forced to enable 2FA. I thought  it was just that the old version didn't work with 2FA so I upgraded the container but then this

Edited by Jagadguru
Link to post

Just received this from Code42 Support:

 

Quote

I see that the archive was recently (~10 days ago) in maintenance, and that it's likely being impacted by a post-maintenance synchronization issue we're working to fix at this time.

I have taken corrective action and signed you out of the app on the computer. Please sign back in and monitor the synchronization - we should see it complete this time.

This has nothing to do with the 2FA implementation, as that is only used for website login. There was an app released shortly thereafter, which is the cause of the problem. Apologies for any frustration or inconvenience this had caused.

 

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.