Подскажите где взять место под backup

А как бекапить базу где данные скомпрессиваны?

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

Да и бинлоги эти окажутся в разы больше полного бекапа.

Да, и это означает, что надо копить все что загрузил в течении 3 месяцев.

Какие бинлоги? Экспортировать из базы данные за день в какой-то структурированный формат, как их еще из большой базы достать-то. Если это sql база, то можно экспортировать в sql формат. Бэкапы чтоли не делали?

Облачное хранилище http://selectel.ru/services/cloud-storage

Хранение данных - 3 руб за Гб/месяц или 4.5 руб. за Тб/час

Сеть (исходящий трафик) - 0.8 руб. за Гб

Сеть (входящий трафик) - бесплатно

У adman.com за 1 гб - 1 рубль. 300 гб - 300 рублей. Сам пользуюсь, доволен. Делается по запросу в тех поддержку.

Что тут думать!?

Однозначно Хедзнер.

25уе в месяц, полноценный сервак 500гб диск 4гб рам (с их "аукциона", они всегда в ниличие.) +100гб бэкапа на отдельном сервере бекапа. 5тб внешнего трафа включено. внутренний на дополнительный бэкап не учитывается. Установка бесплатно в течение часа.

Mutabors, hetzner не панацея.

Хранилище будет надежнее и быстрее, чем этот древний сервер с полумертвыми винтами.

http://dev.mysql.com/doc/refman/5.5/en/backup-methods.html - раздел Making Incremental Backups by Enabling the Binary Log

В mysql ничего экспортировать не надо. Он сам именно это и делает, пишет бинлог.

Так вот, бинлог за 3 месяца в зависимости от интенсивности апдейтов может восстанавливаться 1 неделю, а может 1 месяц.

Так это не для бэкапа, а для репликации, в нем будут все повторяющиеся апдейты присутствовать, зачем их в бэкап ложить? Конечно такое будет долго рековэриться, все апдейты за все существование проекта нужно будет выполнить за раз.

Это и для бекапа, и для репликации.

Именно так в mysql делается инкрементальный бекап.

Читайте там по ссылке: These binary logs are the incremental backup

Причем в mysql 5.6, например, добавили режим работы сервера-реплики, когда он ничего кроме записи бинлогов не делает - это чтобы бекапы сами по себе писались в realtime на маломощном сервере каком-нибудь.

А вы предлагаете вручную делать select * from table where update_time > "вчера" для каждой таблицы? :)

Это вы предлагаете бинлог для бэкапов приспособить. А я не предлагаю, можете наступать на эти грабли сколько влезет.

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

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