Comments 36
да, действительно использовать logger правильнее, при возможности разберусь с его документацией
про ошибку при наличии pid файла — дело в том, что в конце работы скрипта он удаляется безусловно. т.е. если скрипт доработал до конца, его не будет. таким образом наличие этого файла может свидетельстовавать о 1) процесс идёт 2) скрипт убили 3) во время последнего запуска сервера произошла перезагрузка системы. Или как Вы предлагаете?
про ошибку при наличии pid файла — дело в том, что в конце работы скрипта он удаляется безусловно. т.е. если скрипт доработал до конца, его не будет. таким образом наличие этого файла может свидетельстовавать о 1) процесс идёт 2) скрипт убили 3) во время последнего запуска сервера произошла перезагрузка системы. Или как Вы предлагаете?
Это неплохо, но не смотрели на rsnapshot? Тот же rsync, + perl.
А базы mysql можно бекапить rsync-ом?
>дампить базу по крону нужно на клиентской машине перед тем, как rsync заберёт файлы.
вы имеете в виду изпользующиеся в данный момент .MYD .MYI и .frm файлы MySQL?
если вы имеете ввиду сами файлы баз, то можно, но перед «горячим» копированием нужно «заморозить» состояние базы и сбросить кеши. Т.е. в любом случае одним рсинком не обойтись, нужно предварительно совершить некоторые действия с самой базой. Более подробно все расписано в главе 6 официального мануала.
Что только ни придумают, лишь бы не использовать Bacula
В бакуле есть возможность выполнять скрипты до/после бэкапа. Если места на диске достаточно, то можно все файлы засунуть в архив, скопировать этот архив, затем удалить этот архив. Логичный минус — то что копируется всё скопом, а не выборочно исходя из изменений. Но если места хватает, это даже плюс.
Проверено, работает.
Проверено, работает.
Уже больше 3х месяцев использую duplicity — масса положительных впечатлений.
Поддерживает инкрементальные бекапы, указание списка каталогов и исключений (откуда бекапить), шифрацию получившихся файлов (через gnupg), при этом на сервер бекапов отправляет только изменения.
В итоге работает такая схема:
1. Выделенный бекап сервер, на него есть доступ с основных серверов
2. Каждый сервер по крону ежесуточно запускает инкрементальный бекап, еженедельно — полный
p.s. Получение доступа злоумышленниками к бекап серверу не особо опасно с учётом того, что бекапы зашифрованы.
Поддерживает инкрементальные бекапы, указание списка каталогов и исключений (откуда бекапить), шифрацию получившихся файлов (через gnupg), при этом на сервер бекапов отправляет только изменения.
В итоге работает такая схема:
1. Выделенный бекап сервер, на него есть доступ с основных серверов
2. Каждый сервер по крону ежесуточно запускает инкрементальный бекап, еженедельно — полный
p.s. Получение доступа злоумышленниками к бекап серверу не особо опасно с учётом того, что бекапы зашифрованы.
у duplicity немного другой подход. насколько я знаю, она оперирует только tar файлами, что не всегда удобно (согласен, что с другой стороны не всегда удобно деревья файловой системы в тысячу файлов :) )
Получение доступа злоумышленниками к бекап серверу не особо опасно с учётом того, что бекапы зашифрованы.у них там право только на запись, а не на удаление? я к тому что если сайт дефейснули, не смогут ли злоумышленники просто удалить все бэкапы на удалённом сервере?
Мне намного проще иметь на бекап-сервере десяток больших файлов вместо сотен-тысяч мелких.
По поводу удаления злоумышленниками — в принципе, могут. Хотя никто не мешает по cron'у на backup сервере файлам менять owner'а (через какое-то время после создания) и оставлять возможность только чтения.
Конкретно у меня так бекапятся виртуальные сервера, бекапятся из хост-системы, так что риски значительно ниже (linux + openVZ).
По поводу удаления злоумышленниками — в принципе, могут. Хотя никто не мешает по cron'у на backup сервере файлам менять owner'а (через какое-то время после создания) и оставлять возможность только чтения.
Конкретно у меня так бекапятся виртуальные сервера, бекапятся из хост-системы, так что риски значительно ниже (linux + openVZ).
в обычных условиях это правильно, а у себя как раз продумываю возможность на несколько часов быстро превратить бэкап-сервер в резервный, на который можно моментально перекинуть днс в случае падения продакшн. хотя это всё на уровне сферического отказоустойчивого сервера в вакууме — игры разума.
тоже вариант
тоже вариант
Эффективнее использовать перенос подняв rsync-демон на бакапном сервере и использовать для авторизации rsync password-file, вместо ssh-ключей. Передача данных в таком случае значительно вырастет, особенно актуально при больших объемах передаваемых данных.
duplicity + S3
Пробовали много разных скриптиков бекапа в том числе и fsbackup (больше года на нем сидели), но все это фигня по сравнению с Bacula, попробуйте очень рекомендую
Есть rdiff-backup — делает то же самое, только отлажен и с несколькими плюсами.
dirvish.org делает тоже самое, только еще умеет еще удалять старые бэкапы. правда не уверен, что программа все еще поддерживается.
Прикольно. Пару лет назад я сделал подобное на Perl+rsync. С поддержкой команд на удалённом сервере, чтобы можно было сделать экспорт баз, с параллельным запуском rsync-ов для разных серверов и прочими гибкими настройками. Быкаперы запускаются по крону с разными конфигами, в каждом конфиге описываются сервера, методы доступа к ним, если не дефолтные и количество копий, что надо держать.
Bontmia — работает как часы
Я правильно понимаю, что в случае изменения какого-либо файла в папке latest, он изменится также во всех копиях (в папках названных датами)? То есть папка latest будет отличаться от копий только наличием новых файлов или отсутствием старых?
Вопрос очень хороший, в своё время я сам занимался его изучением. Чтобы на него ответить надо понимать механизм работы rsync по-умолчанию c параметром --delete. man говорит что:
Т.е. при запуске rsync, если параметрами не определено иное, в папке-приёмнике удаляется файл (а так как он существует в папке за предыдущий день — убирается только ссылка на него в папке-приёмнике), а затем под таким же именем создаётся новый файл, в который синхронизируется содержимое из папки-источника.
--delete-before receiver deletes before transfer (default)
--delete-during receiver deletes during xfer, not before
--delete-delay find deletions during, delete after
--delete-after receiver deletes after transfer, not before
Т.е. при запуске rsync, если параметрами не определено иное, в папке-приёмнике удаляется файл (а так как он существует в папке за предыдущий день — убирается только ссылка на него в папке-приёмнике), а затем под таким же именем создаётся новый файл, в который синхронизируется содержимое из папки-источника.
написал предыдущий коммент и понял что он ничего не объясняет :) вернее всё что там написано относится к файлам, которых больше нет в папке-источнике :)
а то о чём Вы спрашиваете, происходит из-за механизма работы хардлинков. при модификации одного из файлов, на диске создаётся его модифицированная копия, т.е. происходит так называемый detach хардлинка.
Допустим есть 2 бэкапа Backup1, Backup 2. Они содержат File1, File2 которые не изменялись и File3, который изменился. Это будет выглядеть так:
а то о чём Вы спрашиваете, происходит из-за механизма работы хардлинков. при модификации одного из файлов, на диске создаётся его модифицированная копия, т.е. происходит так называемый detach хардлинка.
Допустим есть 2 бэкапа Backup1, Backup 2. Они содержат File1, File2 которые не изменялись и File3, который изменился. Это будет выглядеть так:
Проверил. Всё работает отлично. Гениальное в простоте.
Было бы еще хорошо если б какой-нть такой же вариант с базами MySql провернуть, а то они получаются архивированными дампами лежат, хотя меняется пара-тройка записей в одной таблице.
Было бы еще хорошо если б какой-нть такой же вариант с базами MySql провернуть, а то они получаются архивированными дампами лежат, хотя меняется пара-тройка записей в одной таблице.
Sign up to leave a comment.
Скрипт резервного копирования через rsync