Jump to content
Djoss

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

947 posts in this topic Last Reply

Recommended Posts

On 8/11/2020 at 8:58 AM, ryancacophony said:

Per my last issue (Crashplan freezing), I think some combination of raising the default memory and updating the docker container fixed it (I'm also getting much better upload speed now, though still not maxing out my connection, but that's crashplan for ya)

 

I do have one issue that's consistently bothering me though. I'm not sure if its caused by crashplan or some setting on UNRAID - every day at 3am my crashplan backup stops, and I have to restart it when I get up in the morning. the only think I had scheduled then AFAIK is my SSD trim (which crashplpan is accessing my array not SSD, largely) and I set that to only once a week but it still happens every day. Any idea what might be causing it? is there a log I can check?

Do you have configured a backup schedule in CrashPlan ?

Share this post


Link to post
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)

Share this post


Link to post
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

Share this post


Link to post
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!

Share this post


Link to post

Well it looks like is time for me to DUMP Crashplan.  Duplicacy and Hetzner will do the job, 1TB / 6 days is not too bad.  My test is complete and I am switching over.  

BACKUP-HETZNER.png

Share this post


Link to post
Posted (edited)

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

Share this post


Link to post
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?

Share this post


Link to post
37 minutes ago, Shonky said:

Code42 probably won't care about a docker installation

It's worse than that, they actively discourage docker.

Share this post


Link to post

@Shonky, thanks for reporting the issue.  I will try to see what can be done to fix this.

Share this post


Link to post

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?

Share this post


Link to post

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.


Let me know if I can help fight this problem.

Share this post


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

 

 

Share this post


Link to post
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

Share this post


Link to post

@Trylo, @Boyturtle, I'm looking at solutions to this.  The cause of the issue is known: CrashPlan changed the location where pipes are created for restore operation.

As workaround, running CrashPlan as root (set the User ID and Group ID in container settings to 0) should work.

Share this post


Link to post
8 hours ago, Djoss said:

The latest Docker image fixes the issue.

Brilliant. Thanks for that, it works like a charm now 😀

Share this post


Link to post
4 hours ago, jbuszkie said:

Does anyone else see this issue?image.png.f35410b17c5f15addd57b24a5d0d35d8.png

Try to click the "Check for updates" button to fix this.

Share this post


Link to post

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!

Share this post


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

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.