Instant Crashes - Having a Nightmare

[J.T.]

Finally threw iomega's software out of the window, having suffered sluggish computers and ages-long boot splash pages for way too long. I was excited to move to the recommended EMC Retrospect...

 

So I bought it and installed it. That's where the excitement ground to a halt.

 

It took me a day and some 20 reboots before I got the updates installed, ultimately in Windows Safe Mode. That was a nightmare but I was hoping worth it, that it would work after the updates.

 

No such luck. Fire up Retrospect and within one, if lucky two clicks it's frozen. I've not even gotten to the stage of configuring backups though I did get to the stage of finding out it's not recognising my Rev drive. I'm posting this here and not on the iomega forums as I'm only at the stage of getting the software up and running, I'm not at the stage yet of getting it to talk with the rev drive.

 

It's installed on a bog standard Windows XP Pro box which runs nothing but a browser, e-mail client and a card reader. It's not swamped with exotic software and the hardware is only a couple of years old. This machine did not run the Iomega software either.

 

So... What can I do to get Retrospect up and running without these constant, instant crashes?

 

I'm running a business without backups now, which of course is a major concern. Any help in getting us up and running would be great, thanks.

[Mayoff]

I would not expect any of the crashes as you described. Retrospect has been running on 1000's of Windows XP computers for years. If it was crashing computers before even setting up the first backup, we would be in major trouble.

 

To see the REV drive, you do need to make sure the REV drivers are installed.

 

What version of Retrospect are you using?

 

Does removing the card reader help, I do remember a problem many years ago with some card readers.

 

 

[J.T.]

7.5.387 with driver update and hotfix 7.5.11.100

 

I'll give it a shot on an even more clean PC but if it's as resource intensive as Iomega's software was, I really want it on a machine that's normally not actually used by anyone.

[Mayoff]

7.6.123 is the current version. Try updating to it.

[J.T.]

Got it on my own computer now, installed all the updates through and including the 7.6 ones so there's nothing left to update. It went all fine, now also sees the Rev drive.

 

On the first back-up config, it's calculating the size etc. (6.5GB) and then asked me to select a drive which will be renamed. Clicking around in the "Please select a new disk..." pop-up, I now get the "Restrospect (Not Responding)" deal again.

 

I forcibly End Program and I get the popup about power loss or system crash.

 

Will have to see tomorrow on the first actual scheduled run to see whether problems persist.

[Mayoff]

What type of backup set are you creating?

[karefil]

Hello,

 

Having this problem on a customer server, we finaly check TOC (NTFS) of the backup destination disk.

 

Once repaired, all errors gone and no more crashes while backup )

 

Hope this help

[J.T.]

Another half day wasted.

 

It runs now, seemingly OK. It sees the iomega Rev. I make a scheduled backup and it wants to run. My disks are still full from the previous software so it wants to rename and erase and that's again where it gets stuck.

 

If I click the "Media & Devices" button and select the Rev disk, then click the pink eraser, it gives me a bunch of warnings and then... ejects the drive, saying it's busy. Even if I explicitly tick not to do any processing, or pause Retrospect entirely. Having faffed about a few times, I am unable to erase or format. And why isn't there an easy way to format anyway?

 

It crashed a few more times, some of the errors from the log:

 

Device error -208

Execution terminated unexpectedly

Can't use Open File Backup Option

Couldn't erase dis, device busy, -204

 

Insufficient permissions has popped up a few times too.

 

So how do I format a disk? Why does it throw out the disk when I just want to erase?

 

On top of that, it's also struggling to access my NAS disk, saying error 1102 Drive missing/unavailable.

 

Based on previous experiences with the Iomega software and now this, especially the money spent and the time wasted, excuse me for not having high hopes this is going to work smoothly at any stage.

 

Would still appreciate any last rolls of the dice.

 

Regarding TOC NTSF - I'm not even getting to any stage where I can configure/erase/format/otherwise do anything with my Rev disks so at this stage, that's a no go still, but thanks for the tip.

[Mayoff]

If you have other backup software installed, I would remove it.

 

The error -208 and -204 come from the hardware directly saying the items can not be erased by Retrospect. Can you erase the disks within Windows Explorer?

 

[J.T.]

I reinstalled the iomega drivers and now I can finally run some backups. Glad to discover it doesn't suck up as many resources as the old software did.

 

Do have one issue left.

 

I use a Netgear SC101 NAS which each computer just sees as a local disk. The old iomega backup software was able to access this without any fuss.

 

Retrospect can also access it, but every time I reboot, it looses access to it and I need to select the NAS again, in fact a separate one but actually the same, by editing my script.

 

Attached is a screenshot showing what I mean. Scratch that, I can't find a way to attach files.

 

Basically, in the list of sources, on the first day I had my G: NAS drive. On day two, this one greyed out, and a second G: NAS drive appeared below it. I had to select this one to make the script work again.

 

Now many reboots later, I keep having to select the "new" G: drive again under "Add..." in the script's sources and I now have 7 or 8 of the greyed out ones in the list.

 

So it seems that Retrospect references the NAS drive by something which may change upon reboot.

 

Is there nay way around this so I don't have to update my scripts daily?

[Mayoff]

See http://kb.dantz.com/article.asp?article=9637&p=2

 

 

[J.T.]

Thanks but that's not relevant to me. My NAS is not password protected and the software can access it just fine. The log on icon is greyed out even.

 

My issue is that every reboot, Retrospect seems to think the NAS is not available anymore even though it is. In the list of sources I see a new NAS on the same G: drive and when I select that one, it is ready to go again.

 

Perhaps I can e-mail my screenshot somewhere to show you what I mean? It's weird behaviour because Retrospect is listing my NAS now 6 times, 5 of which are greyed out and don't work. All on the same G: drive.

[Mayoff]

My NAS is not password protected and the software can access it just fine

 

If "the software" is Retrospect and it "can access it just fine" then you wouldn't be posting a question in the forum about Retrospect having so much trouble.

 

I gave you a link to details about configuring Retrospect so that it can authenticate to your NAS because I believe the problem you are having is because permissions or lack of permissions could be causing the problem. If you can setup the NAS with a password, then you should do that. It may fix your problem.

 

The Login item is greyed out because you are probably highlighting one of the bogus ghost images for the disk and not the active icon for the disk.

Edited May 15, 2009 by Guest

[J.T.]

Well, let me rephrase it then. Since the other problems were ironed out, Retrospect is working fine, it can even access the open-access NAS.

 

But the moment I reboot, the NAS disk on the G: drive that is saved in my script becomes a "ghost" one, to use your words, and Retrospect can no longer read from the NAS on G:. However, if I pick the new, same-name NAS also on G: from the list below the one that became a ghost one, it works again.

 

It can run a back-up perfectly fine, on a freshly select NAS drive.

 

It can not run a back-up on a NAS drive which was saved in the script yesterday, even when the NAS disk is on the same G: drive, this NAS drive is not password protected and nothing else has changed. Windows Explorer can also read and write to this G: NAS drive without fail.

 

Because Retrospect can read a freshly selected NAS drive and use it in a back-up script which completes successfully, I personally think it is not an authentication issue.

 

Note that Iomega Backup Pro or whatever it was called could access this drive without creating ghost listings or requiring authentication.

 

As my script can in fact read from the NAS successfully I'd like to explore other avenues rather than enforcing authentication for all the PCs here that need access to this frequently used NAS.

 

Do you perhaps have any other suggestions?

 

Thanks for your assistance!

[J.T.]

Hi,

 

Any ideas on this?

 

I still have to re-select the NAS every day.

 

Also, the old Iomega software used to just sync files that had changed, rather than a full snapshot. This allowed us to do 2-hourly back-ups to an on-site disk A and then Mondays to disk B for off-site and Fridays to disk C for off-site.

 

I had now just done the on-site one in EMC. It's writing to it what seems to be a new snapshot every day, approx. twice a day. This has now filled the disk an it's asking for a new one. I'd prefer to just keep updating the files on the one disk. Is there such a sync backup method as oppose to a full snapshot?

[Mayoff]

When doing a backup, Retrospect adds new or changed files. it does not overwrite files.

 

You could try using the duplicate feature, which copies the data in Windows format overwriting old versions with new files, but writing to a NAS may not allow for an accurate incremental copy of just changed files.

Edited May 20, 2009 by Guest

[armaniake]

Hi,

 

You are suggesting "but writing to a NAS may not allow for an accurate incremental copy of just changed files."

 

I'm not clear on this.

 

May I ask why? I'm using the duplicate feature to duplicate my music files from one hard drive to my NAS.

 

Thanks

[rhwalker]

You are suggesting "but writing to a NAS may not allow for an accurate incremental copy of just changed files."

 

I'm not clear on this.

 

May I ask why? I'm using the duplicate feature to duplicate my music files from one hard drive to my NAS.

It's a metadata issue. There is more to a file than just the bits in the sequential file stream. If the NAS doesn't have the same metadata model as the source filesystem, then an accurate copy of the entire bundle of bits that make up the file might not be possible.

 

For example, the NAS might not support the same complete permissions model that the source has, or the NAS might have a different timestamp granularity than the source, or the NAS might have a different ownership (user, group, etc.) model than the source. When the source is compared with the destination, if all of this doesn't match, you don't have an accurate copy.

 

This issue doesn't arise if you use Retrospect for backups (as contrasted with copy / duplicate) because everything for a backup is dumped into Retrospect's database container (the backup set), which properly preserves metadata.

 

Russ

[armaniake]

I see, it makes sense now.

 

Thank you