Progress during backup shows ETA which is not the correct term for the Estimated Time Remaining

Output of restic version

restic 0.18.0 compiled with go1.24.1 on linux/amd64

What backend/service did you use to store the repository?

sftp

Problem description / Steps to reproduce

run restic backup and note the progress display does not identify that the first time is the elapsed time (ET) and shows the last time as ETA instead of ETR (more in actual behavior section)

Expected behavior

Minimum Change

I would like at a minimum to change ETA to ETR because it uses a standard time format which can be confusing. I might see ETA 10:12:33 and think that the backup will finish at 12 minutes after 10 oclock. But in reality it is showing that it will take more than ten hours from now to finish.

Compact and Consistent Progress

A more compact and informative progress line is possible. Loading indices uses

[0:13] 100.00% 366 / 366 index files loaded

Note how this uses the "files loaded / files total" notation. Extending this to backup progress we get:

[2:26:52] 32.59% 134518 / 819333 files done, 5.491 TiB / 16.849 TiB, 0 errors ETR 4:38:11 ETA 22:15:44

Note that combining time elapsed and time remaining is not congruent with file completed/total. I also left the first two fields (ET and % complete) where they are as they will apply to progress for every operation where restic outputs progress. I am not sure about using the word "done", both whether it is necessary or if it should be after the word files, like it is in "index files loaded".

Alternative versions

Assume that the user understands that "x of y" means "x completed of y total". The / also works instead of "of" but it is also an indicator of division.

[2:26:52] 32.59% 134518 of 819333 files, 5.491 TiB of 16.849 TiB, 0 errors ETR 4:38:11 ETA 22:15:44

Possible ways to shorten the progress string:

If / is used it could be compressed to leave out the spaces. The space in the size could also be left out to shorted the progress line, which is common in many places where size notation is used in the industry. In addition if the goal is to keep the progress line in 80 characters times could be shorted to leave out the seconds, at least for ETA and ETR (which are not accurate enough for seconds to matter). Commas can also be left out. They are not consistent as is appearing after TiB but not after N errors N. In addition the tag appears after the value in most cases, but not for ETA where the time follows the tag. The quantifier can be omitted for the completed size if it is the same as the total size.

[2:26:52] 32.59% 134518/819333 files 5.491/16.849 TiB 0 errors ETR 04:38 ETA 22:15

I believe that using "tag: N" in all cases is efficient and very common. Parsing 10 errors ETA does require slightly more work by the user.

[2:26:52] 32.59% files: 134518/819333 size: 5.491/16.849 TiB errors: 0 ETR: 04:38 ETA: 22:15

I still find separating elapsed time from time remaining slightly inconsistent, but I accept as being consistent in the overall progress scheme of restic where all progress is shown as

[ET] N% <required info> <extended/optional info>

I realize that I have provided a lot of possibilities. I am a developer and I just want the product to continue to get better.

Actual behavior

A real progress line is:

[2:26:52] 32.59% 134518 files 5.491 TiB, total 819333 files 16.849 TiB, 0 errors ETA 4:38:11

I want to mention two items

1. the elapsed time is in brackets at the beginning of the line, vs the remaining time at the end of the line has a label and no brackets. This is inconsistent. It also requires that the user realize that the first time in brackets is elapsed time.
2. the estimated remaining time is incorrectly labeled ETA (estimated time of arrival) when it should be ETR if using the acronym for estimated time remaining.

Do you have any idea what may have caused this?

The cause is just a simple term swap in the program for the ETA vs ETR.

I will mention that based on all my thinking about this and all the examples that I provided above that a single function could show progress in all cases using something like this python function signature:

def show_progress(et, progress, fields):

where fields is a list of thruples (tag, value1, value2) with valuee being None if there is only one value such as ETA. The field representation could be extended with a boolean to specify tag first or tag after, and a separator for value1 and value2 to make the function even more generic.

Did restic help you today? Did it make you happy in any way?

restic is great!

It is fast, efficient, conserves space and relatively easy to use. I am very glad that I found it.

I do wish the term for a given backup instance was not called snapshot. That conflicts with the term snapshot in file systems. I do understand the there is some correspondence. But, I have been using other backup systems for decades and the notion of a backup set with a name, a definition, a schedule, etc. is just ingrained at this point.