mayton2019

Я-бы поделил файлы word,exel,pdf ,txt на группы.

1) Aрхивы docx, xlsx. Как выше заметил один джентльмен их можно проверить любой
утилитой которая умеет читать zip и делать zip -t (test) с выводом статуса в errorlevel.
Автоматизировать можно либо bash либо python скриптом.

Если архив целый (контрольные суммы совпали) то и документ почти 100% не поврежден.

2) Офисные документы старого формата (doc/xls). Здесь я-бы парсил их через apache POI
(это java библиотека). Это разработка. Но простая. На 1 story point. Я думаю
любой первокурсник напишет.

3) Adobe документы. Масса вариантов. Есть автоматизация с помощью bash/python
и консольными тулзами. Я перечислю тулзы которые есть под линукс и которые читают
pdf.

- pdfimages
- pdfextract
- pdftoppm

Напомню что почти все они должны в случае неуспеха генерировать статус код не нулевой.
Это будет критерий проверки.

4) Прочие текстовые документы. Неструктурированные. Я тут честно не знаю как их проверять.
Но допустим если они содержат текст в кодировке win-1251 то любой криптохакер
с cryptohack вам быстро напишет скриптик для проверки что гистограмма или биграмма
соотвествует примерно тексту и национальным признакам. Если файл будет в нулях
или в рандомном шуме то какой-то критерий не сработает. Здесь надо подумать
и просто глазами посмотреть на эти документы. Возможно большая часть из них
это бланки - и тогда надо чекать наличие просто каких-то шаблонов.

На сервере свойства файла тоже хранятся в файловой системе или в БД или по разному в зависимости от того как настроен сервер?

HTTP протокол вообще не оперирует понятием "файл". Он обычно делает responce который может содержать
octet-stream определенной длины. Или неизвестной длины. Этот-же Responce может хранить в себе сет атрибутов. Таких как ETag,
Age, Accept-Range... e.t.c.

Поэтому процесс скачивания чего-либо с интернета - это квест. Чтобы решить этот квест надо ответить на
вопросы - какие атрибуты нам вернул HTTP responce. И какой клиент для скачивания был использован.
Например клиентом может быть не браузер а Curl, Wget, Postman, *Downloader, Скрипт на Python
и многое-многое другое. И все они действуют по разному. Каждый - по своему алгоритму как сделали
создатели этих утилит.

Сами файловые системы тоже отличаются по качеству хранения атрибутов. Например NTFS может приклеивать
к файлу большое количество атрибутов (ACL, Подписи от антивирусов) а файловая система FAT32 имеет
только несколько дат и фиксированное количество легаси атрибутов которые остались еще со времен MS-DOS.
Поэтому чисто приколовшись можно копировать файлы с NTFS в FAT32 и обратно и таким образом
стерилизовать некоторые из них.

К VPS можно подключить блочное хранилище. Если это у AWS или Azure то там даже есть разные
тарифы и разные гарантии по скорости там и доступу.

Вот один индюк хвастается https://www.youtube.com/watch?v=VnO3Lz7Qr0U
как он ловко подключает себе к Амазонской EC2-шке одно блочное устройство.
Вам только нужно выбрать магнитный драйв и подешевле. Если речь идет о фильмах то тут SSD не важен
и обычный HDD норм пойдет.

UPD:

Да. Такое возможно. Те кто беспокоятся о целостности публикации - обычно прикладывают рядом с файлом
md5, sha1 контрольное число чтобы можно было сразу проверить.

Самовосстановление и докачка в TCP не поддерживается. Можно возобновить докачку с HTTP протокола
в режиме continue (wget -c) но это при условии что веб-хостинг правильно публикует размер файла
и поддерживает range-запросы. Я этим часто пользовался в 2000е во времена DSL модемов когда
сбой соединения разрывал мне закачку фильма или музыки.

А вот если линка была torrent или magnet или eMule то клиет будет ее бесконечно докачивать
пока контрольный код не совпадет с тем который в самом .torrent файле или в линке. Поэтому
торрент линка - это вообще идеальный вариант для закачки.