Progress Indications During Restore

[davidduff]

i'm using retro 8. like almost everyone probably, i do a lot more backups than restores. recently, i had a hardware failure and so i am in the midst of a restore and taking the downtime as an opportunity to offer feedback that i have offered periodically over the years, stretching back 10 years or more to retrospect 6.x and earlier.

 

feedback and progress tracking is honestly TERRIBLE in retrospect from the perspective of someone doing a restore. first, you get a progress indicator similar to what you see when doing backups. you also get an estimated time to completion. for this restore of what i consider to be a fairly typical mac laptop (with a modest-size photo library and a smallish music library) this is about 250GB and 1.6M files. the "first phase" of restore took about 6 hrs. progress indication during this phase was somewhat along the lines of what i'm used to seeing with backups. the estimated completion time would fluctuate somewhat, but that is to be expected - it is an estimate and it is updated based on recent progress.

 

this has now been followed by another phase where the program status says "Completing restore....", the progress indicator is a stationary blue candy cane, and there is no estimate of time, # of files, or amount of data remaining. the program still shows a "Performance" value of 1GB/min, but i'm 99% certain that this number is simply the last performance estimate from phase I and has nothing to do with anything the program is doing during the current phase because a) the number has not updated at all during the time i've been watching and if it were processing at 1GB/min, it should be done by now.

 

 

i've been in this state for 5-6 hours now. i have no way of knowing if the program has crashed, if it has encountered read errors or write errors on one of the disks, etc. i consider this to be behavior very unfriendly to the user/operator. i have absolutely no indication whatsoever of whether this is going to complete in 5 minutes, 5 hours, 5 days, or not at all. this is not "reasonable" behavior for any kind of serious program intended to be used for real tasks.

 

specifically, i suggest the folliowing improvements:

 

1. when doing a retrospect operation that has multiple phases, there should be some kind of "uber-progress bar" that shows what phase i'm in, what phases have been completed (including the time that they took) and what phases remain (including estimates of time, # of files, # of bytes remaining, when possible). this is in addition to the existing contents of the "overview" panel.

 

2. all the details mentioned above for each major phase (elapsted time, bytes per second, etc.) should go in the log file. current logging of elapsed times and rates is lacking in useable details.

 

3. the progress reporting should be fixed across the board so that that bogus numbers are never left up in the "Details area" of the status summary. currently, as a user, at any given time, when i glance at retrospect's activities window and look at the summary pane, the "performance" number i see there may or may not have anything whatsoever to do with what the program is currently doing. this is a bug.

 

4. progress reporting for whatever you call the phase of a restore operation where the program status says "Completing restore..." should be fixed so that there is at least some signs of life from the program, and preferably, a real progress bar and estimates of time/files/bytes remaining.

[Lennart_T]

That request has been high on the wish-list for years.

 

What happens, is that Retrospect is setting the file/folder permissions. As such is should be faster than the restore itself. But if you have a lot of small files, it can take almost as long time.

[davidduff]

That request has been high on the wish-list for years.

 

What happens, is that Retrospect is setting the file/folder permissions. As such is should be faster than the restore itself. But if you have a lot of small files, it can take almost as long time.

 

yes, i have inferred that what's happening is that retrospect first copies all the files, then updates the permissions and other file system metadata associated with each. i don't know whether this is accurate or not. i was careful to avoid trying to do any reverse-engineering of the program in my bug-report/feature-request above. assuming that it as you say and as i had speculated, however, i see absolutely no reason why the program couldn't put up a progress indicator for the second phase based on the number of files completed and the number remaining. both of these should be known by the program as it goes along.

 

it may be that i've let my annoyance regarding the terrible user experience of the second phase influence me, but i'm pretty sure that i've observed the second phase taking longer than than the first phase. the restore that i'm waiting on right now has taken 13:35:00 so far, and i'm pretty sure it was "Completing restore..." when i first checked this morning >7 hours ago, so that means it's more than half the time so far - and its still completing.

 

of course, if there had been anything useful written to the logs, i wouldn't have to speculate about this. the logs say only the time that the backup was started. they don't say a) how long the scan phase took, how many files/bytes were identified for restore during the scan c) how long the copy phase took or whether it was completed, nor d) what time the final metadata update phase started. all of those would be very useful to me as a user of the program.

 

you'll also notice that i'm not complaining about how slow the program is, though i could write an entire separate rant on that subject as well.