[Busla]

mwz, да вполне классический подход: том с ОС и ПО, том с данными, том с логами.

[mwz]

том с логами »

Не уговорили. Чем логи не устраивает, например, каталог D:\Logs вместо отдельного разадела?

Ещё одна классика — отдельный раздел под файл подкачки.

И хотелось бы услышать, "в чём смысл жизни", у топикстартера.

[Busla]

Чем логи не устраивает, например, каталог D:\Logs вместо отдельного разадела? »

тем, что они могут "отнять" место у основных данных
нередко сбой одной системы порождает массу логов в соседних, а иногда обновление ПО подразумевает изменение структуры данных и тоже порождает нетипичные объёмы логов

[mwz]

и тоже порождает нетипичные объёмы логов »

И если основной объём диска уменьшить, а из освободившейся части сделать для них отдельный диск, то они его не смогут этот диск переполнить, и им придётся обрезаться с новым логом типа "Unexpected error 0x70 from WriteFile on D:\folders\{00008086-058D-4C89-AB57-A7F909A47AB4}\WORKST.C.VolumeCluster.4096.dat: There is not enough space on the disk." — и дополнительно место у основных данных не будет отнято?

PS
Это я со своего серверочка списал. При том, что места вагон.

[Busla]

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

Искренне считаю что "Unexpected error" в подобной ситуации - это ошибка в ПО.

[mwz]

то "вагон места" для данных как раз позволяет »

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

это ошибка в ПО »

Или в базе, с которым оно работает (это ошибка только при завершении прореживания бэкапов в WHS (том, что на базе WS2003). Её не было ни разу более 5 лет, с момента последней переустановки сервера, — и появилась только пару недель назад после переустановки одного из компьютеров, с которых забираются бэкапы. Ничего нового не ставилось; вот пытаюсь с ней разобраться малой кровью, а то настолько влом преставлять систему и настраивать с нуля www- и ftp-серверы).

[mwz]

Busla, ну вот, поделился вскользь проблемой с "Unexpected error 0x70", посмотрел на запись об ошибке "со стороны", услышал полезное мнение — и решил-таки её.

Скрытый текст

Как и надеялся, проблема оказалась не в ПО (ну, скажем так — может она там тоже есть, но за годы проявилась лишь в этой ситуации), а в самой базе. Создал её резервную копию, а затем на исходной пожертвовал несколькими промежуточными бэкапами, удалив записи (не сами бэкапы), относящиеся к проблемному периоду этого компьютера, в т.ч. ту, которая вызывала ошибку. И запустил "Repair Database".

До удаления записей эта операция проходила очень быстро, с сообщением "Проблем нет". Здесь же работа пошла посерьёзней, заметно дольше, с финальным сообщением "Не удалось восстановить часть бэкапов", относящимся только к удалённым вручную сведениям. И после этого всё заработало без проблем, а размер базы сжался чуть не на полтерабайта, причём не только за счёт очистки от неактуальных бэкапов: при возникновении проблемы обработка базы происходила не полностью, и дедупликация работала не в полном мере — раздув тем самым объём базы.

Поиск в интернете как по этой, так и по связанной ошибке (которую я не привёл как менее информативную) полезной информации не дал, хотя сообщения о таких ошибках, и не одно, нашлись сразу.

[НеУбейСистему]

слейте инфу, пересоздайте в чем проблема? зачем писать?