Jump to content


  • Content count

  • Joined

  • Last visited

Posts posted by Fletchi18

  1. 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. 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. 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. 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. 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.

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

  8. 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.

  9. Some side information: 'full' backup on Friday this past weekend took 1d 6 hours. The job that ran last night was on pace to take about 1d 5 hours. Again, this is using the 'normal' backup type after creating the new backup set on Friday.

    So, this further goes to prove that *every* file is being backed up on a nightly basis instead of the 'progressive/incrimental' backup that should be happening.


    I saw some posts in the forums about MD5 and verification in general. Verification is turned off on all jobs (boy, could you imagine what it would be like if verification was on?).

  10. Yeah, they're all to the same back up set. They start a new set each weekend and I'm noticing that, say, on Tuesday, the job still backs up each and every file on the servers.


    No erase or no new media.


    As far as I know, there is nothing done to the server except being used by users. No other backups done, no nothing.


    This is just an aside (but might just show the condition of things in this location): it seems like every night there is something wrong with the backups. At my old job, the only frustration the guy who handled our backups had was the constant requests to restore files. Here, every night it's a new error. One server has a -530 error, so it's rebooted. Another has a -541, again, rebooted, its fine. Another has a -1019. Another with a -519. Most of these end up being 'false positives' and are resolved by the old standby: reboot! Are there that many issues with this application or is it this location? (if this gets to be too major of a question that it will end up hijacking the thread, then we'll talk about it another time).



  11. No, I mean all files are being backed up. I don't think it is due to lack of understanding (it might very well be, but the staff, who have used the product for some time, are stumped as well).

    For example, I found these facts:

    I looked at the session (**make that snapshotview**) information for a server. A new backup set was just created on Friday (which would have been the 'full' backup). During this backup, 51,000 files were backed up. The job that was run last night, Feb 26 at 8:45 pm, was a 'normal' job, which means it was their 'progressive' backup. During this job, 51,000 files were backed up. Either the people here are SUPER busy, or there is something up.

    Looking at another server (full back up on Friday, 'normal' last night), a server with 182,000 files has all of the files marked as being backed up last night. Once again, I think I am working with industry legends here!!

    Is there something that I am missing (or for that fact, the full time staff here)?

  12. I am working as a contractor for a company that has tasked me with fixing their backup issues (I am fairly new to Retrospect, although the last 6 days have been a major league crash course in the app). Among many issues, most of the servers are being backed up completely (rather than just changed files) on a daily basis (I'm told that their scripts are set to do incrimental during the week with a full over the weekend). Any ideas why this might be happening?


    Thanks in advance for any insight in to what might be causing this!


    Retrospect version 7.5.370 running on Server 2003.

    Backing up a number of different clients ranging from server 2003 with 7.5.111 to OSX 10.4 with Mac client 6.0.109.