sysdba22,

опять берем калькулятор в руки. 8 часов это 28800 секунд,
следовательно, "разархивация" у вас происходит со скоростью 3 мегабайта в секунду. Чего так медленно?
Дохлый проц? на диске выключен кэш записи?

sysdba22,

ерунда какая-то. Берем мой ДВЕНАДЦАТИЛЕТНЕЙ давности тест restore. Допустим, там лучший результат - 9 минут для базы размером 3,9 гиг.
Получаем 7 мегабайт в секунду. На древнем процессоре Phenom II 720, и HDD SATA2 дисках.
Ну ладно, слишком это старое.
Тогда берем базу tpcc, бэкап 22 гиг, ресторенная д.б. где-то 25 гиг.
Ресторим на FB 3.0.7. С абсолютно дефолтным конфигом. Не, у меня temp по умолчанию на ssd, поэтому я его специально перенес на hdd. А то вдруг у вас ssd нет.
Разумеется, бэкап на одном hdd диске, ресторится база на другой hdd, иначе будет раза в полтора медленее (На ssd можно так не делать).
Все это десктоп, диски sata по 2 терабайта, проц amd ryzen 3700x.
Получаем -
рестор данных - 651 секунда (22 гиг данных, 33мб в секунду)
при создании индексов обмен с диском – 125мб сек.
всего секунд, на весь рестор – 857. на создание индексов ушло 206 секунд.
Итого, база в 25 гиг заресторилась за 14 минут, со скоростью в среднем 29мб сек.

Т.е. на моем ДЕСКТОПЕ с десктопными hdd-дисками ваша база ресторилась бы примерно 45 минут.

Вопрос - зачем так мучиться с 82 гиг базой? Не проще запустить хотя бы CrystalDiskMark, попечалиться, и обзавестись ну хоть какими-то нормальными дисками?
Не, можно, конечно, всё сделать и на rapspbery pi, с базой на флэшке, и бэкапить-ресторить по 2-5 суток. Только зачем?

sysdba22за двадцать последних лет, на базах 100+ Гб, никогда не видел таких скоростей. На каком только железе не пробовали. И HDD, и SSD, и RAID 10. Восстановление самих данных не проблема. Но, потом начинаются индексы и все, приплыли.
По пунктам.
Создание индексов при restore (и вообще)
Индексы создаются через сортировку. Т.е. то же самое что PLAN SORT в запросах, разве что в файл попадает только ключ и номер записи, а потом данные не клиенту выдаются, а записываются в базу в виде индекса.
Поэтому скорость создания индексов, точно так же, как и у запросов с сортировкой, зависит от скорости диска, куда указывает temp. Ну и от скорости диска "приемника" (т.е. с базой).
В базу обычно пишется больше, чем читается из бэкапа или файла сортировки. Поэтому скорость всего процесса ограничена скоростью записи.
Скорость записи на уровне 3 мб/сек очень сильно напоминает какую угодно дисковую систему с выключенным кэшированием записи (если посмотреть в перфмон или еще куда это будет выглядеть как ровная линия, без "пилы или синусоиды").

Про "20 лет" и "базы 100+гб"
Два года назад я написал статью про "определение скорости диска при помощи бэкапа"
http://www.ibase.ru/backupspeed3/
Я пересмотрел данные где-то по сотне серверов, которые мы обслуживаем (это не все).
Это реальные сервера с разными базами.
Вырезал данные где-то 30ти наиболее интересных. И свел в табличку.
Да, в статье только про бэкапы, но рестор обычно в 2-3 раза дольше бэкапа, так что оценить можно.
Так вот, "463 гигабайта за 11 часов" - это уже медленно. Медленно с точки зрения БОЛЬШИНСТВА серверов.

Ну или вот примеры тестового рестора с реальных серверов, все в разных компаниях (имена баз и некоторые даты скрыты)
- Restore '......fdb' 74.7 GiB done successfully at 2021-06-16 ...., taking 01h:22m:19s.368.
- Restore '......fdb' 60.8 GiB done successfully at ....., taking 01h:37m:59s.216.
- Restore '......fdb' 117.1 GiB done successfully at 2021-06-16 ....., taking 05h:24m:22s.951
(тут да, медленновато как-то. Но это не 80 гиг за 8 часов, а 117 за 5.)
- Restore '......fdb' 74.7 GiB done successfully at 2021-06-16 ...., taking 01h:21m:16s.771.
- Restore '......fdb' 159.6 GiB done successfully at 2021-06-16 ...., taking 01h:56m:01s.456.

Надо сказать, что как раз для баз 100+гб у нас тестовый рестор обычно не делается, но обязательно включена репликация, и делаются бэкапы.
И тут понятно, что если база в 400 гиг бэкапится 3 часа, и это действительно быстро, то рестор ее будет идти не меньше 8 часов, а это слишком долгий простой, и быстрее восстановить базу из реплики.

В общем, рестор даже всей БД (а не только индексов) 80 гиг за 8 часов - это крайне медленно. Как я уже сказал, это либо дико медленный проц, либо дико медленный диск, или temp настроен "не туда", или, кстати, это линукс с включенным barrier на диске.
Свой десктоп на протяжении лет 15-ти я привожу в пример не зря - если у вас сервер медленнее десктопа, то что это за сервер?
(тем более что у меня raid 10 никогда не было, а ssd появились только полгода назад).

И про CrystalDiskMark я уже писал - так трудно запустить и проверить? Сравнительных данных полно.
sysdba22ну, не знали мы до вчерашнего дня про лайф хак ALTER INDEX ... ACTIVE на активном индексе.
про эту "фишку" уже как минимум лет 15 известно, и про нее как минимум я писал в разных местах.