Helmonder

I'll also vouch for the supermicro ones... I have 4 in use in my primary server.. For my backup server I also want to use them but am still trying to find the correct case.. Unfortunately cases with a lot of 5 1/4"drives on the outside are VERY rare..

You've already said that so you're one of the lucky ones. Can we get the developer to chime in here or do we need to reach out on GitHub? Sent from my iPad using Tapatalk I wanted to be sure.. I might have thought it worked when it didn't... If it the docker itself that does not start then support should be in here.. If it is crashplan itself that is nog starting to backup, then it might be crashplan and/or github...

Is there a plugin ?

Just tested.. auto-starts fine...

Ok I'll keep waiting. Been two days at least, so wasn't sure if it was automatic or not. Then it probably already updated.

So, I have no idea how to get this update? I was waiting for an over-the-air update, but it never came. And I can't find an 'update' button within the app. I'm still on 2.3.1, which was installed via the Play Store. How do I get this update? Thanks. It updates on its own.. No need to do anything..

My appologies.. I think I misunderstood "autostart".. I thought you meant that the crahsplan docker did not auto-start.. In retrospect I see this is some kind of other package that I have no idea of what it is..

autostart works fine here..

I do not, so that's not it. In a few weeks when I upgrade my network capacity I will, if anything comes up I'll report back. As for now, still not sure what caused it, it's been running fine even after reboots ever since it connected properly. Same here...If you do not touch it in the end it will start to function again on its own also..

Do you use network bonding in unraid ? Maybe its ties into that somehow.. Verzonden vanaf mijn iPhone met Tapatalk

Doublecheck in settings - network if you have the correct interfaces selected.. You can just select them all.. If all else fails repeatedly press "retry" to connect... It does this with me sometimes.. In the end it always connects btw.. always..

Check for a sticky bit? A bit stuck at 0 would pass the current preclear, but fail a write / verify 1's pass. If you really want to get thorough, you could do a 1's pass, Hex AA pass, Hex 55 pass, then finish with a 0's pass. That would force any marginal sectors to definitely either pass or puke. Plus, it would almost satisfy DOD erasure standards. Would that not give the effect of three passes of preclear in one go ? That would actually be nice.. Kind of the effect of three passes in one..

MC works fine, even with my mouse.. But it all depends on the terminal emulation program you use.. On Windows most use putty which is great.. But actually, krusader wil give you more then that.. So just do that. MC will not bring anything to play that you cannot use with KRusader and that will always work..

That is not correct..

If all the hardware is melted there is nothing to restore.. Your data is what you should backup If you area allready doing that then just install the Community Applications plugin and backup your dockers and VM's from there..

Personally, I would get rid of the redirect to /boot/logs/scrub_cache.log. That way user scripts can display the logs. But, the output is not persistent and will be lost over reboots. I allready took ik out on my side for the same reason.. :-)

The following will do a btrfs scrub and report back the results through the notification interface, I have scheduled this monthly: /usr/local/emhttp/plugins/dynamix/scripts/notify -e "start_scrub_cache" -s "Scrub cache drive" -d "Scrub of cache drive started" -i "normal" -m "Scrubbing message" btrfs scrub start -rdB /mnt/cache > /boot/logs/scrub_cache.log if [ $? -eq 0 ] then /usr/local/emhttp/plugins/dynamix/scripts/notify -e "start_scrub_cache" -s "Scrub cache drive" -d "Scrub of cache drive finished" -i "normal" -m /boot/logs/scrub_cache.log else /usr/local/emhttp/plugins/dynamix/scripts/notify -e "start_scrub_cache" -s "Scrub cache drive" -d "Error in scrub of cache drive !" -i "alert" -m /boot/logs/scrub_cache.log fi The following does an hourly check on Out of Memory errors in the syslog, I scheduled this hourly: if grep -q "Out of memory" /var/log/syslog; then /usr/local/emhttp/plugins/dynamix/scripts/notify -e "OOM Checker" -s "Checked for OOM in syslog" -d "OOM error found in syslog" -i "alert" fi

The parity drive needs to be at least as large as your largest data drive. Your data drives are 3TB so your parity should be at least 3 TB. Know that when you add a new drive in the future you cannot use a drive larger then your parity drive. So lets say you want to expand your array in the future and you want to add a 6TB data drive, then you would need to add 2 6TB drives, one for parity and one for data. Your current parity drive you can then reuse as a data drive. As far as 1 or 2 parity drives is concerned, that is up to you. With one parity drive one disk can fail and you loose nothing. With two parity drives you can loose two.

It would be nice if there were a plugin of some sort that would give an insight in storage growth. It could take a sample on a daily basis of: - Used storage per disk - Used storage per share - Used storage in total This could then be reported in a graph and preferably extrapolated based on the trend seen, therefor telling us when a system needs expansion..

For the benefit of the rest: 1) log into your unraid server 2) log into the crashplan docker: docker exec -it CrashPlan bash 3) go to /etc/my_init.d 4) vi 01_config.sh ${TCP_PORT_4242} on line 46 needs to be replaced with ${SERVICE_PORT} ${TCP_PORT_4243} on line 47 needs to be replaced with ${BACKUP_PORT} And indeed, then it works ! Just restart the docker

On the unraid server that its crashplan is now reporting a 0.0.0.0 address as local address (see above) I also have a win10 vm running with crashplan installed, it also shows a 0.0.0.0 address for the local IP... This crashplan version is ofcourse not a docker version but a windows version.. I therefor think that it is -not- the docker itself causing the issue.. That would mean it is either crashplan itself (but we should expect a lot to be google-able on that if crashplan itself would be borked, so i do not think that is it). Or there is some relation with the docker engine running on unraid. I have been having backup troubles for approx. 2 days which is about the same time unraid 6.2.1 is out..

I also notice that one of my two crashplans reports no internal ip address.. Weird thing is that they are both running the same unraid and same crashplan version.. Ofcourse both unraid webgui's are perfectly reachable on their respective internal addresses.. Hope this gets fixed soon.. I am missing my backups..

this is working fine for me..

do you not get in a fight with apple over this ?

Its also not working for me anymore... crashplan clients cannot connect anymore.. not only windows.. my main crashplan server can also not connect to the backupserver.. both running crashplan, on 6.2, same docker version..