Backup stuck in 'Closing'

[Mayoff]

We released a new client last night with a bunch of bug fixes. If you haven't tried that, I would recommend it.

 

With Nate's help, we have asked our engineers to investigate these "closing" issues.

[netsys]

I have applied the new updates to both the server, and the client. No help at all.

[nevillev]

Just as interim update, I updated my clients to the "6.5.136" version on 3/19, and I have not had my backup get stuck since then.

 

In a sense it's a pity since I was most of the way through getting Nate a set of log files to help isolate the cause of the problem.

 

Perhaps the problem will return - it has been intermittent after all. I'll post again if and when it recurs.

 

Regards,

-Neville

[nevillev]

Well I spoke too soon. I have had the same "Closing" issue occur again twice now since updating to the 6.5.136 clients.

 

The first time I didn't have logging turned on, but the second time I did.

 

I have sent new log files to Nate - and I'm hoping they'll be able to figure out what went wrong, and fix it for a change.

 

I'm posting this update here to keep the rest of you informed.

 

Regards,

-Neville

[Moriarty]

Hi

 

I had the same here and I try two options.

-One. I reboot my backup server every night and stop and restart the "retrospect client" service before at start my backup at night. Still got the error.

- Second. I turn off the open file backup in my script. Never got the "closing" problem again. The really annoying thing about that is that you get a bunch of error ("sharing violation") when Retrospect create the snapshot. Even if you exclude the file.

 

I know this is only a workaround but at least I get my backup working again. Cannot be worst then the previous version where I didn't have the open file backup option!

 

Martin Moriarty

[netsys]

Just an update here, since applying the new clients, the only server I have had problems with is one using the SQL agent. I do not have the "open files" option selected.

[Stan Mayfield]

Although I see this thread has been running for some time, this is my first occurrence of the problem. Since there aren't many Mac postings, I will add mine.

 

I have an iMac running OS 10.3.2 and am using Retrospect Backup 6.0.178 for the third time to duplicate to a La Cie hard drive. I am not on a network, just my iMac and a Firewire hard drive. I had no problems the first two times I used it. I duplicate instead of backup so I can boot up from the hard drive if I need to. I have been doing this with earlier versions of Retrospect for about a year with no problem.

 

I tried to duplicate prior to loading OS 10.3.3 and ran into the "closing" hangup. I duplicated 5.3G of new data which, with prep time, took about and hour and 15 minutes. Then the closing routine started but it went on for over an hour before I shut it down. I tried again and even though the data duplicated on the second try was much smaller, the closing routine did the same thing. The log doesn't show any errors, just shut down by operator.

 

Since I have never had this problem before, I read through this complete thread but I don't find any answers for this problem with back up or duplication, Windows or Mac. Any good news out there?

[Stan Mayfield]

Double OOPS!

 

First, I looked only at the subject on the main page and not the thread heading...now I see this is for servers,etc. and not single home computers.

 

Second, I found that 6 days ago, Dantz posted an upgrade for Macs which I am in the process of downloading now. Hope it solves the problem.

[Mayoff]

This closing issue is being investigated by our engineers. To be updated on this issue join the RDU notify list at list.dantz.com

[elli]

One more user with the same problem!

 

Retrospect Backup 6.5 (updated on newest version!) runs on Windows XP Prof. We backup network folders on a windows 2000 server (file server) to a file on a removable hard disk. We do NOT use Retrospect Client.

 

What I found out:

 

- If I rename or delete the backup set file and create a new one, Retrospect does close properly

- If I backup just some small files, Retrospect does close properly

- If I backup all the files (up to 12 GBs or more), the problem begins: Retrospect does not close anymore. It can't even be stopped by the task manager. I have to turn off the computer and restart the system!!

 

So the problem may have something to do with a big number of files???

 

Hope this bug will be fixed soon...

[bcarter27]

Same problem here:

 

Retro 6.5.343 running on Win 2000 Pro with 6.5.132 clients running and sticking on Win XP clients. My client does not have the Open File add-on.

[repyzals]

I just installed 6.5.350 and I'm still having the same problem.

[repyzals]

Also installed Retrospect driver update 5.0 and the problem still occurs.

[netsys]

HELLO.....

 

Dantz???????

 

Is anyone else still having this problem? Or has everyone else just given up?

 

We are a VAR, and have been putting a lot of Retrospect servers in. We have stopped, because Dantz has offered NO help and NO indication that they even recognize there is a problem. We are seeing this often on jobs that use either the Exchange or SQL agents, or just drives with large numbers of files. When the problem occurs, it won't even fail the job and allow others to continue. This means major clients, with major data, are not getting backups. THESE ARE THE KINDS OF SERVERS THAT ARE IMPORTANT TO BACK UP!!!!!!!!!!!

 

I'm about to admit to our clients that we have sold this product to that they are screwed, because I thought this was a good product, and sold it to them. We have kept applying every update faithfully, but NOTHING addresses this problem.

 

Does anybody at Dantz think this is even REMOTELY serious? THIS PRODUCT IS DEFECTIVE!!! ARE YOU GOING TO FIX IT, OR JUST KEEP PRETENDING THERE IS NO PROBLEM?

 

If I'm being too subtle and you can't tell, I'm a bit frustrated. Seriously, if anybody at Dantz or anywhere else has any clue here, PLEASE respond. Thank you.

[nevillev]

I have posted on this thread before; and just want to add an update.

 

Nate has worked closely with me; and I've sent him a series of debug log files, assert logs and so forth.

 

The problem has persisted; and I've seen it on a local drive as well as remote machines - similar to Elli, above. I do not (currently) use any external scripts. I use no Open File, SQL, Exchange nor other agents either. I've installed a couple of updates from Dantz too.

 

I remain frustrated that this problem persists.

 

I'm interested in knowing, netsys, what backup software you're now recommending as I'll probably have to change my backup software and strategy in the not too distant future either. My support is coming up for renewal; and I'm not planning on spending more money on it.

 

Thanks,

-Neville

[netsys]

Hi Neville,

 

Unfortunately, I have gone back to the old standby, Backup Exec. I had used them for years, but the duplicate file handling in Retrospect provided options that nobody else had (or to my knowledge, still has).

 

It's too bad, because Retrospect has so many good features. Other than Nate's postings here though, there is no indication that Dantz cares at all that the product is unusable for real networks, where backup is important. I guess serious known instability is okay, as long as your marketing keeps you selling product. Says volumes about the company, doesn't it?

 

Even worse, I have clients where we have installed Retrospect who are growing, which means that if they don't have the problem already, they will. I love telling people that I have sold them defective solutions.

 

If you (or anyone) finds a better alternative, please post it. Maybe if they won't fix their own products, at least maybe Dantz can provide us a forum to try to help each other out of this mess. Thanks.

[gwayne]

I have read every single post in this thread and these are the EXACT same problems that have been plaguing my backup system. As many have stated, these problems have essentially rendered Retrospect useless and we too are looking at Backup Exec.

 

Nate, please contact me to get log files.

 

Thanks,

Glenn

[Zarniwoop]

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 :-)

[Mayoff]

Users with this "closing" issue should download a Trial to Retrospect 7 to see if the problem continues. If it works better for you, please let us know.