L_argoЯ всего лишь предположил, что перед началом бекапа сервер резервирует место, как для несжатого бекапа.
И это вполне логично, т.к. база может быть из одной таблички, в кот. лежит mpeg4. И тогда никакого сжатия не будет.Это нелогично, потому что тогда сервер не сможет сделать бакап, который мог бы сделать.
И практикой это подтверждается, о чём вам уже несколько раз написали.
L_argoНе уверен, что сервер может предугадать будущий упакованный размер.Да, не может даже теоретически, даже сделав бакап "без записи", потому что во время бакапа база может изменяться, расти, и любая оценка т.о. становится бесполезной. Скервер может начать бакап утром, а к вечеру, когда он завершится, в базу добавится ещё террабайт. И этот дополнительный террабайт тоже в итоге окажется в этом бакапе, начатом утром.

alexeyvgL_argoЯ всего лишь предположил, что перед началом бекапа сервер резервирует место, как для несжатого бекапа.
И это вполне логично, т.к. база может быть из одной таблички, в кот. лежит mpeg4. И тогда никакого сжатия не будет.Это нелогично, потому что тогда сервер не сможет сделать бакап, который мог бы сделать.
И практикой это подтверждается, о чём вам уже несколько раз написали.Забыл добавить - ещё и потому, что такая оценка будет неправильной, потому что база может меняться во время бакапа.

Т.о. получаем две ошибки:
1) не делаем бакап, хотя места хватает
2) даже если место зарезервировали "без сжатия", всё равно места может не хватить, и предыдущая жертва была напрасной