Jump to content

Problems with restoring entire source volume


Recommended Posts

Today I tried and failed to restore a client's individual user folder using the "Restore entire source volume or favorite folder..." option. The client was running client version 9.2.102 on OS 10.7.4. The restore would consistently get stuck at the deleting files phase. ("Stuck" means that Retrospect was spinning its wheels for 15 minutes or more.) Aside from whatever may have been in this user's Library folder, the rest of the folder was essentially empty.

 

After three attempts, I gave up, and successfully performed the restore using the "Restore from a backup/replace corresponding files" option.

 

Has anybody else experienced this problem?

Link to comment
Share on other sites

I trialed version 9 recently, and had a similar problem when trying to use the 'restore on demand' feature (Retrospect getting stuck, with CPU usage high but seemingly little actually being done).

 

I can't recall whether the same occurred with restores initiated by the server, however.

Link to comment
Share on other sites

  • 1 month later...

retrospect restores can take a very long time. retrospect's so-called progress indicators are in my opinion bad in the sense that they give you a false sense of confidence in their ability to represent the state of the backup.

 

in my experience, a retro restore typically has the following experience from a user perspective:

 

you start a backup, it proceeds more or less according to your expectations but takes about 20x longer than you think it reasonably should (based on rough estimate of speeds reading/writing from disks, etc.). still, during this time you are seeing progress in terms of a "thermometer" that is gradually advancing, a counter showing elapsed time and perhaps even an estimate of remaining time. ok, as then as this phase apparently is drawing to a close, right near the (apparent) end, the progess will stop changing (usually showing that there are only a small number of files remaining). at this point there are no further progress indications for a very long time except for a "pulsing" of the thermometer - like maybe 10x as long as the entire first phase was originally estimated to take (this could easily top multiple tens of hours, in my experience). then eventually, after a very very long time, this phase finally completes and another phase starts with the appearance of the moving thermometer again, perhaps briefly restoring your confidence in things. but then yet again, the progress indications freeze near the apparent end of the phase and again, you're treated to an inordinately long wait with only a pulsing thermometer and in (incorrect) status indicated in the progress window. then things will finally finally complete.

 

the above scenario has been true (and documented and complained about by me in past versions of forums like this) in all versions going back 10+ years (no, that is not an exaggeration). it's a terrible user experience. compounded by the fact that a "typical"(?) user does frequent backups but only infrequent restores and restores are often happening under "duress" - i.e. when some drive has failed and you're trying to get a machine up and working or a drive back online.

 

i don't understand why this doesn't get attention from developers. first in my opinion, restore's shouldn't take this long. ... and if it is going to take an "unreasonably" long time like this due to some design limitations of the program, then at the very least, there should be a working progress indicator. it is in my view worse than useless to have a progress indicator that only represents a small part of the process and thereby gives you false/misleading expectations about when you can expect to be done. it even worse to have this bug where there is a progress incidation on the screen that freezes in a particular state such that for a very very very long time, it is mis-representing the state of the system (in terms of what specific file is being processed, the percent complete, time remaining, etc.).

 

i can only speculate about what is happening internally - it may be as follows (please correct this if i'm wrong):

 

1. copying of files - this is tracked somewhat accurately by progress indicators - except that the indicators don't say that they're only tracking this step and not the whole process.

2. changing of permissions - this step seems to not be tracked and as i indicated, there seems to be a bug where the progress indicators from the prior step are "frozen" near the end.

3. verification of files - progress tracked similar to step 1.

4. verification of permissions? - progress not tracked similar to step 2 with stale indicators left over from the end of step 3.

Link to comment
Share on other sites

Aside from whatever may have been in this user's Library folder, the rest of the folder was essentially empty.

 

This is like saying "Aside from the pile of rocks in the truck bed, there are essentially no rocks in the truck."

 

The Library folder in my home folder contains around 750,000 files. During a Restore, Retrospect would need to look at each and every one of those, a task which might reasonably (without knowing the networking situation involving this client/engine pair) take longer then 15 minutes.

 

This is not to discount David's excellent point(s) regarding interface. Heck, I'd just be happier if the Operations Log provided more information throughout the various possible activities of the program, but its behavior is unchanged for versions going back 20+ years.

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...