Jump to content

I am getting tired...


bnj

Recommended Posts

Dear friends

I am getting more and more frustrated about this software.

 

We have a multiserver licence with most addons. We are backing up ca 100 computers, win, mac linux.

The server is an XP box with 2GB memory and 2TB disks that are "transfered" every day to tape. The server is not doing anything else than this.

 

For the price of the software I think it is really not working well enough.

 

Since the last update I have had nothing but work to do with repairing catalog files after numerous crashes. Retrospect funny enough asumes it dies because of power failures. Buffer overrun it says sometimes.

 

Before the latest update we also had version 7.5, which we paid for about a year ago. 7.0 was a very, very! slow mess. 7.5 is faster, but still not good. There is a memory leak that eats up the memory after some days, which means I have to restart the program several times per week in order to avoid crashes. This problem has been there at least since v7.0. We paid quite some money to get the "upgrade" from 7 to 7.5. I claim that this was more a fix, since the program started to do some of the things 7.0 was promised to do, but couldnt really because of the slow program and gui.

 

This program really has some nice features, proactive backup, transfer to tape, multi threading (although I am not sure it uses all available CPU's if more than 1), etc. If Dantz, EMC or insignia, (whoever it is right now) cannot make this working soon, we have to start looking for alternatives. This is getting far too expensive to use.

 

I would expect to use somthing like an hour per week to check that things are progressing, put in new tapes and add/modify clients. The last month I have probably used in average 2-3 hours/day and there is still a lot of clients that are not backed up because of corrupted index files for the disk backup sets and now also the tape set. I cannot repair the catalogs faster than they are messed up by retrospect because of crashes. I have decreased the number of used threads from 8 to 3. It seems to help on the buffer overrun issue. I am sanding in...

 

Maybe it is so that Retrospect is not really meant to be used for so many clients? If so, please let me know! I would guess the server could serve at least 200 clients if only the software was not giving us so much touble.

 

Desperate Brian...

Link to comment
Share on other sites

You are not alone.

 

I too have invalid catalog files, corrupted backupset ect. ect.

 

Funny though - it´s nearly always the same backupset/catalog that gets messed up even though I have forgotten the backupset, recreated it, repaired it, moved it to another location.

 

I am quite sure my hardware is okay - I manegement software do not report any HW problems at all.

I have email with techsupport several times regarding this issue, but have not recieved any suggestions yet or solution to the problem. I am to running the latest build.

 

Se below:

 

13-04-2007 14:16:23: Transferring from Backup01-server

DATA (E:) (07-04-2007 19:04)

Backup Set format inconsistency (9 at 2)

13-04-2007 14:17:08: 1 execution errors

Remaining: 1 files, 404,2 MB

Completed: 24 files, 1,1 GB

Performance: 1435,5 MB/minute

Duration: 00:00:42 (00:00:01 idle/loading/preparing)

 

 

- 13-04-2007 14:17:08: Transferring from Backup01-server

DATA (E:) (06-04-2007 19:05)

Backup Set format inconsistency (9 at 2)

13-04-2007 14:18:36: 1 execution errors

Remaining: 1 files, 404,2 MB

Completed: 23 files, 1,8 GB

Performance: 1250,3 MB/minute

Duration: 00:01:26 (00:00:01 idle/loading/preparing)

 

Script: Groom-Backup01-Server-backupset

 

Date: 28-03-2007

 

Script "Groom-Backup01-Server-backupset" completed with 2 errors

 

Script: Groom-Backup01-Server-backupset

 

Date: 28-03-2007

 

Can't compress Catalog File for Backup Set Backup01-Server, error -1 (unknown)

 

Script: Groom-Backup01-Server-backupset

 

Date: 28-03-2007

 

Grooming Backup Set Backup01-Server failed, error -2241 (Catalog File invalid/damaged)

 

Script: Groom-Backup01-Server-backupset

 

Date: 28-03-2007

 

Grooming Backup Set Backup01-Server failed, error -2241 (Catalog File invalid/damaged)

Link to comment
Share on other sites

For what it's worth: What you see isn't normal and I doubt it has anything to do with Retrospect. We have about 60 clients which until recently ran off a Pentium 4, 2GHz. Now it's a Xeon dual core 2.33GHz with 2GB RAM. We don't have any memory leaks, the server is running 24/7 with nothing but Retrospect.

 

Retrospect puts much strain on the hardware, so any hardware problem you might have show up ONLY when running Retrospect.

 

I'm sorry I can't be more specific than: Check your hardware (including firmware and drivers).

Link to comment
Share on other sites

Tjenare Lennart!

 

You might be right (or I hope so). When I look in Windows Task Manager it is Retrospect.exe which hold the memory though. When I restart Retrospect it is released. I dont have to restart the server.

 

We are regularly checking for updates for the hardware, so far without any effect on this problem.

 

Since the last update I also have a suspicion that the disk sets are growing faster. We have just bought 2TB more disk space that we will install soon.

 

Since last summer it worked sort of OK (except for the memory leak and the usual irritations), but the last 1-2 months it has been a real pain. There is a lot of minor things I would have made different with the program, but that is another discussion. I am thinking mostly on the user friendlyness and some reporting and summarizing features that would be neat and nice.

 

/brian

Link to comment
Share on other sites

Quote:

You might be right (or I hope so). When I look in Windows Task Manager it is Retrospect.exe which hold the memory though. When I restart Retrospect it is released. I dont have to restart the server.

 

 


Hejsan Brian.

 

Retrospect uses more memory when a script executes. As soon as the script finishes, the memory usage returns to low levels. We never need to exit Retrospect, so there is nothing wrong with Retrospect on our hardware.

Link to comment
Share on other sites

I'm in the same boat as you, Brian. I have only been working with Retrospect for about 2 months, but in that time, I have had more issues with the software than any other product I've ever worked with (not just backup software, but nearly everything I've touched over the years!).

 

We had a problem with a server and a buffer overrun using 7.5.370, so we were told to downgrade to 7.5.324. After that we kept getting assertion errors and support told me its because I downgraded. So, just to add some more wasted time into the mix, I ended up having to build an entirely new server and things seem to be working ok.

Also, I've been tracking issues on our 4 retrospect servers over the last 2-3 weeks and the memory usage on the servers is pretty amazing. Lennart, you say that, while a script is executing, it uses more memory, then once it's done, the usage goes down. How can it be explained that one of our servers was sitting idle the other day (no scripts running) using 870 megs of memory, with a total resource usage at 1.22 gigs? Or that same server idle using 902 megs of memory with a total system usage of 1.31 gigs? Or another server, again at idle, with retrospect using 374 megs of ram, with a total system usage of 1.45 gigs? If the first 2 aren't evidence, than that last example is pretty clear evidence that there is a serious memory leak issue. Or how about the day Retrospect crashed because it was out of memory. Retrospect was using 264 megs of ram, while the total system usage was 1.99 gigs? Can you say leak? (in best Mr. Rogers voice) Shhhhhhhure you can... Good job boys and girls! (takes off sweater and puts it in the closet).

 

My time consulting with this company is nearly up and I'm actually quite relieved to be getting rid of Retrospect. Let's just hope that my next assignment uses something a bit more stable or at least can support the product a bit better.

Link to comment
Share on other sites

Quote:

For what it's worth: What you see isn't normal and I doubt it has anything to do with Retrospect.

 


 

Retrospect 7.5.x under Windows does indeed crash regularly and it often mangles catalog files as a result of those crashes. These issues are due to bugs and and design flaws in the program, and they are very well-known. If you are using it heavily (though 60 clients isn't that heavy) and not getting crashes, then you are just lucky cool.gif

 

That being said, it has improved a bit since the last update and while it does require continual mothering, it is workable and it does, in the end, get the job done when it comes to bringing back people's data. Also, I'm sure these problems will get resolved, eventually.

Link to comment
Share on other sites

The problem we're finding here is it DOES require mothering... and anyone with a child in a nursery knows mothering costs money!

 

I'm can't wait for a new build as I'm sure the problems I'm seeing are caused by this latest build... Can anyone point me towards .324 as I can't find it on their site.

 

Cheers,

 

Rich

Link to comment
Share on other sites

Hi all

I went back to the earlier version and now I am back with "only" the old problems that I described before.

 

Richy Boy Look here:

 

http://kb.dantz.com/article.asp?article=9607&p=2

 

I installed the extra 2TB so I am good for a while I guess. I tried to make a safe VB script that could restart Retrospect every second day or so, but with no succcess...

 

The problem with the memory use is the same as Fletchi18 described. The memory is used, but not released again, even if the software is idle. The memory is released only when restarting the program. In the old days (Before version 7.0), one could see the progress of the program by monitoring the memory humps passing by in the Task Manager. Now it is more a line slowly climbing only with smaller modulations.

 

/brian

Link to comment
Share on other sites

So, here I am, on my last day here, and I enter my cube blissfully unaware of what awaits me.

I sit down, comfortable in my knowledge that the troublesome server has been eradicated and a new workstation backup server has been built. Yes, indeed...all of that time spend adding clients back to the server, re-cataloging the backed up files, rebuilding scripts...all of that has really been worth it. Ninety-four clients all added by hand (since the program doesn't have a batch adding feature, even for password protected clients...but that is a gripe for another day). Two meticulously created scripts, designed to get every bit of performance out of the application.

Sure, let's open up my vnc viewer and access the new backup server to see how my hard work is paying off.

BAM!! My screen shows what I have dreamed never would happen: Buffer overrun!! Nooooooooooooo!!! How could this be?!?! Thirty seconds ago, I was on top of the world, now it has come crashing down around me...Oooooh Retrospect, you vile mistress!!!

 

So, I guess the moral of this story is: it's not up to us to rebuild, downgrade, upgrade, sidegrade, outwit, outlast, outplay Retrospect. It's up to EMC to fix the dern thing!

 

New server: $1200

Hours spent building the darn thing: $500

Buffer overrun in Retrospect: WORTHLESS!!

 

Thanks to all who, over the last 2 months, have offered their help. I guess I'm one of the lucky ones (good God, I hope) who will hopefully be at a company soon using a product that is stable and has competent support. Take care all!

Link to comment
Share on other sites

Yes, the company has a support service plan with EMC. I spoke with support on several occasions.

 

- Once to find out why Retrospect was doing a full backup every night when it was supposed to be their 'normal (re: incremental). Their reply: it's something with your antivirus. Click.

-Once to find out why we're getting buffer overrun errors. Their reply: go to 324 and you'll be fine.

-Once to find out why we're getting assertion errors. Their reply: well, downgrading to 324 from 370 causes issues with the catalog files, etc. That shouldn't have been done. (well, maybe their tech should communicate a bit more with each other so they can get their stories straight).

 

We are in the process of gathering lots of data to throw at suppor the next time a call is placed and basically lay it on the table: fix this!

 

So, yeah, I've been in contact with them several times, and really haven't gotten much out of it (as you can see by the 370 to 324 incident, it actually made things worse...I had to rebuild the server!!).

Link to comment
Share on other sites

Don't tell me this Fletch, I'm just about to downgrade to 324 in the hope that something starts to work again.

 

My exchange threw...

 

+ Normal backup using Thursday Exchange Backup at 20/04/2007 01:48 (Execution unit 2)

To Backup Set Thursday 500GB...

Can't access backup client MS Exchange 2003, error -505 (backup client reserved)

20/04/2007 01:48:32: Execution incomplete

 

... last night, so I guess I need to kick off another manual backup. I NEVER had exchange issues until this last build, yet after checking and double checking the consistency of the database I find nothing wrong. The amount of times I have had to manually delete 45 mailboxes is getting silly.. (boy am I glad I work for a small company!)

 

I can't help feeling that the poor Retrospect team has been reduced to about 4 people in a small room whilst EMC milks what they can from this product before killing it off.

 

Rich

Link to comment
Share on other sites

Quote:

There is a memory leak that eats up the memory after some days, which means I have to restart the program several times per week in order to avoid crashes.

 


I have monitored our 7.5 server for a few days now and we have no memory leaks. From Windows Task manager:

Day     Mem usage    I/O bytes read     I/O bytes write     I/O bytes other

Wed     19112kB         734GB                361GB                 394GB

Thu      22960kB        1245GB               667GB                 590GB

Fri        15696kB        1727GB             1064GB                 655GB

Mon      19908kB        2962GB             1760GB               1555GB

 

During this time there have been no restarts. There have been backups to tape, backups to disk backup sets, grooming of disk backup sets and transferring snapshots from disk backup sets to tape. (No restore, though.)

 

Maybe it's your hardware driver's that leak???

Link to comment
Share on other sites

EMC's "support" of Retrospect is laughable. We also have a paid support contract with them. I reported a problem backing up my Netware clients(Using the supplied Netware client) within a week of receiving the product. I still have yet to receive any support other than me spending hours and hours of my time generating debugging information for them.

 

I believe my support contract even said something about sending someone on-site if they were unable to resolve the issue within a reasonable time frame. It's been months now and EMC Retrospect is virtually useless to me.

 

They stopped contacting me for several months and I finally got back in touch with them through a "manager" who promised to get back to me several weeks ago. No response, is it time for a class action lawsuit?

Link to comment
Share on other sites

Ok, so a hardware driver issue *might* explain the memory leak issue. However, that still only explains one of the numerous issues I saw while dealing with Retrospect.

At a previous position, where the imaging system alone was about 4 terabytes of data (I won't even begin to talk about the shares, etc. on the SAN...who knows how much data was there!!), traditional incremental backups only took a few hours (as opposed to Retrospects 'normal' backups used to take 12 hours a night for just 1 terabyte because it would back everything up, even if it hadn't been modified!!). The full done on the weekend took the whole weekend, as would be expected. The guy in charge of the backups might have spent about 5 minutes a day looking at the backups and just confirming everything was good. Here I am with barely a terabyte of data to back up in total, and I'm spending about 30-60 minutes a day now that I have somewhat stabilized the system (stabilizing it took me about 3 days). I think that is far too much time to spend baby sitting a backup system.

Backup systems are supposed to give you peace of mind..knowing that all of your data was safe and sound. If backing up the data is this much trouble, what should I expect if, god forbid, something like a full restore is ever needed. I honestly do not get a 'warm fuzzy' feeling with this product.

Link to comment
Share on other sites

Quote:

Maybe it's your hardware driver's that leak???

 


 

That Retrospect leaks memory is a well-known fact. You could post your results till the cows come home, but it won't fix the program for everyone else who isn't so lucky.

 

Quote:

If backing up the data is this much trouble, what should I expect if, god forbid, something like a full restore is ever needed.

 


 

That being said, R does actually come through when it comes to restoring data. It's just keeping the program up that is difficult.

Link to comment
Share on other sites

Quote:

That Retrospect leaks memory is a well-known fact. You could post
your
results till the cows come home, but it won't fix the program for everyone else who isn't so lucky.

 


How do you know it's Retrospect that leaks?

 

I've been using Retrospect since version 3.0. I've had my share of problems with Retrospect. Yes, some of them have been bugs in Retrospect, but I have NEVER had any problems with memory leaks.

 

The overwhelming majority of problems I've had were caused by bad NIC drivers. I've also had problems with bad firmware in our tape/loaders.

 

Since memory leaks isn't a problem for all Retrospect users, I don't think it's caused by a bug in Retrospect. I think it's caused by the strain Retrospect puts on hardware and (possibly buggy) drivers.

 

This is MY experience with Retrospect and MY theory.

Your milage may vary. wink.gif

Link to comment
Share on other sites

Quote:

How do you know it's Retrospect that leaks?

 


 

I don't know if Retrospect is leaking in the particular cases described here, but Retrospect does have many leaks

 

Quote:

Since memory leaks isn't a problem for all Retrospect users, I don't think it's caused by a bug in Retrospect.

 


 

and many bugs.

 

And what's being described here sounds like those leaks and bugs at work.

 

It might be that one sees these bugs more frequently the more strain is put on the program and you are not seeing them because you are not stressing the program, but that's just a guess. Another explanation might be that different editions of Windows may "hide" some bugs better than others.

 

Quote:

I think it's caused by the strain Retrospect puts on hardware and (possibly buggy) drivers.

 


 

I actually don't think Retrospect puts much of a strain on hardware, at least on my hardware in the current version, it doesn't, and I'm backing almost 3 times the number of computers (and probably a lot more data proportionally) than you indicated earlier.

Link to comment
Share on other sites

Hi Lennart

You might be right, but the leaked memory is released when restarting only the program and in the task manager the memory is reported to be held by retrospect.

 

I will try and make a log over some time...

 

/brian

Link to comment
Share on other sites

Quote:

the leaked memory is released when restarting only the program and in the task manager the memory is reported to be held by retrospect.

 


Hi Brian,

 

That's normal. The driver software doesn't run their own processes.

When a process ends, all memory allocated by the process is released (regardsless if it was the called driver allocating the memory or not).

Link to comment
Share on other sites

Quote:

The driver software doesn't run their own processes.

 


It can be done, but it's hard.

 

Quote:

When a process ends, all memory allocated by the process is released (regardsless if it was the called driver allocating the memory or not).

 


Yep. Right on. If it was any other way, it would be trivial to hang any system from a user-level program.

 

Russ

Link to comment
Share on other sites

  • 2 weeks later...

I hear you! Based on your problem description, however, it sounds like you're using Microsoft Small Business Server 2003. It is pitiful, perhaps especially when configured by an Authorized Microsoft SBS VAR. The SQL component has a memory leak, and does bring down the server periodically. The default, our 2nd service person pointed out, was for SQL to use all memory except the last 10MB. It was commonplace for the SQL services to be using 1.4, 1.8, 1.9, 1.95 GB (gigabytes) of RAM on a 2GB system. There was a glitch in our installation such that it required a password to change the upper bound on SQL memory usage, and our service providers could provide no password.

 

I should point out -- worst of all -- that only Webroot's Spysweeper used SQL, and it could have used the simple SQL Express or the MSDE. We ended up junking the "all-Intel SBS" server after three years of this insanity.

 

For our situation, Retrospect and Norton Antivirus softwares were the ONLY two softwares which worked properly from start to finish. EACH and EVERY other piece of software on that box had sustained and major problems from day #1 to the day the box was taken off line.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...