Zettabyte

PHP benchmark script от Alessandro Torrisi, который вы используете, не очень хорошо работает для современных реалий и быстрого железа.

Попробуйте вот этот, он лучше подходит как для актуального сейчас софта, так и для сравнения разных аппаратных платформ: https://github.com/odan/benchmark-php

У Майкрософта есть собственные SyncToy и RoboCopy, популярная сторонняя - DSynchronize (можно запускать как сервис).

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

/xf "~*.*" "*~.*" "desktop.ini" "Thumbs.db" ".Sync*"

Шифровать умеют, к примеру, CryptSync и Resilio Sync.

У вас широкий спектр вариантов:

• можете использовать специальные решения с проприетарным форматом (Acronis True Image, Norton Ghost, ...);
  
• либо шестнадцатеричный редактор (CI Hex Viewer, WinHex, ...), с помощью которого создадите несжатую посекторную копию диска. Тут предпочтительнее будет чтобы диск был того же объёма, а лучше модели;
  
• если же на диске только файлы (без каких-то привязок - загрузка ОС, установленные программы, ...), то, судя по описанию, ничего не должно помешать их просто скопировать.
  

Hdd упал с небольшой высоты и несильно ударился, был отключен.

Скорость работы замедлилась и появились медленные и битые сектора. Данные уже записанные считываются с большими приостановками но в большинстве считываются.

Не добивайте диск тестами чтения! Копируйте (пока можно!) самые важные данные, затем остальное. После этого выводите диск из эксплуатации.
Вообще говоря, вам достаточно сильно повезло - играйте в лотерею или наоборот, не играйте (т.к. удача ушла сюда).

1 Что могло сломаться?

Головы наверняка повреждены ("ослабли") и скорее всего, постепенно деградируют окончательно. С определённой вероятностью они могут запилить и поверхность.

Текст вопроса большой, но remap и прочее - не для вашего случая. Это механизмы для скрытия минимальных дефектов, вызванных износом, либо неидеальностью производственного процесса. У вас - физическое повреждение.
Зелёнкой нельзя вылечить перелом и сотрясение мозга.

Можно отключить часть из них? В Интернете пишут запись на дисках происходит одновременно на все поверхности. Но удар был слабым и вообще странно что весь диск посыпался.

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

Да, запись идёт по всем головам, иное - неразумно хотя бы в плане скорости.
К тому же блок головок - это жёсткая конструкция (как устроен жёсткий диск). По этой же причине и повреждения могут быть обширными - если из-за механического воздействия сместилась одна голова, то и на соседние закон сохранения импульса подействовал в той же степени.

Hdd regenerator

И ни в коем случае не пользуйтесь этой профанацией. Сколько данных (изначально спасабельных) было безвозвратно уничтожено вместе с дисками, благодаря сказкам её разработчика о "петлях гистерезиса"!

Если потребуется протестировать диск (не этот, другой), воспользуйтесь лучше R.tester-ом - его функции ориентированы в первую очередь именно на диагностику (безопасную).

Если у вас Outlook Express хранит файлы на том же разделе, куда могут писать ОС и другие программы, то я бы в первую очередь посоветовал выключить компьютер, чтобы удалённый inbox.dbx не был затёрт другими файлами.

Подключите диск к компьютеру с рабочей ОС, скачайте бесплатную программу R.saver и запустите полное сканирование.

Предварительно убедитесь, что никакие программы или ОС не записывают / не будут ничего записывать на раздел, где хранился inbox.dbx, и не сохраняйте ничего на тот раздел сами (в т.ч. архив с программой).

Если речь идёт об ССД, подготовьтесь заранее и не включайте его впустую - команда TRIM может стереть данные безвозвратно. Надо либо действовать быстро, либо отключить её.

Если нужна более подробная инструкция, посмотрите видео про восстановление удалённых файлов, либо напишите тут в комментариях.

Как вариант - контроллер мог перевести флешку в режим "Только для чтения" из-за износа NAND-чипов памяти.
Особенно подобным поведением увлекаются устройства от Transcend.

Сделать дополнительную диагностику вы можете с помощью R.tester-а, это должно дать, как минимум, лучшее представление о том, что случилось.

MamaLuyba,

В соседнем кабинете у нас компы чинят - дал им послушать, сказали, звук не очень

Если вы считаете, что на это заключение можно полагаться, то я бы предполагал физические/механические проблемы с диском.

Если это так и если данные важны, то сейчас вам нужно:

• Забрать диск из соседнего кабинета, где "компы чинят" - при таком раскладе помочь они смогут вряд ли, а вот добить диск окончательно - вполне
  
• Больше его самостоятельно даже не включать, не говоря уже о каких-либо попытках восстановления/ремонта. В случае проблем с головками/поверхностью, каждый запуск имеет все шансы сделать ситуацию хуже, вплоть до обнуления шансов на восстановление.
  
• Обратиться в проверенную компанию, занимающуюся восстановлением данных профессионально. Если раньше у вас подобного опыта не было, вот краткая памятка: восстановление-данных.рф
  

Советы выше вдвойне важны (я бы сказал жизненно критичны), если у вас относительно современный диск Seagate (говоря грубо, объёмом от 500 ГБ - 1 ТБ и более).

Если не находится прямо вообще ничего, то файл мог быть перезаписан. Вероятность этого выше, если с момента удаления прошло много времени и/или диск с удалённым файлом активно использовался.

В первую очередь вам нужно обеспечить полное отсутствие любых операций записи на диск, на котором хранился удалённый бэкап SQL-я.

Скачайте бесплатный R.saver и запустите полное сканирование. Посмотрите что получится найти с его помощью.
Здесь также не сохраняйте архив с программой на тот диск, с которого удалили бэкап.

Если в автоматическом режиме ничего не найдётся, то возможно будет иметь смысл поискать руками, но это отдельная задача.

Также, если речь идёт об SSD, искомый бэкап мог быть удалён командой TRIM (если так, то ситуация становится печальной). Надеясь на то, что это ещё не произошло, не лишним будет отключить ТРИМ.

Скачайте R.saver (бесплатно) и запустите полное сканирование. Не сохраняйте архив на тот диск, с которого пропали данные.

В идеале анализ стоит делать на отдельной машине, предварительно отключив TRIM. Если R.saver не найдёт ничего похожего на пропавшие файлы, то можно начинать отчаиваться.

В целом, на мой взгляд (и если я правильно понял ваше описание), вероятность восстановить данные, к сожалению, низкая:

• Прошло много времени и нужные файлы вполне могли быть просто перезаписаны
  
• Как я понял, вы скачивали дистрибутив(-ы) ОС, затем переустановка - всё это запись новых данных
  
• С учётом того, что у вас ССД, данные мог безвозвратно стереть TRIM
  

Если у вас PyCharm хранит файлы проектов на том же разделе, куда могут писать ОС и другие программы, то я бы в первую очередь посоветовал выключить компьютер, чтобы данные не были перезаписаны другими.

Если вам нужна программа, работающая под Linux, то для поиска удалённой папки воспользуйтесь, например, UFS Explorer Standard Recovery - у неё, как и у более старших ревизий ЮФС Эксплорер, есть версии для Линукс.

Если есть возможность запустить сканирование диска под Windows, например, вынув его из компьютера, поищите удалённую папку бесплатным R.saver.

Предварительно убедитесь, что никакие программы или ОС не записывают / не будут ничего записывать на раздел с файлами PyCharm, и не сохраняйте ничего на него сами (в т.ч. программы для восстановления данных).

Если вам нужна программа для восстановления данных, работающая под Linux, воспользуйтесь, например, UFS Explorer Standard Recovery - у неё, как и у более старших ревизий ЮФС Эксплорер, есть версия для Линукс.

Если есть возможность запустить сканирование диска под Windows, воспользуйтесь бесплатным R.saver.

Предварительно убедитесь, что никакие программы или ОС не записывают / не будут ничего записывать на диск при подключении, и не сохраняйте ничего на него сами (в т.ч. программы для восстановления данных).

Нужен надежный диск.

Я бы выбирал между Hitachi (HGST) и Toshiba.

Ну и теми моделями WD, которые на самом деле Хитачи.

А не проще ли будет отслеживать нажатия на ту или иную кнопку (выбора мессенджера)?
Или вам надо отслеживать только тех, кто гарантированно написал хотя бы одно сообщение вашему сотруднику?

Посмотрите также в сторону Swift Mailer, он такое умеет.
В PHP-проекты интегрируется хорошо, что можно изобрести для связки с написанным на Ruby Jekyll'ом, говорить не возьмусь - не знаком с этой областью.

Насколько я помню, у HP error 226 - это power fault, достаточно общая ошибка, которая может уходить корнями в различные подсистемы.

Но первое, что стоит попробовать - это, если контроллер съёмный, выключить сервер, отключить батарею контроллера, извлечь сам контроллер, протереть его контакты и в обратном порядке вернуть всё на свои места.

Если это не поможет, стоит также копнуть в сторону предохранителей, но я бы уже говорил с поддержкой НР на этом этапе.

Хотим собрать сервер на SAS 12G (прям мечта)

Не то, чтобы прямо ответ на ваш вопрос, но увидев упоминание SAS12G, не смог пройти мимо.

Если вам интересна тема "гонки серверных интерфейсов", посмотрите недлинный пост о SAS3 (12G) и SAS (3.0G). Там на старом контроллере удалось получить 790 МБ/с.