ryancacophony Posted August 12, 2020 Share Posted August 12, 2020 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) Quote Link to comment
Djoss Posted August 12, 2020 Author Share Posted August 12, 2020 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 Quote Link to comment
ryancacophony Posted August 12, 2020 Share Posted August 12, 2020 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. 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! Quote Link to comment
DivideBy0 Posted August 13, 2020 Share Posted August 13, 2020 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. Quote Link to comment
Shonky Posted August 17, 2020 Share Posted August 17, 2020 (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 August 17, 2020 by Shonky 1 Quote Link to comment
bump909 Posted August 19, 2020 Share Posted August 19, 2020 (edited) @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. Edited August 19, 2020 by bump909 Quote Link to comment
Shonky Posted August 22, 2020 Share Posted August 22, 2020 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? Quote Link to comment
JonathanM Posted August 22, 2020 Share Posted August 22, 2020 37 minutes ago, Shonky said: Code42 probably won't care about a docker installation It's worse than that, they actively discourage docker. Quote Link to comment
Djoss Posted August 25, 2020 Author Share Posted August 25, 2020 @Shonky, thanks for reporting the issue. I will try to see what can be done to fix this. Quote Link to comment
Boyturtle Posted August 25, 2020 Share Posted August 25, 2020 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? Quote Link to comment
Trylo Posted September 3, 2020 Share Posted September 3, 2020 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. Quote Link to comment
Boyturtle Posted September 10, 2020 Share Posted September 10, 2020 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. Quote Link to comment
Djoss Posted September 10, 2020 Author Share Posted September 10, 2020 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 Quote Link to comment
Djoss Posted September 10, 2020 Author Share Posted September 10, 2020 @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. Quote Link to comment
Djoss Posted September 11, 2020 Author Share Posted September 11, 2020 The latest Docker image fixes the issue. Quote Link to comment
Boyturtle Posted September 11, 2020 Share Posted September 11, 2020 8 hours ago, Djoss said: The latest Docker image fixes the issue. Brilliant. Thanks for that, it works like a charm now 😀 Quote Link to comment
jbuszkie Posted October 1, 2020 Share Posted October 1, 2020 Does anyone else see this issue? Quote Link to comment
Djoss Posted October 2, 2020 Author Share Posted October 2, 2020 4 hours ago, jbuszkie said: Does anyone else see this issue? Try to click the "Check for updates" button to fix this. Quote Link to comment
jbuszkie Posted October 2, 2020 Share Posted October 2, 2020 Ok.. That fixed that one... But now I have this! LOL... Quote Link to comment
SPOautos Posted October 8, 2020 Share Posted October 8, 2020 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! Quote Link to comment
Djoss Posted October 14, 2020 Author Share Posted October 14, 2020 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. Quote Link to comment
Doug Estey Posted November 3, 2020 Share Posted November 3, 2020 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: Ok, seems good... but then: 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: 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? Quote Link to comment
trurl Posted November 3, 2020 Share Posted November 3, 2020 9 minutes ago, Doug Estey said: One of my (2) drives is failing, and the plan is to swap in an identical replacement drive, then run a restore from CrashPlan Assuming you have parity you are going to rebuild the replacement so no need to restore. Quote Link to comment
Doug Estey Posted November 3, 2020 Share Posted November 3, 2020 (edited) 10 minutes ago, trurl said: Assuming you have parity you are going to rebuild the replacement so no need to restore. CrashPlan "is" my parity drive 😅 Edited November 3, 2020 by Doug Estey Quote Link to comment
Djoss Posted November 3, 2020 Author Share Posted November 3, 2020 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: Ok, seems good... but then: 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: 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 ? Quote Link to comment
Recommended Posts
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.