Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About robertdana

  • Rank
    Occasional Forum Poster
  1. robertdana

    Full Backup - Off-Site

    This all hinges on what you consider to be a "full" backup. Retrospect is VERY DIFFERENT from other backup systems and doesn't follow the normal full / differential / incremental regime. The first time you back up to a backup set is a "full". Each subsequent time is something like an "incremental", in that only the changed files are backed up. The difference is most obvious at restore time. In normal backup systems, you have to restore the most recent "full", and the the most recent differential, and then each incremental that has happened since that differential. This is painful, and is one of the reasons why people specify things like "full backup every night". How Retrospect works: each backup to a backup set looks like a "full" backup at restore time (even though only changes were copied). It hides all of the "incremental" complexity, and when you restore from the most recent snapshot in a backup set, all of the files are put back just like it was a "full" backup in a traditional system with a single operation. So you get the efficiency of incrementals, but the convenience of "fulls". So in other words, a "full" backup every night in the traditional sense is not the "retrospect way". There's literally no way to store more than one full backup in a backup set. Relax. This is OK. The system works very well the way it was meant to be used. If you are in some way forced by inflexibly-enforced requirements to do a true full backup every night, the key is to do a "recycle" before each backup, which will blank the previous backup and force a full. "Recycle" is an action available in the script scheduling, so you can set up a "recycle" to occur a few minutes before the backup. You'll have to explicitly schedule each day's backup set. Things will not fail gracefully if the wrong disk is inserted. If you need to keep multiple week's worth of history, you'll have to have separate removable disks / backup sets for each day / week combination (Week1Monday, Week2Monday, etc...). This is a REAL pain to administer. The "right way" would be to create a single backup set for each day of the week, and throw them all into a proactive backup script. The server will automatically back up to whatever set is attached, so you'll get a backup even if someone forgets to change the media. The main downside of a proactive script is that you won't get errors if a particular volume or host isn't available to be backed up. Just let the incrementals build up over time, then recycle or groom as needed.
  2. robertdana

    Backing up DFS Replicated folders

    Robin, can you be more specific about which DFS uses are "unsupported"? We are currently using 7.6 on Windows 2003 server. We have several file shares that have referrals set up in the DFS namespace (not replicated), and have no problem backing those up (via a local client). I see that Retrospect does not support accessing shares via the DFS namespace. This is easily worked around by accessing the shares with their normal names. But the OP sounds like they are trying to back up *local* files that happen to be replicated via DFS, and that is failing. Is this really not supported? That seems like a pretty big issue. We are looking at migrating to 7.7 and then Windows 2008 (separate projects), and DFSR is a very attractive feature...
  3. robertdana

    How much space is required for grooming?

    I've never seen a catalog do that, and I've seen catalogs do a lot of strange things. Must be a 7.7 thing. As for our problem, increasing the amount of free space on the first member of each two-disk backup set from 5% to 10% resolved the problem completely- every groom I've done since the increase has succeeded. It seems strange to me that grooming (an operation designed to free disk space on overly-full volumes) requires a certain amount of free space on those volumes to succeed.
  4. robertdana

    How much space is required for grooming?

    I've started getting "Grooming Backup Set Client A failed, error -1115 (disk full)" whenever I groom a particular backup set (manually or via our weekly scheduled groom). My disk configuration is as follows: Drive c: (boot) - 335GB Free Drive q: (10k rpm drive dedicated to catalogs) - 107GB free Drive F: (1-Client A) 1TB capacity, 55GB Free according to OS, Retrospect set to use 95% (it reports 0% / 8.5GB free on this member) Drive G: (2-Client A) 1TB capacity, same configuration as 1-Client A, but with ~450G free Last night when grooming failed due to "disk full" I checked the event log and noticed a notification that system restore had been suspended because drive F: (1-Client A) was low on free space about 30 minutes before grooming failed, and was resumed about 30 minutes after (noting that disk space had been freed). So it is the data volume itself that is apparently filling up and causing the grooming failure, not the catalog or boot drives. So... how much free space is needed on a member of a multi-member set that is being groomed?
  5. For the specific job I've got, which is backing up a network of windows-based workstations and servers, I don't think there's a better tool than Retrospect. In environments where there is meaningful data on end-user machines, the combination of the "unlimited" client licensing, proactive backup and incremental-centric backup sets is killer. We back up every bit on our network (other than temp files and such), and can recover any machine from scratch in case of a drive failure without reinstalling and rebuilding, and it didn't cost an arm and a leg. There's tremendous value in being able to put a machine back to exactly the way the user had it... so many IT professionals disregard the productivity loss when someone is given a "clean" computer and has to recustomize / repersonalize it to their needs. There are other tools that do pieces, but Retrospect is the only solution I know that brings it all together, for this specific need. Robin, your service on this forum is a tremendous credit to the product and your company. There are so many useless vendor-run support forums monitored by L1 overseas technicians with no real knowledge outside what's written in the KB. I can't tell you how many times I've run into a problem and found the answer here, and I really appreciate that. But... (you knew this was coming) while I didn't suggest that EMC isn't investing in Retrospect at all, the Windows product has stagnated (just as the Mac product did before it). I could write a laundry list of all of the longstanding issues that haven't been addressed that make my life as a Retrospect administrator difficult on a daily basis, but I've done that before, so there's no point to rehashing it. I'm glad to hear that there's a windows release scheduled... there hasn't been anything about it on the blog, and without knowing about it or what is coming it's kinda difficult to get excited when I've got yet another backup set rebuild to run that's going to hold up my weekly offsite tape transfer.
  6. robertdana

    How much space is required for grooming?

    Of course. I was just wondering why the grooming failed with "disk full" when there obviously was enough space, and no other previous sign of corruption. Or is this just a variant of the -2241 issue where we just basically have to suck it up as a fact of life with large backup sets for the foreseeable future?
  7. robertdana

    How much space is required for grooming?

    Yes, it is definitely on that disk. Here's the full error: I find the "can't compress catalog file" error interesting because I have catalog file compression turned off for that backup set. I do get the -2241 issue during grooming about 25% of the time (as discussed in this thread ) but I have done exhaustive testing and am CERTAIN the disk and controller are good. So while it's possible the catalog was corrupt, I know when the catalog for this backup set was last rebuilt, and there haven't been any crashes since then.
  8. I sold Retrospect too when I was a consultant. It has some really great features, but it is high maintenance relative to other backup solutions. In one way, this is good... you never want backups to be failing silently, and Retrospect will highlight each and every little hiccup in the system. Unfortunately, it does not do a great job at distinguishing intelligently between "temporary hiccup" and "something really bad is happening"... thus the "high maintenance" aspect. The basic problem you are having is that Retrospect just hasn't been designed to work well over a WAN of any kind (where there are glitches). It works well with backup clients on a hardwired LAN and directly-attached backup storage- that configuration was the norm when the current incarnation of Retrospect was built, and EMC is just not putting the resources into moving it into the new world of detached / WAN-connected storage (at least on the windows version). Some people do make it work with those configurations, but it requires extremely high quality networking and careful procedures (like making sure the NAS isn't rebooted from underneath it). My suggestion is that you consider backing up to a local volume and then synchronizing that backup set offsite via rsync or something that does block-level differencing and is designed to deal with the vagaries of WAN connectivity.
  9. I'm getting the following error when grooming: Grooming Backup Set Client B failed, error -1115 (disk full) The boot drive of the system (where the catalogs live) has 80GB free. The catalog file is around 20GB (set to uncompressed). The backup set is around 1.2TB. How much free space do I need to maintain? Or does this error mean something else?
  10. Because of grooming problems, I end up rebuilding backup set catalogs regularly. Unfortunately, rebuilding the catalog removes the backup set from any scripts it is participating in... in our case, with a D2D2T strategy, this is a real pain in the neck, as I have to: 1. Add the backup set back to the main backup script, and fix the schedule so it is used. 2. Add the backup set to the snapshot transfer scripts we use for offsite tapes 3. Add the backup set to the weekly grooming script It's easy to forget / fumble this, since the catalog file rebuild takes so long. Of course, it would be better if grooming weren't so buggy, but since that's apparently hard to fix, it would be nice if the process of rebuilding a catalog were easier in the mean time.
  11. robertdana

    Error -2241 while grooming

    We're seeing this exact problem as well (I've confirmed it is not a disk corruption issue). Any update on a fix? -Robert
  12. We fumbled an offsite tape exchange and had the wrong tape in our changer when our weekly offsite snapshot transfer ran. So Retrospect "did the right thing" and added a new blank tape to the backup set automatically. So the current state is that we have two tapes that aren't completely full in the set. Is there a way to force Retrospect to use the empty space on the lower-numbered tape before continuing with the last member of the set? Or is storage in tape backup sets strictly sequential?
  13. robertdana

    Cleaning up after a Retrospect crash

    Cool. The catalog updates often complete really quickly, so I've never been sure how much validation of the media sets they do. -Robert
  14. robertdana

    Cleaning up after a Retrospect crash

    Yeah, I know. I reconfigured everything from scratch about 4-5 months ago (when we moved to a new server), and it came back. Given the amount of pain involved in reconfiguring, I'm not particularly interested in doing it again unless it is guaranteed to resolve the issue. Troubleshooting is near-impossible because the crash is unpredictable and infrequent. Speaking generally, should a catalog update be done before a media verify, or vice versa? We had another crash a while ago that appeared to corrupt an in-use backup set... not just the catalog. We ended up having to do a recycle because the media verify showed so many errors. But I'm wondering if that might be because I didn't repair / rebuild in the correct order. Or are you basically hosed if both the backup set and catalog are damaged? -Robert
  15. Every so often (maybe once a month) Retrospect crashes with an elem.cpp-1000 assertion error. There doesn't seem to be any rhyme or reason to it, and we've just learned to live with it. What I'm interested in is ensuring we are taking the right subsequent steps to ensure the integrity of our backups... sometimes it crashes in the middle of one or more backup operations, and in the past we've later encountered catalog errors after the fact. I'm wondering if there are more proactive steps we should be taking when such crashes occur. We do reboot the server. But should we verify media? Do a catalog repair? Recatalog? If more than one of these, is order important? -Robert