So I am still not having success with updating to v4.2.0. I am not sure of all the other places to check but the series for crashplan, locale and java8 are all showing as running:
# ./service.sh status
crashplan is enabled and running
# ./service.sh status
locale is enabled and running
# ./service.sh status
java8 is enabled and running
One thing I do see in the Drobo Dashboard (and I am not sure if this is normal) is that locale and java8 show as “Status Unknown” in the Drobo Apps section. Would this have anything to do with crash plan not working? I’m kind of at wits end here. Whats the best way to remove/uninstall locale, java8 and crashplan and start over? I am thinking about just deleting everything and starting clean unless I hear of some other options.
My suggestion to you is to copy/move the “backupArchives” folder inside the crashplan folder somewhere else before you starting clean. That is the folder with all your backups. You can move it back into its place after the installation to restore all of your backup data.
Thanks. I wasn’t aware of that. A few other questions Ricardo:
[list=1]
[]Is it normal for the java8 and locale to show as “status unknown” from the Drobo Dashboard?
[]How do I properly uninstall crashplan, locale and java8? from the Drobo Dashboard? Just delete the folders while SSH’d in? Delete via Windows explorer/Mac finder?
[]Are their log files (if so where are they located) where I can verify things have (re)installed ok?
[]Is there any other ways to check to ensure all components are running as expected?
[/list]
Yes. Those are not regular apps in the sense that they can be started and/or stopped. They are just there, to be used by other apps.
All of those ways should work the same, as long as you make sure crashplan is stopped. Just to be extra safe you can reboot the Drobo after uninstalling them.
All the log files are located under /tmp/DroboApps/{appname}/. For example, crashplan’s log is located at /tmp/DroboApps/crashplan/log.txt. You can retrieve the files using SSH.
Like I said, locate and java8 are always “running” as expected, since they don’t really run at all. Crashplan will report its status to the Dashboard, so you should check that. You’ll have to connect to it eventually, so there is that as well.
OK Ricardo, I went through and:
[list=1]
[]Stopped crash plan from the drobo dashboard
[]Went to the DroboApps folder and deleted the crashplan, locale and java8 folders and restarted the Drobo via the Dashboard
[]Then went through and placed the latest versions of locale.tgz and java8.tgz in the DroboApps folder and restarted the Drobo again (thus installing the apps)
[]Next, I dropped the crashplan.tgz in the DroboApps folder and restarted the Drobo once last time.
[/list]
Drobo Dashboard shows the application running so I
[list=1]
[]Set the ui.properties file
[]Launch Terminal and SSH using the -L 4200:localhost:4243 setting
[]then launch CrasPlan from my laptop
[]I enter in my crashplan account info
[/list]
My Drobo 5N is at a “Waiting for backup” state and will not kick off no matter what I do. Another thing to note in I have some machine on my LAN that I have set to backup to the Drobo for crash plan backups and they show a “Destination unavailable - backup location not accessible” message.
[size=medium]Help! Not sure what else to do here! Please let me know what logs I can post, etc to help get this going.[/size]
setsidlocal /mnt/DroboFS/Shares/DroboApps/java8/bin/java pid=1512
-Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms20m+ -Xmx512m -Djava.net.preferIPv4Stack=trueech
-Dnetworkaddress.cache.ttl=300 -Dsun.net.inetaddr.negative.ttl=0+ -Dnetworkaddress.cache.negative.ttl=0 -Dc42.native.md5.
/mnt/DroboFS/Shares/DroboApps/crashplan/app/lib/com.backup42.desktop.jar:/mnt/DroboFS/Shares/DroboApps/crashplan/app/lang
[05.22.15 12:02:24.525 INFO main root ] Locale changed to English
[05.22.15 12:02:24.530 INFO main root ] *****************************
[05.22.15 12:02:24.531 INFO main root ] *****************************
[05.22.15 12:02:24.532 INFO main root ] STARTED CrashPlanService
[05.22.15 12:02:24.537 INFO main root ] CPVERSION = 4.2.0 - 142527600
[05.22.15 12:02:24.538 INFO main root ] LOCALE = English
[05.22.15 12:02:24.541 INFO main root ] ARGS = [ ]
[05.22.15 12:02:24.542 INFO main root ] *****************************
[05.22.15 12:02:24.903 INFO main root ] Adding shutdown hook.
[05.22.15 12:02:24.927 INFO main root ] BEGIN Loading Configuration
[05.22.15 12:02:24.964 WARN main com.code42.utils.UniqueId ] critical error converting IP
[05.22.15 12:02:25.108 INFO main root ] BEGIN Copy Custom
[05.22.15 12:02:25.109 INFO main root ] Directories: [.Custom, cust
[05.22.15 12:02:25.110 INFO main root ] NOT waiting for custom skin
[05.22.15 12:02:25.113 INFO main root ] NO customizations found.
[05.22.15 12:02:25.113 INFO main root ] END Copy Custom
[05.22.15 12:02:25.129 INFO main root ] Loading from default: /mnt/
[05.22.15 12:02:25.671 INFO main root ] Loading from my xml file=co
[05.22.15 12:02:25.867 INFO main root ] Loading ServiceConfig, newI
[05.22.15 12:02:25.899 INFO main root ] OS = Linux
[05.22.15 12:02:26.290 INFO main root ] AuthorityLocation@27276388[
[05.22.15 12:02:26.295 INFO main root ] Checking Java memory heap m
[05.22.15 12:02:26.303 INFO main root ] Previous Java memory max
[05.22.15 12:02:26.314 INFO main root ] END Loading Configuration
jtux Loaded.[/code]
Your latest 4.2.0 release resolves the issue. Thank you. The only thing that stinks is I have to re-backup all 1.5 TB of my files back to CrashPlan Central servers
hi its cool that the new version gets things going again, and while i dont have crashplan i was wondering this:
what is it that is causing the existing files to not be recognised by crashplan having them on their servers already?
eg even if crashplan updates their version, i would think that it would use some kind of similar hashing process that it is familar with, so that it doesnt tie up its servers backing up the same files?
maybe there is 1 existing file which is like a table of contents locally that is getting overwritten, that might save you from having to reupload?
This could have been my fault. I honestly don’t know 100% for sure. I thought I was being very careful not to delete my CrashPlan Central data for my Drobo, but it seems not to be the case. As of now, it looks like it is re-uploading everything. I hope to document the ‘correct’ way to update crashplan on the Drobo so this doesn’t happen to me again. It takes me a few months to backup my ~1.5 TB of data as I have it pretty much running over nighttime hours so it doesn’t interfere with my daytime traffic bandwidth.
oh thats fair enough - maybe it was or maybe it wasnt
either way its good that its backing up again for you, and it would be handy for you and all others if you find out that ideal method indeed.
btw maybe there is a way to limit the bandwidth that it uses during the day, so that you can run it all the time and reduce the amount of days it will take you catch up?
I do see there is a bandwidth throttle settings within the CrashPlan gui for the Drobo but I honestly don’t know how that really works seeing this is a headless ‘dumb’ device (“present” vs. “away”). I have it set to “None” for sending over the WAN which takes place over night hours, so that helps a little. I also kick the backup off over weekends where I’m not around so it gets more process during that time as well.
hmm am not sure, though maybe your crashplan main account (on crashplan itself) might have some settings to help control the speed of uploads from their side, which might help.
if not - then you might have to view less google vids during the day to do more backups (only joking)
I don’t see anything on the CrashPlan side of things that allow one to throttle back bandwidth just during off-business hours (either from the client or from their website/console). I’ve just been manually changing the throttling in the evening/on weekends… if I remember!
I work out of my home so having a backup running during the day (especially when its set to use a high bandwidth) affects when I use my VOIP softphone and just throughput trying to get day-to-day work done. I am sure I could pin this all down via my ASUS router by defining limits and QoS but thats too much of a headache for me and this situation
oh thats fair enough - if your router supports bandwidth management per ip address, there might be a way to simply slow down the drobos ip. (but it might take longer to setup and test than just letting the backups run)