Was starting to review steps needed to migrate to PRO and was so happy to see this thread here. A few questions, though:

 

1. I'm backing up 11TB and Code42 has already indicated it can't migrate anything over 5TB and will need to perform a full backup from scratch. I assume there is no need for me to migrate any data then? Or do I still need to do copy "/mnt/user/appdata/CrashPlan" to CrashPlanPRO?

 

2. Long ago I had to modify the code/config to avoid deduplication by CP as it bogged down multi-terabyte backups. Will I need to make that modification again with PRO? I need to find in my notes how I did this long ago. With dedupe turned on my backup never would not have finished as it was too aggressive.

Edited September 14, 20178 yr by snowboardjoe

On 8/25/2017 at 0:56 PM, JustinAiken said:

Okay, was successfully able to migrate from the other container without adoption!

 

cd /mnt/cache/appdata
cp -r CrashPlan/ crashplan-pro
chown -R nobody:users /mnt/user/appdata/crashplan-pro/
cd crashplan-pro/
mv id/ var/
rm -r cache
rm -r bin
rm -r log

All docker template values are default, except for:

- config -> /mnt/user/appdata/crashplan-pro
- data -> /mnt/user (To match old container)

 

 

So far, so good. I followed these steps, CPP came right up and it's currently synchronizing block information. It says all my destination points are missing, though, but I'll wait for the sync to finish and see what it says then.

 

The worrying part was dealing with the code-42 website. I entered all the info, clicked the button and basically nothing... it went back to the start of the enrollment screen, and now the Admin panel has a scary red warning that my subscription is about to expire and I need to re-enroll now!!! It says the subscription is good through March 2018, though, although with my extra 60 days it should be beyond that.

 

If things don't clear up by tomorrow evening, I'll jump on chat with them & get it straightened out.

 

Thanks to @Djoss for getting this container working so quickly and to @JustinAiken for the simple directions!

 

UPDATE: For those who have large backups, don't forget to allocate more memory to CrashPlan. Double click on the little business building icon in the top right corner then type

 

java mx xxx, restart

 

Where xxx is the amount of memory you want to assign in MB. Their instructions are listed here. They recommend 1 GB of memory for every TB of backup or million files.

Edited September 14, 20178 yr by FreeMan

1 hour ago, snowboardjoe said:

1. I'm backing up 11TB and Code42 has already indicated it can't migrate anything over 5TB and will need to perform a full backup from scratch. I assume there is no need for me to migrate any data then? Or do I still need to do copy "/mnt/user/appdata/CrashPlan" to CrashPlanPRO?

You can effectively start with an empty appdata.  No need to keep your previous config.

 

1 hour ago, snowboardjoe said:

2. Long ago I had to modify the code/config to avoid deduplication by CP as it bogged down multi-terabyte backups. Will I need to make that modification again with PRO? I need to find in my notes how I did this long ago. With dedupe turned on my backup never would not have finished as it was too aggressive.

Yes you need to redo it.  Make sure to read the article from Code42 about his (unsupported) change:

https://support.code42.com/CrashPlan/4/Configuring/Unsupported_changes_to_CrashPlan_de-duplication_settings

1 hour ago, FreeMan said:

UPDATE: For those who have large backups, don't forget to allocate more memory to CrashPlan. Double click on the little business building icon in the top right corner then type

 

java mx xxx, restart

 

Where xxx is the amount of memory you want to assign in MB. Their instructions are listed here. They recommend 1 GB of memory for every TB of backup or million files.

Much more easier to set the memory amount using the dedicated container's setting!

2 minutes ago, Djoss said:

Much more easier to set the memory amount using the dedicated container's setting!

True!

 

I saw that but it didn't even register... Thanks, I've made the change there, since it probably would have been overwritten next time the container was updated.

11 minutes ago, FreeMan said:

Thanks, I've made the change there, since it probably would have been overwritten next time the container was updated.

 

And... now I've unset the change there. It wouldn't start properly with it set in both places.

You mean when set in container's setting the container is not starting?

Can you provide the content of /mnt/user/appdata/CrashPlanPRO/bin/run.conf?

I initially set it (to 2560) by using the "click on the app" method I described and it was fine.

Then, you mentioned the setting in the container settings, so I edited the settings and set it there to "2.5G". When I restarted the container, I couldn't get the WebGUI to come up. I cleared the field in the container settings and restarted again, and it came up.

 

Contents of run.conf:

SRV_JAVA_OPTS="-Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms20m -Xmx2560m -Dsun.net.inetaddr.ttl=300 -Dnetworkaddress.cache.ttl=300 -Dsun.net.inetaddr.negative.ttl=0 -Dnetworkaddress.cache.negative.ttl=0 -Dc42.native.md5.enabled=false"
GUI_JAVA_OPTS="-Dfile.encoding=UTF-8 -Dapp=CrashPlanDesktop -DappBaseName=CrashPlan -Xms20m -Xmx512m -Dsun.net.inetaddr.ttl=300 -Dnetworkaddress.cache.ttl=300 -Dsun.net.inetaddr.negative.ttl=0 -Dnetworkaddress.cache.negative.ttl=0 -Dc42.native.md5.enabled=false"

After restarting, it will come up, but it cannot connect to the server, and I see this in the settings:

 

I'll stop fiddling with it until I get some advice. (Which has been quite good so far, if only I'd slow down some!)

My guess is that the value you set failed to be replaced in run.conf.  If you look at the container's logs, you will probably see an error that prevent the container to start.

 

One thing you can try is to stop the container and remove run.conf.  The set the memory amount in the container settings and start the container.

I looked at run.conf and it had "-Xmx1024m", so I deleted run.conf, set memory to "2.5G" and restarted. Again I couldn't bring up the UI.

 

Stopped the container, cleared the memory setting from the WebGUI settings. It didn't start the container, so I edited the run.conf to read "-Xmx2560m" and started the container. The UI will come up now, but it's still not starting the backup, and the internal address is still showing 0.0.0.0:4242.

 

I could uninstall/reinstall the whole container if you think that would be a good next step.

I think the issue is with the "2.5G" value.  Not sure CP supports fraction.  Try to set "2560m" instead.

 

The backup issue is a separate thing.  I think Code42 is doing some maintenance. It's also not working on my side.

9 hours ago, snowboardjoe said:

Was starting to review steps needed to migrate to PRO and was so happy to see this thread here. A few questions, though:

 

1. I'm backing up 11TB and Code42 has already indicated it can't migrate anything over 5TB and will need to perform a full backup from scratch. I assume there is no need for me to migrate any data then? Or do I still need to do copy "/mnt/user/appdata/CrashPlan" to CrashPlanPRO?

 

2. Long ago I had to modify the code/config to avoid deduplication by CP as it bogged down multi-terabyte backups. Will I need to make that modification again with PRO? I need to find in my notes how I did this long ago. With dedupe turned on my backup never would not have finished as it was too aggressive.

 

I switched over and my full 17TB migrated without having to re-upload anything, I'm not alone in this either.

 

SR

I'm still trying to see if I can takeover my existing 11TB of data. CPPro still shows the data is there after the migration and I've been struggling to get my new client to attach to it to keep from spending days/week backing it up all over again. I went through the takeover steps, but it still wants to start over from scratch. When I first got it initialized it shows all my shares were missing and guessing this was due to the path changes (using shares instead of storage and using flash instead of boot). The instruction say to just reselect the shares (not remove the old ones), but it still insists on backing up everything all over again.

 

Is there any way around this? Is there something I should be mapping differently to make it all work? I thought the client would have figured out that data had moved and would not back it up again.

Yeah, well, after a flawless conversion from gfjardim's docker to this one, there was one minor issue... I screwed up my setting for the backup path so the backups didn't start. Then I started messing around trying to figure out why everything was listed as missing and started a prune. When that finishes, I think I'll end up with an empty backup set at code42 and get to start over.

 

Totally my fault, but be sure to learn from my mistake!

Can someone help me.

 

Since i reboot my unraid pc the crashplan engine wont start.

 

I got the crashplan pro etc.

 

 

 

Do you have the container’s log?

1 minute ago, Djoss said:

Do you have the container’s log?

I just reinstalled the app and its working.

 

But if i restart it it is not working 

 

 

 

06.pdf

Nothing special in container's log.

 

Under the container's appdata (/mnt/user/appdata/CrashPlanPRO/log/), you can look at these log files:

• service.log.0
• engine_error.log
• engine_output.log

 

4 minutes ago, Djoss said:

Nothing special in container's log.

 

Under the container's appdata (/mnt/user/appdata/CrashPlanPRO/log/), you can look at these log files:

• service.log.0
• engine_error.log
• engine_output.log

 

 

service.log.0

engine_error.log

engine_output.log

It seems to be the problem:

java.io.IOException: IO error: /usr/local/crashplan/conf/adb/000005.ldb: No such device

Is your appdata correctly seen from the container?  Can you run these commands on the server:

 

docker exec CrashPlanPRO ls -l /config/
docker exec CrashPlanPRO ls -l /config/conf

 

4 minutes ago, Djoss said:

It seems to be the problem:

java.io.IOException: IO error: /usr/local/crashplan/conf/adb/000005.ldb: No such device

Is your appdata correctly seen from the container?  Can you run these commands on the server:

 

docker exec CrashPlanPRO ls -l /config/
docker exec CrashPlanPRO ls -l /config/conf

 

 

If you stop and then start the container (without reboot), do you have the issue?

If you manually stop the container before rebooting, do you have the issue?

no I have to delete everthing and reinstalled the app.

 

 

thx

Just wanted to ask about restoring a file. I wanted to test out a restore via the docker. I was pointing a file to restore it to a share and it said it didn't have write access.

 

I tested a various amount of shares inc a public share. Even back to the original location. Write permission error.

 

Can anyone else replicate this? I am using default mappings. My backups are working fine. Its more of a restore withing the docker issue I am having.

 

Cheers,

By default, /storage is read-only.  This is to make sure that data to backup is not touched/modified.

 

If you want to restore, you can create another mapping (add a "Path" in container's setttings) with read/write permissions and restore to this location.

You can also change the permissions of /storage if you prefer.