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


Recommended Posts

1 hour ago, Djoss said:

Do you have configured a backup schedule in CrashPlan ?

I have it set to "Always Run". I originally had frequency set to "every day" but I changed it to 6 hours in an attempt to have it automatically restart without intervention, but I think I need it to be shorter. I'm not eager to do shorter though cause I feel like the backup re-reads files every time even if its in the middle of an upload (unconfirmed suspicion)

Link to comment
9 minutes ago, ryancacophony said:

I have it set to "Always Run". I originally had frequency set to "every day" but I changed it to 6 hours in an attempt to have it automatically restart without intervention, but I think I need it to be shorter. I'm not eager to do shorter though cause I feel like the backup re-reads files every time even if its in the middle of an upload (unconfirmed suspicion)

Ok.  You can check under Tools->History to see if there is any indication.

Else, you can check in log file located at /mnt/user/appdata/CrashPlanPRO/log/service.log.0

Link to comment
3 minutes ago, Djoss said:

Ok.  You can check under Tools->History to see if there is any indication.

Else, you can check in log file located at /mnt/user/appdata/CrashPlanPRO/log/service.log.0

I dont know why I didnt see history before....definitely the smoking gun.

 

1765053363_ScreenShot2020-08-12at11_16_28AM.thumb.png.6be3fe98758aa7f389d1350100f7032c.png

 

Looks like it pauses it to do a full filesystem scan at 3am every day, backs up some of the other files that changed, and then fails to upload the larger files for some reason, leaving the backup off until the next frequency check..... seems like something I should bring to code42 support. It has no problem starting when I tirgger it manually (I'm assuming the 4 files are my largest files which are large compressed files on my store)

 

Thanks for helping me figure out that it was crashplan and not unraid!

Link to comment

Apologies if this is covered, there seems to be no way to search in an individual thread.

 

My install has been working fine and I did a restore back in January, but it's now giving me problems. When I start the restore it gets stuck on "Preparing files..." in the GUI.

 

The service.log.0 gives a somewhat helpful error message about being unable to create a pipe

[08.17.20 14:21:41.294 WARN  background-0 e.restoretool.RestoreToolService] RESTORE TOOL:: Failed to create pipe for restore tool connection. userName=app, error=com.code42.jna.PlatformException: Problem in mkfifo() for path=/usr/local/crashplan/./restore-pipe-967861654629759799-request, mode=384, errno=13
[08.17.20 14:21:41.295 INFO  background-0 e.restoretool.RestoreToolService] RESTORE TOOL:: Not sending request; no pipe available
[08.17.20 14:24:09.070 INFO  DefaultGroup .code42.messaging.peer.PeerGroup] PG::DefaultGroup DONE Managing connected remote peers. numConnected=4, numFailedConnectedCheck=0, duration(ms)=1
[08.17.20 14:24:11.296 WARN  background-0 e.restoretool.RestoreToolService] RESTORE TOOL:: Failed to create pipe for restore tool connection. userName=app, error=com.code42.jna.PlatformException: Problem in mkfifo() for path=/usr/local/crashplan/./restore-pipe-967861906287999799-request, mode=384, errno=13
[08.17.20 14:24:11.297 INFO  background-0 e.restoretool.RestoreToolService] RESTORE TOOL:: Not sending request; no pipe available
[08.17.20 14:26:41.298 WARN  background-0 e.restoretool.RestoreToolService] RESTORE TOOL:: Failed to create pipe for restore tool connection. userName=app, error=com.code42.jna.PlatformException: Problem in mkfifo() for path=/usr/local/crashplan/./restore-pipe-967862157946239799-request, mode=384, errno=13
[08.17.20 14:26:41.298 INFO  background-0 e.restoretool.RestoreToolService] RESTORE TOOL:: Not sending request; no pipe available
[08.17.20 14:29:09.072 INFO  DefaultGroup .code42.messaging.peer.PeerGroup] PG::DefaultGroup DONE Managing connected remote peers. numConnected=4, numFailedConnectedCheck=0, duration(ms)=1
[08.17.20 14:29:11.300 WARN  background-0 e.restoretool.RestoreToolService] RESTORE TOOL:: Failed to create pipe for restore tool connection. userName=app, error=com.code42.jna.PlatformException: Problem in mkfifo() for path=/usr/local/crashplan/./restore-pipe-967862409621257015-request, mode=384, errno=13
[08.17.20 14:29:11.300 INFO  background-0 e.restoretool.RestoreToolService] RESTORE TOOL:: Not sending request; no pipe available
[08.17.20 14:31:41.301 WARN  background-0 e.restoretool.RestoreToolService] RESTORE TOOL:: Failed to create pipe for restore tool connection. userName=app, error=com.code42.jna.PlatformException: Problem in mkfifo() for path=/usr/local/crashplan/./restore-pipe-967862661279497015-request, mode=384, errno=13
[08.17.20 14:31:41.302 INFO  background-0 e.restoretool.RestoreToolService] RESTORE TOOL:: Not sending request; no pipe available

I did recently recreate my docker.img so set up the dockers all over (using the same application data folder) but think it may be more likely related to the 8.2.2 version?

 

Is it trying to create this pipe file in the docker image and that's the cause of the problem? I did find a reference to perhaps running the service as root but of course that has some security issues.

 

Is anyone else able to restore with the latest version just to rule that out?

 

I see /usr/local/crashplan in the docker is 755 permissions owned by root:root so can see a non root user won't be able to write. I did a quick chmod 777 on /usr/local/crashplan and sure enough the queued up restore which had been failing, then successfully went through.

 

So the question is, what is the correct way to fix this?

 

Thanks

 

Edited by Shonky
  • Like 1
Link to comment
On 8/20/2020 at 1:57 AM, bump909 said:

@Shonky I'm having the same issue.  Thank you for sharing your workaround!  I'll give that a shot.  I did do a little searching and did find this - https://wiki.archlinux.org/index.php/CrashPlan#Restore_stuck_preparing, but I'm not sure if it applies here.

Yeah I think I'd found that, but /tmp would have been fine. The log (and the workaround) shows that actually it's creating it in the wrong place. That would appear to be a Crashplan bug. It shouldn't be creating temporary files where its binaries etc are stored. That's precisely what /tmp is for.

 

Code42 probably won't care about a docker installation, but I would expect this to potentially cause problems in other systems too as unprivileged users may also not be able to write there. Perhaps there's an unset configuration or environment variable it looks for that's missing as a docker?

Link to comment

I've got a problem with restoring files and I've been advised by Code42 that I need to delete my cache. To do this, I need to stop the service first. Going into the command console (Control+Shift+C) and initiating the Shutdown, Stop or Exit commands does not stop the service in its entirety, but rather it restarts it. According to Code42 knowledge base, I can stop the service by going to /usr/local/crashplan/bin and running ./service.sh stop, but there is no such command available in that directory; those present are startCrashPlanEngine.sh, restartLinux.sh, startCrashPlanGUI.sh, Code42Service, restore-tool and vars.sh) and I'm a bit reluctant to run these in the event that I might break something.

Any suggestions?

Link to comment
  • 2 weeks later...
On 9/3/2020 at 6:17 PM, Trylo said:

There seems to be an issue with restoring files. I'm getting "Preparing files..." and it's been like this for over 24h.

I have installed CrashPlan on Windows and restored the files i needed this way, but that's just a workaround.

Well, that's really annoying!! Fortunately, I don't have a great urgency to restore the missing files, but I would like to fix this problem in case I do in the future.

 

I've been in touch via chat with Crashplan support and have not told them that I run this as a docker (they seem to think it's running on Ubuntu 20.04 server, so just let it slide). I've sent them my logs and I've had the following reply and am unsure if I can proceed further with them without letting on about the docker.

 

"Looking through the logs I'm seeing a consistent message that the restore I/O pipe is not able to get created. Typically this is indicative of a permissions issue of the Code42/CrashPlan app. There are a couple of more common reasons this may occur that I would like to have you check.

Please ensure that when you run the Code42/CrashPlan app you're not running it as an admin (sudo.) The app itself should be run from the user space.

Where are you restoring the files to? Have you attempted to restore the files to the Desktop directly?

When selecting the file permissions on the restore you will choose "current" instead of "original".

When selecting the files for restore be sure to allow the calculation to complete fully before starting the restore. If the calculation does not have time to fully complete then CrashPlan will report incorrect estimates for completion times.

Can you provide an example of the file you're looking to download? How large is the file?"

 

I'm not sure if the above info is helpful to the devs @Djoss?

FWIW, I get the "Preparing Files" sticking for a long time, whether I try to restore from the cloud or local hdd, whether it's current or original file permissions and it happens on the smallest of config files (600kb). All the while "Preparing Files" is showing, all backups stop.

 

 

Link to comment
On 8/25/2020 at 9:55 AM, Boyturtle said:

I've got a problem with restoring files and I've been advised by Code42 that I need to delete my cache. To do this, I need to stop the service first. Going into the command console (Control+Shift+C) and initiating the Shutdown, Stop or Exit commands does not stop the service in its entirety, but rather it restarts it. According to Code42 knowledge base, I can stop the service by going to /usr/local/crashplan/bin and running ./service.sh stop, but there is no such command available in that directory; those present are startCrashPlanEngine.sh, restartLinux.sh, startCrashPlanGUI.sh, Code42Service, restore-tool and vars.sh) and I'm a bit reluctant to run these in the event that I might break something.

Any suggestions?

You clan clear the cache with this method:

https://github.com/jlesage/docker-crashplan-pro#device-status-is-waiting-for-connection

Link to comment
  • 3 weeks later...

I've never used crash plan but I think I want to get it. Can you guys give me a little info.....does CrashPlan backup EVERYTHING where you could restore the entire server if needed.....dockers, plugins, vm's, all their settings, ect? Like a full image of the server you can just reinstall on new drives?  In addition can you just restore a single file if say a file was accidently deleted or something like that?

 

Thanks!

Link to comment
On 10/7/2020 at 9:11 PM, SPOautos said:

I've never used crash plan but I think I want to get it. Can you guys give me a little info.....does CrashPlan backup EVERYTHING where you could restore the entire server if needed.....dockers, plugins, vm's, all their settings, ect? Like a full image of the server you can just reinstall on new drives?  In addition can you just restore a single file if say a file was accidently deleted or something like that?

 

Thanks!

No, it doesn't backup everything.  See https://support.code42.com/CrashPlan/6/Troubleshooting/What_is_not_backing_up

So it's not like you will have a full image of the server.

 

However, yes you can restore a single file.

Link to comment
  • 3 weeks later...

Hey @Djoss - thank you for all your hard work on this image. I've been using it for years now without issue. :)

Today I'm having something a little worrisome happening over here with my setup.

 

One of my (2) drives is failing, and the plan is to swap in an identical replacement drive, then run a restore from CrashPlan. Here's my status on the client itself:

k2rjVsy.png


Ok, seems good... but then:

lN12g2O.png


qDq60Uc.png

 

And on the Code42 side, I woke up this morning and had an critical backup alert delivered to by inbox.

Here's what their web UI is looking like:

 

8rpnUT8.png

I've been willing to put up with CrashPlan's shitty interfaces up to this point, but now I don't have much faith.

Is there anything I can do to with CrashPlan or the container to be sure my files are backed up before I pull this drive?

Link to comment
33 minutes ago, Doug Estey said:

Hey @Djoss - thank you for all your hard work on this image. I've been using it for years now without issue. :)

Today I'm having something a little worrisome happening over here with my setup.

 

One of my (2) drives is failing, and the plan is to swap in an identical replacement drive, then run a restore from CrashPlan. Here's my status on the client itself:

k2rjVsy.png


Ok, seems good... but then:

lN12g2O.png


qDq60Uc.png

 

And on the Code42 side, I woke up this morning and had an critical backup alert delivered to by inbox.

Here's what their web UI is looking like:

 

8rpnUT8.png

I've been willing to put up with CrashPlan's shitty interfaces up to this point, but now I don't have much faith.

Is there anything I can do to with CrashPlan or the container to be sure my files are backed up before I pull this drive?

Is your Docker container image up-to-date ?

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.