hint000

1) (+) дубликат носителя можно увезти в другое место и положить в сейф, тогда теоретически спасаем данные от пожара, ограбления, атаки шифровальщика и многих других угроз;

2) (+) по сравнению с (1) удобно хранить (на носителе большого объёма) и передавать по сети, (-) но не обеспечивает физическую изоляцию от угроз;

3) (-) в некоторых случаях сохраняется не вся метаинформация, содержащаяся в файловой системе; при повреждении файловой системы могут быть скопированы не все файлы или файлы могут быть скопированы с повреждениями, не позволяющими дальнейшее восстановление информации с копии; (1) и (2) могут дать больше возможностей восстановления повреждённых данных; если на исходном носителе была скрытая информация (например, скрытый криптораздел\криптоконтейнер), то она не будет скопирована; (+) однако, (3) позволяет в процессе копирования (и верификации) обнаружить факт повреждения файловой системы, чего не позволяют (1) и (2).

Для решения задачи пишется скрипт размером 2-3 строчки (при желании можно и в одну строчку).
Это простое копирование файлов и папок по списку. Список лучше хранить в отдельном файле.
Под виндой можно использовать robocopy для большей эффективности.
Под Линуксом rsync.

Если для восстановления требуется больше суток, то, видимо, и для создания копии потребуется примерно столько же времени. Внешний-то диск имеет USB3 или старый медленный USB2?

1. Следовало уточнить в вопросе, что резервное копирование делаете tar'ом, потому что есть сто других способов.
2. Да, можно; tar ничего не знает о способах разметки диска, ему пофиг, он работает на более высоком уровне - с файловой системой, а не с блочным устройством. Так что до восстановления tar'ом раздел должен уже иметь файловую систему (т.е. должен быть отформатирован, если этот раздел был создан заново утилитой разметки диска).
3. Что там насчёт загрузочного раздела? О нём нужно думать отдельно.

Или, например, Total Commander (или Acronis True Image) при создании резервной копии и так заботится о корректности бэкапа?

Нет, верификация занимает время, если бы она делалась автоматически при копировании каждого файла, то копирование происходило бы медленнее, а этого никому не хочется. Поэтому верификация - отдельный процесс, только по необходимости.
Не знаю как Total, а его основной конкурент FAR умеет сравнивать папки по содержимому файлов; может быть и Total так умеет.

Но это сиюминутное решение, после бэкапа сверить, пока оригинал доступен. Может потребоваться сверка, когда оригинала под рукой нет. Например, рабочий диск умер, есть два бэкапа, но содержимое одного файла отличается между этими двумя бэкапами; как понять, какой из них правильный, а какой косячный? Для этого можно вычислять контрольные суммы или хэш-суммы файлов. Один из самых популярных (уточню: для повседневной верификации) хэш-алгоритмов - это MD5. На Линуксе команда md5sum из-коробки способна обсчитать все файлы в папке, а также сверить с хэшами, ранее записанными в текстовый файл. На винде с этим похуже, легко нагуглить команду для вычисления MD5 отдельного файла, но не всех файлов в папке. Приходится устанавливать дополнительный софт, например этот: www.nirsoft.net/utils/hash_my_files.html Или писать свой скрипт.

Считаете хэши от оригинальных файлов, записываете хэши в тектовый файл, бэкапите этот тектовый файл вместе со всем остальным. Когда нужно сверить - считаете хэши от бэкапных файлов и сверяете с записанными в файле.

https://ru.wikipedia.org/wiki/HP_Data_Protector
Дорого. Мощно.

Можно глянуть на https://en.wikipedia.org/wiki/Backup_Exec
сто лет назад работал с ним, но понятия не имею, в каком состоянии этот продукт сейчас. В вики пишут, вроде есть версия за 2020 год.

Рекомендую переносить только конфиги и данные.
Заново установить систему и нужные пакеты - совсем не долго, а после установки подсунете готовые конфиги, так что настраивать почти и не нужно.

В первом случае (за 40 минут) в сети происходит примерно такой процесс:
Во втором случае (за 12 часов) примерно такой: Ничего удивительного нет. Это так и работает.