R1Soft not supporting CentOS 5.7

Portal Home > Knowledgebase > Articles Database > R1Soft not supporting CentOS 5.7

Posted by pmabraham, 09-16-2011, 05:14 PM
Good day: The kernels for CentOS 5.7 came out on Wednesday, September 14, 2011. These kernels include a number of security fixes. R1Soft developers were completely unprepared for this upgrade. Unless you are on CDP 3 (which has a large number of bugs, performance issues, the mysql add on increases backup time tremendously, etc.), your CentOS 5.7 machines cannot be backed up. The R1Soft developers are so out of touch with reality that after asking for an ETA on when their now broken agents will work with CentOS 5.7, they don't know. Their support department is not responsive taking hours to respond to questions; and maybe I should not blame them. Would you want to try to explain to paying customers why your development team cannot even tell you when your agents will work again? Thank you.
Posted by techjr, 09-16-2011, 07:30 PM
I have lost my trust in R1Soft to be honest. The new mysql backup system just seems silly to even talk about implementing never mind actually using it. CDP2 has issues at times and if you aren't monitoring it backups are going to fail. I have been looking for a cloud provider where you can have multiple images of the server and download it as either an iso or other formats as so far, no other complete backup systems that I have found are capable of worry free backups.
Posted by Scott.Mc, 09-17-2011, 10:06 PM
Specifically what about the mySQL addon bothers you in v3?
Posted by Steven, 09-18-2011, 07:11 PM
My only gripe with the mysql addon in v3 is the amount of time it takes to backup mysql.
Posted by TonyB, 09-18-2011, 07:54 PM
The amount of time it takes for it to be performed. It's not great even with low latency situation but when latency is over 1ms it's really bad. Two identical machines where one is 1ms away from the CDP server and the other 30ms your 30ms system will be around 30 times slower. It takes us about 4 hours to do the discovery task on a server with 700 databases that is 30ms away. From the query logs I checked it looks like the CDP server connects and performs every query by query. So here's the basic logic: The CDPv2 version I believe had the agent perform the queries they were running. It did grab less information but even if this system only had the same features it's be significantly slower. We're pretty annoyed we have a CDPv3 server where only our local machines can use the MySQL feature. They get by because we're talking about .2ms latency between them. Anything not local to the CDP server this feature is not possible without it taking hours.
Posted by techjr, 09-18-2011, 09:09 PM
Exactly my issue. Try backing up to another datacenter and have no onsite backup servers. It took longer being in another facility but when you're backing up a server from Chicago to a server in Atlanta it's bad. I'm thinking about talking to the techs I work with and see if we can't implement a heavily modified open source solution.
Posted by net, 09-18-2011, 09:20 PM
I am still not happy with version3. This is why we are still stuck with version 2 and it is still stable when it comes to restoration of files or databases.
Posted by RaidLogic, 09-18-2011, 10:27 PM
We been testing version 3 since last friday, we are in no hurry to go live with v3 yet
Posted by techjr, 09-18-2011, 11:46 PM
Did they not fully test the mysql addon when they released it? You would think testing offsite backups would be one of the first things to try.
Posted by Scott.Mc, 09-19-2011, 11:02 AM
How many tables are you backing up?
Posted by Steven, 09-19-2011, 01:08 PM
If you use it on a say a shared webhosting server, it can take 10 hours to backup mysql whereas cdp2 on the same server takes a hour or two to do the complete process.
Posted by Scott.Mc, 09-19-2011, 01:12 PM
Yeah that's why I am wondering the table counts that cause this problem. I mean are we talking thousands or tens of thousands before the problem starts? (We don't have any dense shared systems or even systems with more than a couple hundred tables) and in testing have not managed to duplicate this - but that's minimal 3x testing across only a handful of systems.
Posted by TonyB, 09-19-2011, 02:02 PM
7000 tables which is not a lot for a shared hosting system. What sort of latency between the agent and the CDP server? From our testing that seems to be where the problem is. We have servers with 25,000 tables that are local that do the same task in 10-20 minutes. So if you were to time two identical system. One with say .2ms away from the CDP server and another say 50ms away you'd see a dramatic difference in completion times of the mysql discovery task. The rest of the tasks will be similar assuming you can get the same throughput.
Posted by Steven, 09-19-2011, 02:11 PM
Have you monitored the bandwidth throughput with a local and remote server?
Posted by TonyB, 09-19-2011, 02:23 PM
We have and they're pretty close: 15MB/sec vs 17MB/sec. Only a 12% difference. The speed differences of MySQL portion are much more dramatic. The 15MB/sec system does 0.13 databases per second scanned the other does 2.08 databases per second. These numbers are all of course rough we don't have identical machines sitting around doing nothing to sit there benchmarking r1soft performance. We basically deployed another CDP server decided to use v3. Attempted to convert some machines from various locations and quickly realized the more latency we had the worse the MySQL replication portion became. We left one machine with higher latency on the v3 server to see if newer versions will eventually address this.

Add to Favourites Print this Article