Комментарии 16
как вариант.
Хотя мы в своем проекте перестали сохранять данные в каталог проекта. Использовать Amazon S3 или подобное намного удобнее, особенно когда проект большой и количество серваков больше двух.
Хотя мы в своем проекте перестали сохранять данные в каталог проекта. Использовать Amazon S3 или подобное намного удобнее, особенно когда проект большой и количество серваков больше двух.
А Amazon бэкапит сам? Я просто не знаю, но если нет — то значит обиженный админ или просто баг в коде, наподобие недавнего бага может все на амазоне тоже обнулить?
Есть версионность и вот это — docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?MultiFactorAuthenticationDelete.html. Настроить бекап не проблема я думаю. можно дуплицировать один бекет в другой.
Спасибо, интересный руби-стайл вариант для бэкапа перед деплоем. Можно его сразу добавить в тот же capistrano-task. Но для систематических крон-бэкапов все-таки предпочитаю лайв-дамп всего сервера.
Мы раньше так и делали. Но если не жать — то весь сервер может потянуть гигов на 100. Перекачивать это по сети долго и хранить 14 последних бэкапов — накладно. Если жать — то долго жать и долго доставать. А так получается каждый проект в отдельном архивчике максимум на гиг и disaster plan быстро реализуется.
Потому есть вариант хранить на удалёнке только последний бэкап и недельной давности. А локально можно хранить сколько надо при наличии места. Да и gzip не так плох в плане скорости сжатия как bzip.
Данный вариант хорош, но зато если упадёт железо, то придется заново все поднимать, а только потом деплоить, а здесь развернул дамп и готово. Выигрыш в аптайме.
Данный вариант хорош, но зато если упадёт железо, то придется заново все поднимать, а только потом деплоить, а здесь развернул дамп и готово. Выигрыш в аптайме.
Напишите, пожалуйста, статью — как это делать быстро и правильно…
Что конкретно?
Написание Capistrano-tasks railscasts.com/episodes/133-capistrano-tasks
Бэкапы во FreeBSD www.freebsd.org/doc/ru/books/handbook/backup-basics.html
Написание Capistrano-tasks railscasts.com/episodes/133-capistrano-tasks
Бэкапы во FreeBSD www.freebsd.org/doc/ru/books/handbook/backup-basics.html
Например, интересно, есть ли способ:
1. Поставить определённый список пакетов на систему (ubunyu-server)
2. Установить ree + набор gem'ов (без интернета)
3. Развернуть svnserve и репозитории
4. Развернуть web-сервер с базой из бэкапа и запустить его.
Я спрашиваю потомучто мне очень интересно, есть ли инструменты, позволяющие написать простой (не очень сложный и страшный, да пусть даже и так) скрипт, который бы сворачивал всё это дело в бэкап и разворачивал обратно сам, например, в отсутствие администратора (чтобы меня не дёргали из отпуска).
1. Поставить определённый список пакетов на систему (ubunyu-server)
2. Установить ree + набор gem'ов (без интернета)
3. Развернуть svnserve и репозитории
4. Развернуть web-сервер с базой из бэкапа и запустить его.
Я спрашиваю потомучто мне очень интересно, есть ли инструменты, позволяющие написать простой (не очень сложный и страшный, да пусть даже и так) скрипт, который бы сворачивал всё это дело в бэкап и разворачивал обратно сам, например, в отсутствие администратора (чтобы меня не дёргали из отпуска).
Я бы не рекомендовал REE, так как он работает медленнее чем ruby 1.9.2. А на бэкэнде лучше unicorn (плюшки, простота установки, нативность, стриминг в рельсах 3.1), если вы используете passenger.
Если сделать дамп на freebsd (можно по крону), как я описал ранее, то можно готовую систему со всеми установленными пакетами и гемами разворачивать с загрузочного диска. Не знаю, есть ли такая возможность в debian-подобных системах, давно ими не пользуюсь. Как вариант – можно банально за-tar-ить необходимые каталоги.
Если сделать дамп на freebsd (можно по крону), как я описал ранее, то можно готовую систему со всеми установленными пакетами и гемами разворачивать с загрузочного диска. Не знаю, есть ли такая возможность в debian-подобных системах, давно ими не пользуюсь. Как вариант – можно банально за-tar-ить необходимые каталоги.
Спасибо за статью, думаю возьму себе на вооружение этот метод, так как пока отношусь к тем, кто еще не делает бэкапов :)
а rsync всего сервера, не?
и хранить последних 14 бекапов, места занимать будут мало т.к. рсинкатся будут только инкременты.
и хранить последних 14 бекапов, места занимать будут мало т.к. рсинкатся будут только инкременты.
1. СУБД бэкапить rsyncом нельзя — будут коцаные базы при восстановлении.
2. Описываемый gem backup rsync умеет, и при этом получаются тоже только инкременты. Но при этом надо выбирать — или инкремент и один бэкап, или 14 последних, но инкремента не будет. Ведь чтобы был инкремент надо сравнивать с тем что уже забэкаплено. А если бэкап один и админ проспит беду, на следующую ночь неправильные файлы заменят правильные и в бэкапе.
3. Сейчас на среднем серваке у нас по 100Гб и миллионы файлов (в основном картинки из статей, написанных юзерами в CMS). rsync длится часами — пробовали, знаем.
4. rsync не шлет письма, не шифрует. Разговора нет — можно все баш-скриптом реализовать. И получится то же самое на bash. Так зачем писать больше?
2. Описываемый gem backup rsync умеет, и при этом получаются тоже только инкременты. Но при этом надо выбирать — или инкремент и один бэкап, или 14 последних, но инкремента не будет. Ведь чтобы был инкремент надо сравнивать с тем что уже забэкаплено. А если бэкап один и админ проспит беду, на следующую ночь неправильные файлы заменят правильные и в бэкапе.
3. Сейчас на среднем серваке у нас по 100Гб и миллионы файлов (в основном картинки из статей, написанных юзерами в CMS). rsync длится часами — пробовали, знаем.
4. rsync не шлет письма, не шифрует. Разговора нет — можно все баш-скриптом реализовать. И получится то же самое на bash. Так зачем писать больше?
я везде пользовал astrails, который к тому же умеет работать с Amazon S3, но ваш вариант тоже вполне спортивный.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Резервное копирование Rails проектов без затей