Jump to content

Urgent: "Completing restore..." for hours!


Recommended Posts

Here's what happened:

 

Machine zeus is an Xserve with the Retrospect server software 6.1.x and an Xserve RAID that serves as a file backup repository (mounted as regular 2.5TB drive named hera on zeus). This machine is running Mac OS X Server 10.4.4

 

Machine eos is a 12" PowerBook G4 attached via GigaBit Ethernet to zeus, this machine runs Mac OS X 10.4.4

 

Machine "apollon" had disk corruption due to some sort of OS crash, etc. The machine is a G5 with two SATA drives that are working as an Apple software RAID 0, i.e. like a single drive of nearly 500GB capacity.

Machine appollon is in FW target drive mode, attached via FW400 to eos.

 

apollon's RAID was wiped, and the entire apollong disk snapshot was supposed to be restored over the network from zeus/hera to eos/apollon, via "replace entire" mode.

 

Surprisingly enough, despite near zero other network activity, this was somewhat slower than expected (just about 120MB/min or about 2MB/s) Not sure if that's the limit of the disk drives, because the network surely should be able to supply data faster than that.

 

Anyway, now after a few days and 1156293 files and 429.1GB worth of data restored, I have this situation:

 

Completing restore... and the file names go by about one per second. You can imagine, if we have to wait about 1156239 seconds, we'd be waiting 321 hours, or about two more weeks for the backup to finish!!!

 

What is Retrospect doing at this point? Just doing checksums or stuff like that? Premissions? Hardlinks?

Why is there no progress bar? I have no idea if it actually has to process all 1156239 files, or just a few hundred "special" files. If I stop and restart the backup, will it do whatever it's doing now, just faster, or will it just realize the files are there and never do whatever it's doing now?

 

Can't really find anything on Dantz/EMC's web site that would shed light on this issue...

 

Greetings,

 

Ronald

 

PS: Unrelated, but for incremental backup over a slow internet link (DSL 384kit/s), is there a way to throttle the speed, such that backups don't always fail with "Net retry" errors?

Link to comment
Share on other sites

It's "Completing restore..." for 11 hours now, and no sign of being done!

 

No messages that say WHAT it's doing (checksums? permissions? links? modification dates/times? ACLs? Finder bits? Forks? sending data to big brother?), no progress bar indicating how LONG it's going to take (the backup progress bar is full, indicating that it should be done, since it already restored all the files).

 

It's just doing something, takes forever, and leaves the user completely in the dark as to what's going on.

 

Is this a way to make us pay for expensive per incident tech support, because obviously, there's nobody that will take a call for free regarding something that clearly is a shortcoming of the software!

 

People are breathing down my neck asking when it's done, and I can just shrug my shoulders looking like a fool!

Link to comment
Share on other sites

That's a common problem. What it does is setting Unix permissions to each and every file.

 

As you have discovered:

 

1) It takes a LONG time.

 

2) You have NO idea how long it will take.

 

 

 

How many files are restored?

 

(11 hours seems too long time to me, but with an extreme amount of files and/or a slow hard drive...)

 

 

 

EDIT:

 

I see now you have 1156293 files. That's a lot of files. I think you just have to wait. Let it sit over night and see what happens.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...