Jump to content

Zarniwoop

Members
  • Content count

    18
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Zarniwoop

  • Rank
    Occasional Forum Poster
  1. I can see how to force a grooming manually, but I can't find how to schedule one. Can someone point me out how to schedule a grooming job on a backup set? Grooming on my 600 gig disk set takes well over 12 hours, and I could schedule that time conveniently on the weekend after the transfer snapshots to tape run finishes. If there is no scheduling option, can you please add the option to schedule a grooming in the next update? Thanks,
  2. Zarniwoop

    Backup stuck in 'Closing'

    My backups haven't hung on closing or on clients for a long time. Things I did and still do to work around it: Make a separate clients group for the problem client(s). Add that group to the end of the backup sources, so everyone else is backed up first - if it hangs, everyone but the problem clients have been backed up. -- Haven't had any issues with this for many months. If the backup ever hangs on a client, go to the client (or use Computer Management and connect to the remote computer) and stop the client's Retrospect Client service. This always lets my server figure out that the client is hung, and it ends the backup and rolls the temp logs into the main logs, so you don't lose the backup session's log entries. -- Haven't had to reset a hung client for many months. Always keep the retrospect program open on the backup console. -- Yup, I still do this. I had many problems in early versions of Retrospect with it firing up and performing backups when it was supposed to. As long as I left the backup console logged in and Retrospect running, I never had it fail to do a backup again. So I've never stopped the practice. I can't say if this is fixed or not. Since I have two other applications that only run as a logged-in application rather than a background service, I just consider Retrospect in the same category and have the console logged in 24/7. The screen saver is password protected, the backup server has physically controlled access... You can argue that you shouldn't have to do something like this but I do whatever works because, well, it works! I almost abandoned Retrospect a year ago but after evaluating all of the offerings of Veritas, I stayed with Retrospect and I'm glad because since 6.5.343 came out I haven't had any problems. Our company needs the Backup Set feature - files aren't added if they are already in the set, even if 30 clients all have the same file it is just backed up once. Our company needs the total backup features - all files on all clients are backed up. Veritas has some add-ons for mobile and desktop files but they are pitiful and only back up "My Documents". Our users will save files in arbitrary locations such as "C:\My Files" and no matter how I tried to configure it, Veritas would have missed files on the clients. The pricing was no better for Veritas, especially if adding Exchange and Open File pieces compared to just Value Package upgrade. Our laptops are backed up with the Proactive backup set. They are backed up at scheduled intervals whenever they are on the network, and they don't have to be left on all night to overheat and wear out sooner. Look at some of my previous postings; I have flamed Retrospect as much as anyone. To their credit, they have fixed a lot of problems and there are also workarounds that I use that may help you make your Retrospect more stable as well. What I have to stress is that you do and use whatever works for you, because, well, it works! For me, backup HAS to work. Even our reliable oldest server at a remote office that still uses Backup Exec 8 has a quirk in the backups occasionally, and needs a reboot to set things straight again. It's an app running on Microsoft servers; there will never be a substitute for monitoring and maintenance... If your goal is to never have to touch your servers then you're going to have to switch everything to Linux :-)
  3. Zarniwoop

    Retrospect & XP SP2?

    If you have a domain with Windows Server 2003, you can use Group Policy to configure XP SP2 firewall. If you don't have 2003, you can still add the following entry to your login scripts: netsh firewall set portopening protocol = ALL port = 497 name = "Retrospect Backup" mode = ENABLE scope = SUBNET profile = DOMAIN (that is all on 1 line) Note that you may need to change scope = SUBNET if all your clients aren't in the same subnet as the backup server... This will keep you from having to manually go visit each workstation to get Retrospect client working after SP2 installs. I don't know if this requires local admin rights, all my users already have it on their own workstation...
  4. Zarniwoop

    rotation issue..

    One of the multi-star posters stated the rules for concurrent executions in another thread. Quoting the User's Guide: "If a specific source or destination is in use by one operation, Retrospect cannot use that source or destination for another concurrent operation" and of course, "You must have at least two execution units available to run multiple concurrent operations" So you have to make sure that you have two separate sources, as you said, and that the tape drives are separate destinations, and it can do them simultaneously.
  5. On the monitor screen, proactive tab, there is a pull-down that lets you watch "Sources", "Backup Sets", or "Scripts" Make sure you are watching the Sources view, then click on each client to see the Status and other data update for that client. You will see why a given client is or is not backing up (the laptop isn't there, the backup set is in use by another script, etc.) If you notice that it is saying the client is not found, then you can track down why it is skipping over that client (see below). I only use the Scripts view to activate or deactivate a script. The rest of the time I leave it on Sources. I have one client that seems to stop being found by Retrospect frequently. I am installing the 6.5.136 client on it now, and hoping that it will fix this issue. The client is not going into standby or hibernate, it responds to pings, it doesn't have the firewall enabled, and the Retrospect Client service shows Running, but retrospect can't find this client until I stop the Retrospect Client service on the client, wait for a few seconds, then start the service again. As soon as I do this, Retrospect can find the client and do a backup.
  6. Zarniwoop

    Backup stuck in 'Closing'

    Before you terminate Retrospect on the SERVER, try stopping the client's Retrospect Client service (I do this with Computer Management, connecting to the remote computer). This always lets my server figure out that the client is hung, and it ends the backup and rolls the temp logs into the main logs. I haven't had a hang on the problem client since upgrading to 6.5.343.
  7. Zarniwoop

    Backup stuck in 'Closing'

    I have one client that the backup gets stuck on a lot since upgrading from 5.6 to 6.5. If I stop the retrospect client service on the client, the server finally sees that it isn't getting anywhere and reports an error about backing up the COM database. I've found that when the "Off" button in the Retrospect Client app doesn't do any good, stopping the service does. Stopping the client service also lets the server close out the backup, and roll the logs into the main logs. The prior posts regarding losing logs are from killing Retrospect on the Server, when it's the client that is hanging. (Yes, I know the Server SHOULD time out on a client after a while, no idea why it doesn't, and I've mentioned this a lot in the past.) Anyway, a few days ago, I separated this client into a separate script that is scheduled to start a little after the main script that backs up all the clients. I did this so I could try turning off the option to backup the System State on just this client, and so far it hasn't hung up since. This client is Windows 2000 Pro with latest service pack and Windows Updates, and is NOT configured to standby, sleep, etc. I have no idea what is causing the hang, but I'm more concerned with backing up all the files on this workstation than getting a good registry backup so this is an adequate workaround for me. You can use this idea and see if it helps.
  8. You mention you are using Multi Server version, so make sure you have configured your "Execution, Security Preferences" correctly. It's in the User's Guide. You need to have Retrospect always run as a user who has permission to back up things like Exchange, SQL server, and other computers in your network.
  9. Zarniwoop

    rotation issue..

    If you can't see how Set-based strategy is an advantage, then you can just make yourself a new Selector, and "Include everything... but always exclude files matching Windows Attribute Archive Bit is not set". Then in your backup options, turn on "Windows, System, Clear archive attribute", so it unsets the Archive bit when it backs up the file. Now it will work just like everyone else's backup software. Retrospect backs up two ways; "normal" and "recycle". To understand this, you just have to stop thinking in terms of "Archive bit" on each file. Recycle erases the Backup Set and starts over. Normal adds to the Backup Set, and unless you change the options it does not add duplicate files that are already in the Set. You want to take a tape offsite each night and have full recoverability in the case of a disaster, so you need at least two Backup Sets. If you never want all your sets in the same place you would need to make extra trips offsite, or have three sets. Lets say you have Set1, Set2 and Set3. Your Monday backup puts every file (except temporary and cache files, perhaps?) in Set1. You take it offsite. Your Tuesday backup puts every file in Set2. This duplication is one way you probably don't like how Retrospect is different, but bear with me and you will understand it. You take Set2 offsite. Your Wednesday backup puts every file in Set3. You take Set3 offsite. Why all the duplication? Because each set is an individual recovery unit that doesn't depend on the other sets. Here is where Retrospect actually gets better than backing up based on Archive Bit: Thursday, you bring Set1 onsite, and back up Normal to it. It gets every file that doesn't match what is in Set1, in other words, since Monday. It skips files that are the same, so you don't back up Windows XP SP1 from each workstation you back up because they are all the same files. This can actually make that Monday backup much smaller than "the competition" because of the fact that it skips all files already in the set. If you back up 50 clients, you back up all the files when it does the first client, but then you skip duplicate files like Windows XP and Office XP on the 49 other clients because those files are already in the set. If you only back up one file server, this won't be so much of an advantage to you. Friday, you bring Set2 onsite. You back up Normal to Set2. It gets every file that doesn't match what's in Set2, in other words, since Tuesday. You see how it goes. You can play out how a disaster would effect your tapes. It is possible that two Backup Sets are onsite and destroyed, or there could be only one onsite when disaster strikes. Think about how restoring would work. In my example, it's Friday, and you've brought Set2 onsite. If you've taken Set1 offsite, and disaster strikes, you won't lose it. You lose Set2, but you have everything in Set1 you need. If Set1 and Set2 both burn to the ground because you haven't left with them for the day yet, you still have Set3, although it hasn't been updated since Wednesday. I didn't even mention how snapshots let you restore exactly how things looked when they were backed up. If you've deleted a bunch of files, they aren't restored because the snapshot knows they were gone at that time.
  10. Zarniwoop

    Backup stuck in 'Closing'

    If you follow the links and "Show All User's Posts" on me, you'll find that the locked backup problem has been around since at least Version 5.6 11/6/02... Because you are having the problem with version 6.5 you get the benefit of active support, but the same problem has gone on for a long time. My two cents, the client that seemed to always "lock" my backup hasn't done it since I re-arranged the clients into more than one "group" and stuck it at the end of the backup. My idea was that if it locked up, it would at least do everyone else first. Lo and behold, it has also made it never lock up again by re-arranging it. I don't know why the Server itself can't time out after a specific interval regardless of what the network and the client is doing. The backup has to finish, that's #1. The client can have any number of things happen to it and the server's job is to keep going and going and going. Nothing that happens to the client or network should ever keep Retrospect from finishing a backup and starting the next one when it is supposed to. While it's good to troubleshoot and find out what could have caused the server to wait forever for the client, fixing the problem with the server waiting too long, logging the failure, and letting the server move on would be best.
  11. Zarniwoop

    Retrospect will not autostart

    I quit trying, long ago, to figure out why backups only fired off reliably if Retrospect was open and running. I now let my server login automatically (can be done via registry edit or tweakui), and I put the Retrospect icon in the Startup. My server is in a secure location so this isn't much of a risk in my situation. That's my helpful two cents. The rest of the message is therapeutic and largely unrelated to your specific problem. I find it troubling that for so many issues that many people have had with 5.x, the issues never got fixed, and that people who did choose to try upgrading to 6.0 say it still does not fix said problem. The support people say that you should try the latest version to get the improvements, the customers say the problems are still there. And of course upgrading isn't free. Retrospect is fickle and moody, and I deal with it with patience and constant monitoring. After much twiddling, I have it working quite reliably. But I wouldn't turn my back on it for even a day, not a chance... Since 5/11/2002: System Availability: 99.9669% Total Uptime: 503d 0h:57m:57s Total Downtime: 0d 3h:59m:53s Total Reboots: 33 Mean Time Between Reboots: 15.25 days Total Bluescreens: 0 Well over half of the reboots were due to fixing locked up Retrospect sessions that wouldn't die.
  12. Have you tried checking the settings under Special; Preferences; Media; Erasure There is a check box for "Minimal erase confirmation" I checked the box (not the default) because my unattended backups were stopping and asking me to confirm using a tape whenever my backup wanted to Recycle it. This sounds like the problem you are now having. Perhaps you or someone changed the setting, then later you noticed the effect of it?
  13. Zarniwoop

    Is retrospect 'Fragile'???

    You keep avoiding the simple question... Does Retrospect 6 address the stability issues? Does Retrospect 6 hang for days on a backup instead of timing out and continuing?
  14. Zarniwoop

    Is retrospect 'Fragile'???

    It would sure be nice if someone bothered to answer that last question... Does upgrading to Retrospect 6 fix any of the "fragile" issues in this thread? My backups are working reliably since turning off Verify and Snapshots. The backups take WAY less time this way, but more importantly they actually complete on all workstations instead of hanging for no reason partway through the backup. However, if I ever need a snapshot, system state, or registry restored I'm pretty much out of luck. I do a periodic snapshot of the Server to get around that risk.
  15. Zarniwoop

    Erasing CD-RW is slow

    I would expect there to be an option to use a short erase. This way, those who don't have a drive with this problem don't have to do long erases after establishing that their drive works fine with short erases.
×