Jump to content

Fletchi18

Members
  • Content count

    20
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Fletchi18

  • Rank
    Occasional forum poster
  1. Fletchi18

    I am getting tired...

    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.
  2. Fletchi18

    I am getting tired...

    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!!).
  3. Fletchi18

    I am getting tired...

    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!
  4. Fletchi18

    I am getting tired...

    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.
  5. We are having that same issue here. Every file on our Servers is being backed up on a nightly basis using Retrospect's 'normal' backup type. I was told it had something to do with our Antivirus but I have done some testing and found that not to be true. I was also told to uncheck 'back up file security information from servers' to resolve this issue, and that did not work either. I do like your idea of setting the script not to back items up older than XX hours, but if the program is already built to do an incremental backup and it's not doing it, it shouldn't be up to us to have to fudge things. Just my thoughts...
  6. Fletchi18

    Buffer overrun detected!

    This is all I will say on the subject of the buffer overrun/assertion issue as not to hijack the topic: the tech on the phone said that when we downgraded, that caused an issue with the catalog, or the scripts, etc. He did not say it was caused by the whatever was going wrong *after* the downgrade. Thanks!
  7. Fletchi18

    Buffer overrun detected!

    Support suggested to me to downgrade to 7.5.324. This eliminated the buffer overrun error, but now I am getting assertion errors and their suggestion is to basically redo the server. Just a warning to everyone who receives the suggestion to downgrade. Be wary as it has the potential to corrupt all of your Retrospect settings.
  8. That was suggested to us by Retrospect support and it had no affect on anything. Every file on the servers is still being backed up, instead of just the ones that have been changed or new.
  9. Here's an update from my place here: in anticipation of the daylight saving time change, we have updated all of our servers with the latest microsoft patches. Since doing so, our backups have gone from taking 18 hours to taking 8 hours. So, the backup *time* has gone down. That is a good thing. However, that doesn't change the fact that every single file on darn near every server we have is being backed up nightly. Thanks for the info, Richy Boy. I'll talk to the folks here and see when they upgraded to the lastest version and see if I can trace things back.
  10. Fletchi18

    Buffer overrun detected!

    No, just a plain old dual pentium 2.8s.
  11. Does anyone have any experience with Symantec Antivirus changing the archive bit on all files it scans? It was suggested by phone support that this could be the cause of our issues.
  12. Fletchi18

    Buffer overrun detected!

    Not sure where the server was as far as the page file. I will check when the issues happens again. To anyone experiencing this issue, I spoke with phone support and they said that they are working on this issue.
  13. Fletchi18

    Buffer overrun detected!

    Once again I come in to find the buffer overrun error message on my backup server's screen. Anyone have any leads?
  14. Fletchi18

    Buffer overrun detected!

    Retrospect version / Client version Server: 7.5.370 Client:7.5.116 OS version: server: win 2k3 desktops: win xp CPU information: dual core 2.8 Amount of memory: 2 gigs Amount of data being backed up: about 100 meg on that particular client Make/model/type of backup devices in use: Dell Optiplex GX620 Type of backup script - managed vs Proactive: Managed When does the error occur - during scanning/matching? During copy? During copy How much memory is in use when the error occurs? When we discovered the issue, Retrospect process was using about 1.2 gigs of ram What is the state of the pagefile? Not sure what you're asking.... I have set up some perfmon logging on the server so I'll be able to get you more info if it happens again.
  15. Fletchi18

    Buffer overrun detected!

    We received this error once again last night. I also noticed that the Retrospect task is using 1.2 gigs of memory.
×