[CONTAINER] CrashPlan & CrashPlan-Desktop


Recommended Posts

As mentioned my crash plan client is working again. However I notice backups stop midway with the message "waiting for connection". In settings it says it can't reach crashplan central.

 

However I know it's able to connect periodically since the outstanding backup payload is decrementing.

 

Any ideas why it can't get connection?

 

 

Sent from my iPhone using Tapatalk

Link to comment
  • 2 weeks later...

Edit:

I was able to fix this (for now at least).  I accessed the container filesystem, copied /usr/local/crashplan/cache to /config/cache, and restarted the container as suggested here.  Docker usage immediately dropped about 25%, and Crashplan did not have to re-synchronize anything.

 

Original Post:

I think my Crashplan is storing its cache within the docker file rather than in its appdata folder.  Following the suggestion here, I found several very big files relating to crashplan:

 

root@SF-unRAID:/# find /var/lib/docker/btrfs -type f -size +125000k -exec ls -lh {} \; | awk '{ print $9 ": " $5 }'
/var/lib/docker/btrfs/subvolumes/84cd5cba4749aeacfb6b5fae612de48bd840eff3036bc1cd3cbfce588c81cb96/usr/local/crashplan/cache/42/cpfmf: 538M
/var/lib/docker/btrfs/subvolumes/84cd5cba4749aeacfb6b5fae612de48bd840eff3036bc1cd3cbfce588c81cb96/usr/local/crashplan/cache/42/cphdf: 867M
/var/lib/docker/btrfs/subvolumes/84cd5cba4749aeacfb6b5fae612de48bd840eff3036bc1cd3cbfce588c81cb96/usr/local/crashplan/cache/42/cpfmfp: 199M
/var/lib/docker/btrfs/subvolumes/84cd5cba4749aeacfb6b5fae612de48bd840eff3036bc1cd3cbfce588c81cb96/usr/local/crashplan/cache/42/cpbf0000000000000000000/cpbmf: 2.4G

 

A listing of the crashplan folder shown above returns the following:

 

root@SF-unRAID:/var/lib/docker/btrfs/subvolumes/84cd5cba4749aeacfb6b5fae612de48bd840eff3036bc1cd3cbfce588c81cb96/usr/local/crashplan# ls -l
total 103740
-rw-rw-r-- 1 root   root   7641919 Aug 31 05:37 app.asar
lrwxrwxrwx 1 root   root        11 Aug 31 05:36 bin -> /config/bin
drwxrwxrwx 1 root   root      2486 Sep  1 05:18 cache/
lrwxrwxrwx 1 root   root        12 Aug 31 05:36 conf -> /config/conf
drwxrwxr-x 1 root   root        82 Aug 31 05:37 doc/
-rw-rw-rw- 1 nobody root       443 Aug 31 05:37 install.vars
drwxr-xr-x 1   2013 users      234 May 19  2015 jre/
-rw-rw-rw- 1 root   root  47099083 Jul 29  2015 jre-7-linux-x64.tgz
drwxrwxr-x 1 root   root       602 Aug 31 05:37 lang/
drwxrwxr-x 1 root   root      2914 Aug 31 05:37 lib/
-rw-rw-r-- 1 root   root     11854 Aug 31 05:37 libc42archive.so
-rw-rw-r-- 1 root   root     13060 Aug 31 05:37 libc42archive64.so
-rw-rw-r-- 1 root   root   2481278 Aug 31 05:37 libc42core.so
-rw-rw-r-- 1 root   root     24756 Aug 31 05:37 libjniwrap.so
-rw-rw-r-- 1 root   root     48344 Aug 31 05:37 libjniwrap64.so
-rw-rw-r-- 1 root   root    257693 Aug 31 05:37 libjtux.so
-rw-rw-r-- 1 root   root    287934 Aug 31 05:37 libjtux64.so
-rw-rw-r-- 1 root   root    403970 Aug 31 05:37 libleveldb.so
-rw-rw-r-- 1 root   root    427599 Aug 31 05:37 libleveldb64.so
-rw-rw-r-- 1 root   root      7346 Aug 31 05:37 libmd5.so
-rw-rw-r-- 1 root   root      8417 Aug 31 05:37 libmd564.so
lrwxrwxrwx 1 root   root        11 Aug 31 05:36 log -> /config/log
drwxrwxr-x 1 root   root       308 Aug 31 05:37 skin/
drwxrwxrwx 1 nobody root       322 Aug 31 05:37 upgrade/
-rw-rw-rw- 1 root   root  47474227 Aug 31 05:36 upgrade.cpi
-rw-rw-rw- 1 root   root         0 Aug 31 05:37 ~custom

 

Am I correct that cache/ should point to /config/cache?  If so, what would be the best way to fix this?  I'd prefer not to lose the cache information, as I believe Crashplan would then have to re-synchronize file information, which takes quite a while for me.

Link to comment

A listing of the crashplan folder shown above returns the following:

 

root@SF-unRAID:/var/lib/docker/btrfs/subvolumes/84cd5cba4749aeacfb6b5fae612de48bd840eff3036bc1cd3cbfce588c81cb96/usr/local/crashplan# ls -l
total 103740
-rw-rw-r-- 1 root   root   7641919 Aug 31 05:37 app.asar
lrwxrwxrwx 1 root   root        11 Aug 31 05:36 bin -> /config/bin
drwxrwxrwx 1 root   root      2486 Sep  1 05:18 cache/
lrwxrwxrwx 1 root   root        12 Aug 31 05:36 conf -> /config/conf
drwxrwxr-x 1 root   root        82 Aug 31 05:37 doc/
-rw-rw-rw- 1 nobody root       443 Aug 31 05:37 install.vars
drwxr-xr-x 1   2013 users      234 May 19  2015 jre/
-rw-rw-rw- 1 root   root  47099083 Jul 29  2015 jre-7-linux-x64.tgz
drwxrwxr-x 1 root   root       602 Aug 31 05:37 lang/
drwxrwxr-x 1 root   root      2914 Aug 31 05:37 lib/
-rw-rw-r-- 1 root   root     11854 Aug 31 05:37 libc42archive.so
-rw-rw-r-- 1 root   root     13060 Aug 31 05:37 libc42archive64.so
-rw-rw-r-- 1 root   root   2481278 Aug 31 05:37 libc42core.so
-rw-rw-r-- 1 root   root     24756 Aug 31 05:37 libjniwrap.so
-rw-rw-r-- 1 root   root     48344 Aug 31 05:37 libjniwrap64.so
-rw-rw-r-- 1 root   root    257693 Aug 31 05:37 libjtux.so
-rw-rw-r-- 1 root   root    287934 Aug 31 05:37 libjtux64.so
-rw-rw-r-- 1 root   root    403970 Aug 31 05:37 libleveldb.so
-rw-rw-r-- 1 root   root    427599 Aug 31 05:37 libleveldb64.so
-rw-rw-r-- 1 root   root      7346 Aug 31 05:37 libmd5.so
-rw-rw-r-- 1 root   root      8417 Aug 31 05:37 libmd564.so
lrwxrwxrwx 1 root   root        11 Aug 31 05:36 log -> /config/log
drwxrwxr-x 1 root   root       308 Aug 31 05:37 skin/
drwxrwxrwx 1 nobody root       322 Aug 31 05:37 upgrade/
-rw-rw-rw- 1 root   root  47474227 Aug 31 05:36 upgrade.cpi
-rw-rw-rw- 1 root   root         0 Aug 31 05:37 ~custom

 

Am I correct that cache/ should point to /config/cache?  If so, what would be the best way to fix this?  I'd prefer not to lose the cache information, as I believe Crashplan would then have to re-synchronize file information, which takes quite a while for me.

 

I have observed the same thing with my setup.

 

Below is what I have observed:

 

1. Just right after starting the CrashPlan docker, cache is still pointing to /config/cache

 

lrwxrwxrwx 1 root   root      11 Sep 10 09:08 bin -> /config/bin
lrwxrwxrwx 1 root   root      13 Sep 10 09:08 cache -> /config/cache
lrwxrwxrwx 1 root   root      12 Sep 10 09:08 conf -> /config/conf
drwxrwxrwx 1 nobody root      82 Apr 29 21:22 doc

 

2. After a few seconds, cache is not pointing to /config/cache anymore

 

lrwxrwxrwx 1 root   root        11 Sep 10 09:08 bin -> /config/bin
drwxrwxrwx 1 root   root       578 Sep 10 09:09 cache
lrwxrwxrwx 1 root   root        12 Sep 10 09:08 conf -> /config/conf
drwxrwxr-x 1 root   root        82 Sep 10 09:09 doc

 

Because of this, everytime I restart my CrashPlan docker, it would scan files and synchronise. Has anyone resolved this? Thanks

Link to comment

Did you try what I mentioned in my edit?

 

I was able to fix this (for now at least).  I accessed the container filesystem, copied /usr/local/crashplan/cache to /config/cache, and restarted the container as suggested here.  Docker usage immediately dropped about 25%, and Crashplan did not have to re-synchronize anything.

 

To be clear, this is what I meant by "accessed the container filesystem".  So far, the issue has not resurfaced.  I might have also done "New Permissions" on the cache drive at some point in the process.

 

If that had not worked for me, my next steps would have been to try this:

 

Disable docker

Delete docker.img

Delete /mnt/cache/appdata/Crashplan/cache/ if it exists*

Enable docker

Re-add docker containers using CA's previous apps

 

* Assuming /config is mapped to /mnt/cache/appdata/CrashPlan - adjust as necessary

Link to comment

Clearly, I've made a mistake, and I only seem to have made it worse by trying to fix it.

 

I installed the CP docker and everything worked great. I adopted my old backup (that was running on my Win machine for about 2 years) with about 1.4TB of data backed up to Code42's cloud. I followed their instructions to select my new locations and it was happily scanning along until I received 'Docker.img full' errors.

 

Re-reading the OP and looking at the details of my install, I realized I had installed /config <-> /mnt/user/appdata/CrashPlan instead of /mnt/cache/appdata/CrashPlan.

 

I stopped the docker, changed the mapping of /config and restarted the docker, confident that I had everything fixed. After a minute or two, I got a nice green pop-up telling me that my docker.img file use was back below 75% (it's at 30ish% right now). I'm on it, I've got this, no problem!

 

I returned to the CrashPlan tab in Firefox, hit F5, and nothing. The No VPN page came up, but it wouldn't connect.

 

I went to the docker tab in my unRAID management window, and I saw this:

w6oGEO6.png

 

Great. What have I broken... Wait, that makes sense, there's a docker image on /mnt/user/appdata, and nothing's pointed at it - how do I delete the sucker? I clicked the disk icon, and got the 'Remove' option and clicked that, hit 'Just do it'

hclCkVI.png

I got the confirmation message:

3MyqLDt.png

 

Fantastic, job done! I closed out the pop up, and there was that pesky orphaned image icon. OK, we'll go to the 'Dashboard' view, then back to 'Docker', and it'll be gone. Nope, no such luck. OK, maybe this will actually take a couple of minutes, let's go reinstall the docker in the mean time and everything will be great.

 

I wandered off to the Community Applications tab, selected the 'Backups' department, clicked on the CrashPlan icon again, made sure to specify /config <-> /mnt/cache/appdata/CrashPlan, and hit Done. It went through its install routine, I headed over to the 'Docker' tab, and... yup, the orphan image icon is still there and there's no sign of the CrashPlan docker to be found.

 

After several attempts to Remove the orphan, all with the same result, I attempted to install the docker to the original /config <-> /mnt/user/appdata/CrashPlan location in the hopes that unRAID would somehow reattach the docker to that orphan image so I could uninstall the docker correctly & get rid of it. That hasn't worked either.

 

TL;DR - how the heck do I remove this orphan image and get your lovely CrashPlan docker to reinstall itself?

 

I have the feeling I'll have to restart my backups, since it was at the very beginning of the process of reconciling things, but who knows, maybe CP will happily pick up where it left off. Either way, I don't care, I can wait a bit for all 1.4TB to push back to their servers, I just want to get this thing running again.

 

As a side note, it might be nice to change the docker install config to default to having /config <-> /mnt/cache/... instead of /mnt/user/... since /mnt/cache is the recommended location for docker installs, and goobers like me tend to make mistakes and assume things when they're playing on the server late at night...

 


A couple of additional points:

[*]I'm at 85% of the pre-read of pass 2 of 2 on a preclear of a new drive, so rebooting the server (if necessary) will be postponed for a couple of days

[*]As I was typing this up, unRAID 6.2 was released. See point 1.

[*]My 975 GB of family photos are being copied to my solitary 1TB external drive, just in case, so until that finishes, see point 1.

Link to comment

As a side note, it might be nice to change the docker install config to default to having /config <-> /mnt/cache/... instead of /mnt/user/... since /mnt/cache is the recommended location for docker installs, and goobers like me tend to make mistakes and assume things when they're playing on the server late at night...

You can do this on 6.2

 

What I suggest you do:

Update to 6.2 when you can

Then delete docker.img and recreate it. Then add all of your previous app via CA "previous apps" tab.

Link to comment

I've Googled for an answer, but can someone advise why an inbound backup is failing?

 

Config:

* New build with unRAID 6.2 Stable

* 2 drives installed -- 2x 8TB, 1 is parity. No cache drive. ~7TB free.

 

fails:

 

Yxsxg69.png

 

VwQDY5V.png

 

Thanks!

Yeah, read the q&a in the first post

 

Sent from my ONEPLUS A3000 using Tapatalk

 

 

Link to comment

As a side note, it might be nice to change the docker install config to default to having /config <-> /mnt/cache/... instead of /mnt/user/... since /mnt/cache is the recommended location for docker installs, and goobers like me tend to make mistakes and assume things when they're playing on the server late at night...

You can do this on 6.2

 

What I suggest you do:

Update to 6.2 when you can

Then delete docker.img and recreate it. Then add all of your previous app via CA "previous apps" tab.

 

OK, pre-clear finished, and 6.2 installed! So far, so good.

 

Do I uninstall the dockers first, or just blow away the docker.img file?

 

Also, I went with the default 10GB .img file, but it seems that 15-20GB is recommended. Can I create the new .img in a larger size & still get everything to install properly? It seems that I should be able to, but I just want to double check.

 

Also - just noticed that there's an update to CA (9/17/2016) should I update that before reinstalling, or leave it on the current version (9/15/2016) for the fix, then update it?

 

Then delete docker.img and recreate it

Does this mean that I should delete "docker.img" from disk, or does it mean I should go into Settings | Docker, disable docker, save it, then reenable it?

Link to comment

I did read that.  Is it trying to backup to the Docker img?

 

Perhaps your next reply can be even less helpful.

 

That does seem to be your issue, as it was mine. Learn from my mistake - uninstall the docker & reinstall it, don't try to change the cache mapping while it's running. Doesn't seem to work all that well.

Link to comment

As a side note, it might be nice to change the docker install config to default to having /config <-> /mnt/cache/... instead of /mnt/user/... since /mnt/cache is the recommended location for docker installs, and goobers like me tend to make mistakes and assume things when they're playing on the server late at night...

You can do this on 6.2

 

What I suggest you do:

Update to 6.2 when you can

Then delete docker.img and recreate it. Then add all of your previous app via CA "previous apps" tab.

 

OK, pre-clear finished, and 6.2 installed! So far, so good.

 

Do I uninstall the dockers first, or just blow away the docker.img file?

 

Also, I went with the default 10GB .img file, but it seems that 15-20GB is recommended. Can I create the new .img in a larger size & still get everything to install properly? It seems that I should be able to, but I just want to double check.

 

Also - just noticed that there's an update to CA (9/17/2016) should I update that before reinstalling, or leave it on the current version (9/15/2016) for the fix, then update it?

 

Then delete docker.img and recreate it

Does this mean that I should delete "docker.img" from disk, or does it mean I should go into Settings | Docker, disable docker, save it, then reenable it?

http://lime-technology.com/forum/index.php?topic=42148.msg498419.msg#498419

 

 

Just make your docker image 15-20GB

Link to comment

And... that didn't seem to have helped. I'm obviously setting something up incorrectly, but for the life of me, I'm not seeing the issue. I reinstalled CP, got it started and it filled up my docker.img file within minutes.

 

Here is a screen shot of how I've got the drives mapped.

 

xoVJxVb.png

 

where have I gone wrong?

Link to comment

I reinstalled CP, got it started and it filled up my docker.img file within minutes.

 

What kind of backup are you doing, unraid to the cloud, or another computer to unraid?

 

If it is another computer to unraid, have you had a chance to read the first post?  You need to configure CrashPlan to store the backups on the array and not in your docker.img.  Setting the drive mapping is only part of it, you have to actually load the CrashPlan interface and tell it where to store the backup.

Link to comment

hmmm... I'm backing up my unRAID to CP's cloud, but I do have other backups incoming to my machine. I hadn't checked on the destination for those, I was focused on the more important "get my server backed up" issue.

 

I did read the OP, but that part didn't register as far as location for incoming backups. Thanks for pointing that out. However, I did have /backup <-> /mnt/user/Backup which is NOT in my docker.img file. I just changed that to /mnt/user/Backups, which is where I actually had the previous backups. When I saved the mapping change I got this:

 

QfpvOrx.png

 

Hopefully "Error: Error Code" means more to you than me.  ;)

 

Should I just uninstall and reinstall the container?

Link to comment

hmmm... I'm backing up my unRAID to CP's cloud, but I do have other backups incoming to my machine. I hadn't checked on the destination for those, I was focused on the more important "get my server backed up" issue.

 

I did read the OP, but that part didn't register as far as location for incoming backups. Thanks for pointing that out. However, I did have /backup <-> /mnt/user/Backup which is NOT in my docker.img file. I just changed that to /mnt/user/Backups, which is where I actually had the previous backups. When I saved the mapping change I got this:

 

QfpvOrx.png

 

Hopefully "Error: Error Code" means more to you than me.  ;)

 

Should I just uninstall and reinstall the container?

 

I'm not sure what that error code means :) but once your docker.img has filled up, nothing works right.  I'd delete your CP docker at a minimum, and consider deleting/recreating the docker.img again.

 

I don't know of any reason why backing up unraid to the cloud would fill up your docker.img, but incoming backups definitely will if CP hasn't been configured.

 

It sounds like the incoming backups are starting automatically?  In that case you should go to those other computers and shut them off or disable backups until you can get CP on unraid configured.

 

For me, it is easier when I can reference /mnt/user/[whatever] inside the container, the same as I would outside the container, so I would map /mnt/user/Backup to /mnt/user/Backup (doesn't matter whether you use capital or lowercase 'b', with or without the 's', as long as you are consistent).

 

Once you're happy with the mapping and the container starts again, and you are sure there are no incoming backups :) try backing up unraid to the cloud.  You should see various files added to /mnt/cache/appdata/CrashPlan.  Keep an eye on your docker.img and be sure it doesn't fill up.

 

Then look for the "Default backup archive location" in the CP settings and set it to /mnt/user/Backup (or whatever directory you mapped) as described in the first post.  Also set the default location for each friend as described in the first post.  At this point it should be safe to turn on the other computers and have them start backing up.  Confirm that files are going to /mnt/user/Backup and your docker.img is not filling up.

Link to comment
  • 2 weeks later...

FYI, might be good for people to keep an eye on the CrashPlan Docker container if this update affects you as well.

 

My CrashPlan Docker container did auto update itself today to version 4.8.0

My Custom key did not “survive” the update so I needed to re-enter it to get it running again.

Link to comment

I'm having issues getting the desktop application on my PC and the Docker to connect to each other. I go to start a backup from my PC and the two have green lights beside them but once they begin to connect the lights turn grey.

 

I have no idea what I am doing wrong. I just installed this and am very much a novice. I feel like I might have messed up my paths or ports.

 

I definitely messed up my paths as I just went into my shares and now I have "Backup" and "CrashPlan" in there. I want my backups to go into /user/media/Crashplan

 

Also, how can I get rid of those two shares that I accidentally created? I can't do it via windows. Edit: I remembered how to delete the shares since they were empty

 

 

 

Crashplan_Docker.PNG.53d3af14cc339c9b976027edaee8abf5.PNG

appdata_share.PNG.bbd0037dd74d06e303d20a286d58d7e1.PNG

Media_Share.PNG.0423373c232e66aeda0a707c4b48a8a0.PNG

Shares.PNG.83af2c17e779f153d72bb1011f043e66.PNG

Link to comment

Anyone else having an issue signing into Crashplan docker for the initial startup??

 

I am trying to set up this on my machine and when I try and login with an existing account i recieve the error:  "Unable to connect.  Check your network"

 

I had this docker working earlier, but deleted it and started fresh to see if it would pull the new 4.8 client...

 

Any help would be appreciated...

 

Thanks!

 

 

Edit...

 

After a few hours I was finally able to log on...

 

Maybe something was down on their end for a while.

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.