Ответы:
Вы можете увидеть приблизительный прогресс, используя список оглавления.
Во-первых, получите список объектов TOC для восстановления:
pg_restore -l -f list.toc db.dump
Затем вы можете построчно просматривать список TOC и сравнивать вывод verbose или запроса pg_stat_activity, чтобы увидеть, где в списке TOC находится pg_restore in.
Это всего лишь приблизительная оценка. Во-первых, потому что для загрузки каждого элемента из списка оглавления может потребоваться совсем другое время (например, схемы работают быстро, но загрузка данных больших таблиц и индексов построения не выполняется), и если вы используете -j, у вас будет элемент, который будет восстановлен. до того, как предыдущий закончил. Кроме того, я не уверен на 100%, точно ли pg_restore следует за списком оглавления, если вы не используете -L, но я думаю, что это так.
Действительно для сред Unix / Linux:
Утилита Pipe Viewer (pv) может использоваться для отслеживания хода резервного копирования. PV анимирует вашу оболочку с информацией о прошедшем времени и переданных байтах.
Ниже приведен пример дампа с использованием утилит pv и split для хранения больших файлов дампа небольшими порциями. Может быть удобно перенести его позже в другое место.
# dump the PREDATA in clear text into a .PREDATA.SQL text file
pg_dump -s -o --section=pre-data -n $schemaname $DatabaseConnString | pv | split -d -b $chunksize - $backuppath/$backupfilename".PREDATA.sql"
# dump the POSTDATA in clear text into a .PREDATA.SQL text file
pg_dump -s -o --section=post-data -n $schemaname $DatabaseConnString | pv | split -d -b $chunksize - $backuppath/$backupfilename".POSTDATA.sql"
# dump the DATA into the .DATA.dump compressed (binary) file
pg_dump -Fc --section=data -n $schemaname $DatabaseConnString | pv | split -d -b $chunksize - $backuppath/$backupfilename".DATA.dump"
Недостаток - этот подход не работает, если используется опция pg_dump -Fd (dump to folder).