Jump to content

Backup stuck in 'Closing'


pscs

Recommended Posts

Paul,

 

Just so you know, I am running the latest version and I am STILL having those issues. In fact, it is Monday morning and on one of my backup servers I lost one of three execution units because the job on Friday got "stuck" at closing, locking up the execution unit since Friday afternoon.

 

Of course that doesn't compare to the newest problem I am now having. One of my backup servers rebooted over the weekend from what appears to be an IDE controller problem. Anyway, when the server came backup Retrospect tprompted me to reinstall my license key (which I knew was bad sign) and then when it finally loaded it had lost ALL my changes since August! All my jobs...GONE. All my backup sets...GONE! My entire damn day now...GONE!

 

This is why people drink! Hope your day is going better than mine!

 

JJ

Link to comment
Share on other sites

  • Replies 93
  • Created
  • Last Reply

Hi

 

Your backup sets and data are not lost (unless you have a disk failure of course). Retrospect just doesn't know where they are on your disk because it sounds like your preference files we damaged.

 

The preference files for Retrospect can be found in the following folder:

 

C:\Documents and settings\all users\ application data (hidden)\retrospect\config65.dat and config65.bak

 

All of your scripts and settings are kept in there. If you have a backup copy of these files on your tapes you can simply restore them.

 

Nate

Link to comment
Share on other sites

Paul,

 

It occurs to me we never tried using clean Retrospect preference files. If the problem comes back try renaming the files listed below. When you launch Retrospect again it will ask for you license code - this is equivalent to doing a full reinstall of Retrospect

 

C:\Documents and settings\all users\ application data (hidden)\retrospect\config65.dat and config65.bak

 

Nate

 

Link to comment
Share on other sites

I am also having the same problem.

My configuration is.

Backup Server = Windows 2000 Server sp4 Retrospect 6.5.319

Client = Windows 2000 Server sp4 Retrospect Client 6.5.131

Most backups are to disk backup sets.

 

When I called support they recommended replacing my configuration files and redoing my configuration (their thought was a corrupt config file). I have a hard time with this since it would take many hours to do.

 

While a job is stuck in closing other jobs continue to start run and complete with no problems (as long as they don’t have any resources in common).

 

I have been spending a large portion of my day/night dealing with this. Please Help!

 

-Pete

 

Link to comment
Share on other sites

Pete,

 

Do your other (successful) backup jobs backup to a (different, of course) file backup set located on the same hard drive (as the failing backup set) as well?

 

Just trying to figure out if the problem is local to one of the drives, perhaps, or backup set type...

 

Mikee

computer.gif

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Hi All,

I am having the same issues with my AIT 3. We are running Win2K, SP3 and Retrospect v 6.0 with the latest driver update.

 

There are no issues with our network since two seperate groups are using the same Cisco 5509 switch, one is backed up by Retrospect 5.0 on an Xserve and the other is the Win2K box. The Xserve is working perfectly with no network timeout issues. The PC however is not. First problem is the backup not finishing because it's "closing". Second, when I try to connect to PC clients (who are using Retrospect Client 6.5131) the client says "In Use - Speed Test", or "In use - Preparing" but never goes anywhere from there. Turning off the client aborts the operation. Restarting the client yeilds no differance.

 

Browsing through the forum I've decided to try tossing the prefs, but somehow after what I've read here it won't make a differnce.

 

If I still have the problems (after the pref reset) I'll post again. As with everyone here I hope there is a solution to this.

 

Jeff

 

 

 

 

 

Link to comment
Share on other sites

  • 3 weeks later...

Has there been any resolution to this issue yet? I have been reading through the posts and while there are many suggestions I have not found anyone list the fix for this. I am still having several servers that get "stuck at closing" on jobs and would love a solution to this.

Link to comment
Share on other sites

  • 2 weeks later...

I've got this same problem.

 

The last time I force quit Retrospect the registry got corrupted and I had to reload the OS. I decided to load EVERYTHING from scratch.

 

I loaded Windows XP with all of the current updates and Retrospect 6.5.336 with RDU 4.5.101. I updated ALL of the clients to the newest versions (6.5.132 for PC, 5.1.157 Mac OS 9, 5.1.109 Mac OS X). I didn't copy in the old preferences. I created all new backup scripts and backup files (I'm backing up to files on local IDE disks).

 

The dreaded problem started occuring almost right away with multiple backup scripts and backup files. I've been able to get Retrospect to quit a few times by clicking Stop and quitting Retrospect. After a half hour or so it actually quits at which point I can start it up again and continue backing up.

Link to comment
Share on other sites

Hi

 

I had a wierd problem where my Mac client would not backup properly unless I dropped the physical network speed to 10 Mb full duplex. At 100Mb it would hang and drop packets but it works great at 10Mb.

 

Try dropping the speed on the problem client machine and see if it makes a difference. You can do this in the driver settings for the network card. I haven't tried this on a Windows box yet but it is worth a shot.

 

Nate

Link to comment
Share on other sites

Here's my "me too" message. I started a thread (so far, no replies) in the Retrospect Pro section because that's what I'm using, but the symptoms are the same.

 

RP 6.5.336, Win XP Pro SP1 on backup server and clients. Hangs only on the last volume to be backed up, which is either the local machine or one of the remote machines, depending on what's connected at the time.

 

Did an uninstall/reboot/reinstall without any change. System restore & OFO are both turned on, have not tried turning off. Have not tried renaming the config file either; I'll try that too...but what a PITA if that's the solution!

 

Like another poster, forcibly terminating Retrospect damaged my registry. Windows rolled back to a previous version. Hate it when that happens, too.

Link to comment
Share on other sites

  • 3 weeks later...

After a month of thinking my problem was solved by the upgrade, it's back again..

 

What annoys me is that the answers given by Retrospect are the 'simple', upgrade, reinstall, remove settings and restart type answers. No one seems to be wanting to get to the bottom of what's causing the problem.

 

With the software WE write, we never give those answers as there's usually either something gone wrong with the software, or it's a setting problem that needs fixing, and it's best, in the long run, to start with a broken system and try to fix it than to go back to a working system and hope it doesn't go wrong again.

 

It's obvious from this thread that it's not just an isolated case, so if the settings are getting corrupted, doesn't someone want to work out why? If the software is just getting stuck in an infinite loop or something, does no one care?

 

 

Link to comment
Share on other sites

  • 2 months later...

I am reposting to this thread so it gets attention again. I now have serveral Retro servers, running the latest version having the same problem. This is crippling my backups. If I can't get an answer to this problem I will probably have to switch to another product as I can't have my jobs getting stuck at "Closing" during the night. I came in this morning and one server had 22 jobs queued up because of this! Which of course meant I had to run the jobs during the work day to make sure the servers got backed up.

 

And before I get asked this once more:

 

Windows 2000 Server w/latest service packs and patches

Retrospect 6.5.336

 

Link to comment
Share on other sites

We recently upgraded to version 6.5 (from 6.0) (just a sidebar, I've been using Retrospect since v1.3).

 

Since that time I have had nothing but problems of one sort or another.

 

Granted some/many were likely my fault, *BUT*, I have a problem with the very repeatable behavior of application hang and logs not being updated.

 

We stop our backups at 8am every weekday M-F.

 

If Retrospect is running, it never closes it session and the log is never, EVER updated.

 

When you look at the log, it would appear that the script did launch, resolved the first client's containers, then was cancelled by the operator! In the meantime 50 clients are backed up to tape but there is no evidence other than the size of my catalog.

 

Why does Retrospect hang instead of gracefully closing when using?

 

Why don't the logs update?

 

Why do Events in the Activity Monitor show that my script never executed between 1.25.2004 and 1.29.2004 but the log does?

 

I would send you the log file BUT THERE ISN'T ONE! (Helllllllllllloooo McFly?)

 

Running Win 2000, fully patched, Retrospect 6.5.276.

 

OS Name Microsoft Windows 2000 Professional

Version 5.0.2195 Service Pack 4 Build 2195

OS Manufacturer Microsoft Corporation

System Name BIOPCBKUPSRVR

System Manufacturer VIA601

System Model AWRDACPI

System Type X86-based PC

Processor x86 Family 6 Model 8 Stepping 10 GenuineIntel ~997 Mhz

BIOS Version Award Modular BIOS v6.00PG

Windows Directory C:\WINNT

System Directory C:\WINNT\system32

Boot Device \Device\Harddisk0\Partition1

Locale United States

Total Physical Memory 515,568 KB

Available Physical Memory 383,060 KB

Total Virtual Memory 2,547,820 KB

Available Virtual Memory 2,207,956 KB

Page File Space 2,032,252 KB

Page File E:\pagefile.sys

 

And if one Dantz goon tells me to shred my cofigs and try again, I would like *them* to come here and do all 100 client settings!

 

-tom

Link to comment
Share on other sites

Hi

 

I believe Retrospect is supposed to write to the log after completing the backup of each volume. Thats what it does for me anyway.

 

I would rename/move/delete your operations log (not your configs) so that Retrospect is forced to create a new one.

 

I suspect that the problem is elsewhere though. Specifically that Retrospect actually hung shortly after launching. What do your backup sets indicate was backed up? If you manually run the backup does Retrospect hang after resolving the clients?

 

Yours truly,

one Dantz goon

 

Link to comment
Share on other sites

Here is a perfect example that I am looking at this morning.

 

+ Recycle backup using MYSERVER Week 1 at 1/31/2004 11:43 PM (Execution unit 2)

To Backup Set MYSERVER Week 1...

1/31/2004 11:43:23 PM: Recycle backup: The Backup Set was reset

 

- 1/31/2004 11:43:23 PM: Copying CUSTOMERDATA (D:) on WMA154

1/31/2004 11:43:23 PM: Connected to MYSERVER

1/31/2004 11:53:18 PM: Snapshot stored, 2,781 KB

1/31/2004 11:53:25 PM: Execution completed successfully

Completed: 4390 files, 707.6 MB, with 23% compression

Performance: 87.3 MB/minute

Duration: 00:09:59 (00:01:11 idle/loading/preparing)

 

As you can see it says the job completed at 11:53:25 PM on 1/31/2004...however today is 2/2/2004 and the job is still taking up an execution unit with "Closing..." listed as the status. I am unable to stop the job and cannot close Retrospect via the "Quit" menu choice. My only option is to use task manager and stop Retrospect that way.

 

This problem is really killing my ability to do backjup jobs as that execution unit was not available all weekend long for my backups and now I have backup jobs queued up still pending because of it.

 

Link to comment
Share on other sites

Hi

 

Does this happen on random machines across the network or just one in particular? Does Retrospect respond if you stop the client service on the remote machine? How about shutting down or restarting the remote machine? Have you tried uninstalling/reinstalling the NIC driver on the primary backup machine?

 

I'm not sure if it will help but there is an update to Retrospect 6.5.336 on the updates page you might want to try.

 

Are you using the open file backup module on this client? Is there any difference if you turn off Open file in your backups?

 

Thanks

Nate

Link to comment
Share on other sites

In my case it's on random machines

Stopping the client service achieves nothing

I haven't tried restarting the remote machine, but I don't think it would help - Netstat shows no active connection to the server IIRC

Uninstalling/reinstalling the NIC driver isn't going to help..

 

OFBs are off, no difference.

 

It just needs someone at Retrospect to decide there's a problem and do some proper diagnostics rather than 'willy nilly messing around' in the hope that customers will go away.

 

 

Link to comment
Share on other sites

Quote:

It just needs someone at Retrospect to decide there's a problem and do some proper diagnostics rather than 'willy nilly messing around' in the hope that customers will go away.

 

 


 

Sorry to hijack the thread but this is a really provocative remark. One thing's for certain...the customers will go away. Speaking for myself, I used to be partial to Retrospect, but now advise clients to use other backup products. I'd rather be using Retrospect because of its price, well-designed database and proactive backup...but it's just plain not reliable enough. And some of the problems I've had with it persist, upgrade after upgrade.

 

I'd like to stay and chat, but I have to go check my clients' Retrospect backups to see what went wrong last night!

Link to comment
Share on other sites

WEll, you are about to get the same answer someone else wrote back stating.

 

- Random machines

- Random times

- Random backup servers in fact with different hardware

- Stopping the client does NOTHING, tho the client in this case does say it is in use by Retrospect.

- I cannot restart the client machines as these are customer facing machines. I need them to stay up and be accessible by clients.

 

Let's try a different approach here, let's go on a whim and assume its the Retrospect product and not our hardware. What is Retrospect trying to do when the status is "Closing..."? Is it writing to the log, is it updating the client somehow, is it finishing up the snapshot? If we know exactly is it doing at the time you see "Closing..." listed as a status then maybe we can figure out what is failing. For the record, this is beyond ridiculous. Take a look at how many posters there are to this thread...ALL WITH THE SAME PROBLEM! We can't all have bad Nics.

Link to comment
Share on other sites

Hey all,

 

I have been working with Nate from Dantz (many thanks on this Nate) and we *think* it may have something to do with the RetroEventHandler that is called at the end when a script finishes. I am doing some testing to see if disabling this helps and switching my script over to VB.

 

I would recommend anyone else having this issue to try turning off an scripts you have called by the RetroEventHandler and see if that helps as we narrow down this issue.

 

Jeff

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...