Crashplan 4.2 drops support for OpenSolaris

L

LeftSide

Gawd
Joined
Nov 14, 2003
Messages
582
My open indiana box has been running for around 3 years now with no issues. I run crashplan on it and it has always been a great combo of ZFS and Crashplan for backups. 5 days ago May 19th it stopped communicating with windows boxes. I've done a packet capture and there is full communication between the devices, there are around a 100 packets sent before the FIN ACK is sent. I can also telnet from both devices to each other so it's not a connectivity issue.
I just looked at their website where they have posted that version 4.2 will not have Solaris support.
http://support.code42.com/Product_Lifecycle_Policy/Solaris_Platform_Retirement

I looked at the windows boxes and they have all upgraded to 4.2.0, while the solaris box is still at 3.7

So, crashplan support has dropped for my ZFS box. I figure I have a few options.
1) Run FreeBSD
2) Run a linux box and mount all the network shares so that crashplan will back them up
3) find another remote backup solution.
 
You could run a small Linux VM inside VirtualBox on OpenSolaris and then run the CrashPlan backup service from inside there.
 
Nooooooo!! One of the reasons I love CrashPlan is it runs right on my OpenIndiana box. It is currently backing up, so I wonder when it will kick in for me...
 
The only way crashplan works with network shares is if you mount the drive by batch script executed by system account under windows. That only way i know of it working
 
So, I've started the process of installing a linux VM where I'll mount network shares for Crashplan.
 
thedge said:
Nooooooo!! One of the reasons I love CrashPlan is it runs right on my OpenIndiana box. It is currently backing up, so I wonder when it will kick in for me...
Click to expand...

What version is the windows box running? You can double click the crashplan icon on the top right corner and type 'version' to find out.
 
Well, the backup started working again, so false alarm. Not sure why it stopped working for 5 days. I wonder when the windows code will stop communicating with the solaris code.
 
LeftSide said:
Well, the backup started working again, so false alarm. Not sure why it stopped working for 5 days. I wonder when the windows code will stop communicating with the solaris code.
Click to expand...

Well if you keep the Windows client on the same version it will always talk to it.

The question is when will the Solaris service stop talking to the CrashPlan cloud.

As defined by their software lifecycle policy major versions are supported for 6 months after a new major version. So CrashPlan 3 will stop being supported in 6 months.

Then who knows how long after that until they make some change that breaks CrashPlan 3 cloud connectivity.
 
Should be running BSD anyways to run ZFS shouldn't you since ZFS under linux is more of a hack job implementation of it no where as it was native to BSD...
 
LeftSide said:
What version is the windows box running? You can double click the crashplan icon on the top right corner and type 'version' to find out.
Click to expand...

Me personally (not the OP) I only have it on my OpenIndiana box, so no Windows clients involved currently.
 
MrGuvernment said:
Should be running BSD anyways to run ZFS shouldn't you since ZFS under linux is more of a hack job implementation of it no where as it was native to BSD...
Click to expand...

ZFS isn't native to BSD, it's native to Solaris and Illumos-based distros as they are the continuation of the OpenSolaris codebase.

ZFS is ported to BSD as it's also ported to Linux. Both ports use the same Illumos upstream to pull in the code changes from.

The main difference between BSD and Linux is that the BSD license allows ZFS to be shipped with the BSD kernel. With Linux ZFS has to be loaded as a Kernel Module, but that doesn't make it operate any less well.
 
Last edited:
I ran CP on OmniOS for a good while, but when the support ended for Solaris I set up another VM (ubuntu) just to run CP. I mount NFS shares from my OmniOS VM. Runs fine, and does not consume that much more resources.

My hope is that CP discontinued the support for Solaris because they are close to finalizing native clients for win, linux and os x –+and don't want to support too many operative systems. Java is a memory hog.
 
Java is not the reason CrashPlan uses so much memory though.

Java does not have to be a memory hog, it can be developed to use not much more memory than a C# or C++ app.
 
SirMaster said:
Java is not the reason CrashPlan uses so much memory though.

Java does not have to be a memory hog, it can be developed to use not much more memory than a C# or C++ app.
Click to expand...

java needs more memory due on it's machanism to run "program/code". Java is know as byte code not real binary code after compilation.

C/C++ take much less memory than Java.. since using real low level binary assembly directly. basically, you compile C/C++ to binary assembly language.

C# most likely follow java byte code rule.
 
cantalup said:
java needs more memory due on it's machanism to run "program/code". Java is know as byte code not real binary code after compilation.

C/C++ take much less memory than Java.. since using real low level binary assembly directly. basically, you compile C/C++ to binary assembly language.

C# most likely follow java byte code rule.
Click to expand...

I am a software engineer... You don't have to try to explain this. I written java code for years. The memory overhead in Java is tiny, like a few megabytes...

We are talking about CrashPlan using multiple GB of memory. This is because it keeps a working list of the hash of all the files which really adds up and would be the same size in any language.

Like I said, it's not Java that's the problem here.
 
SirMaster said:
I am a software engineer... You don't have to try to explain this. I written java code for years. The memory overhead in Java is tiny, like a few megabytes...

We are talking about CrashPlan using multiple GB of memory. This is because it keeps a working list of the hash of all the files which really adds up and would be the same size in any language.

Like I said, it's not Java that's the problem here.
Click to expand...

this :p
I am not asking your daiy job. and do not need to know :p

C/C++ is still the winner on small footprint memory.
"it can be developed to use not much more memory than... C++ app" <--- I commented on this part ..

in general, Java is not an issue due on current processor speed and memory size.

oops, not true , hashing on C/C++ versus java is different ..
not identical size, due C/C++ is very native when running.. overhead is minimal processing hashing.

btw I am on embedded world. memory and processor speed is the key. my job? is secret :p

do not believe me? run native program C/C++ and compare with Java program in the same machime. try to create big dummy hashing program with tracing,..

I believe CP want to streamline their support with only thier native application.
 
You must log in or register to reply here.
Back
Top