TheNest.Ru
Резервное копирование на удаленный сервер
TheNest.Ru
Только полноправные пользователи могут оставлять комментарии. TM Feed Хабрахабр Geektimes Тостер Мой круг Фрилансим. Хабрахабр Публикации Пользователи Хабы Компании Песочница. Southbridge ,55 Обеспечиваем стабильную работу серверов. Назрела необходимость замены медленного rdiff-backup на более шустрое решение для инкрементальных бекапов на удаленый сервер. Сперва рассматривался Rsnapshot, но причине того, что он не умеет без костылей делать бекапы именно на удаленные серверы от него отказались. Прочие аналоги нам также не подошли по тем или иным причинам. Искать что-то готовое на просторах github и допиливать под себя мы не захотели, поэтому было решено написать новый скрипт с нуля своими силами. Главная цель сделать решение для инкрементального бекапа на удаленный сервер схожее с rdiff, но с использованием жестких ссылок rsync. Скрипт выложен в нашем репо на github , будем рады получить отзывы, советы, коммиты! Инструкция по приминению нашего решения на примере CentOS 6. Устанавливаем rsync и xinetd: Настройка окружения для бэкапа сервера. Добавляем пользователя если он не еще не добавлен: Для изменения параметров сервера бэкапов, исключений контейнеров из бэкапа, локальной папки или ее отсутствия достаточно внести изменения в файл rsync-backup. Если локальный бэкап отменили — локальные исключения добавляются в удаленные. Включения Особенностью этого скрипта является возможность включения определенных файлов или каталогов из исключенной директории выше иерархией. Если нужно включить конкретный файл, то необходимо указать его путь без первичного слеша, к примеру: При работе включений будет бэкапиться вся иерархия директорий контейнера, даже если раннее было добавлено исключение определенных директорий, но бэкапиться будет именно директории без файлов. Это особенность работы rsync, к сожалению другого пути пока не нашли. Часть скрипта для работы включений: Поэтому, чтобы сократить объем дискового пространства занимаемого бэкапом, при добавлении исключений, и при чистке бэкапов от этих исключений нужно будет удалить соответствующие директории в каждой папке бэкапов. Конечно можно написать скрипт для автоматизации этой рутины, это в планах. В заключение, какой выйгрыш по времени мы все-таки получили: Cравнительный тест rdiff vs. Сравнение времени выполнения бэкапа: Первичный бэкап контейнера в 5Gb локальный и удаленный rdiff-backup — 6 минут 30 секунд rsync-backup — 1 минута 34 секунды 2. Вторичный бэкап, изменения в контейнерах не было rdiff-backup — 30 секунд rsync-backup — 2 секунды 3. Вторичный бэкап, в контейнер добавлена папка c дистрибутивом debian не iso в 4. Добавить в закладки Метки лучше разделять запятой. Я правильно понимаю, что вы написали свою версию rsnapshot? А почему не использовали rsnapshot? Я правильно понимаю, что инициация бекапа идет со стороны клиента а не со стороны сервера, как в случае с rsnapshot? Посмотрел в исходники и не нашел cp -al. За счет чего получаются хардлинки между одинаковыми предыдущими копиями? Нет, это все-таки немного попроще чем rsnapshot. Rsnapshot не подошел как раз потому, что нам нужен бекап с клиентского сервера на сервер бекапов. Хардлинки делает rsync c опцией -H rsync --help … -H, --hard-links preserve hard links. Этот ключик я тоже искал и не нашел в rsync-backup. А бекапы вы делаете на сервер в том же датацентре или в другом? И, если таки хардлинки где-то делаются, то сколько это занимает времени на куче мелких файлов? Мы сделали себе аналогичную систему на rsnapshot, но cp -al на каталог с сотнями битриксовских сайтов занимает часы, если в бекапном сервере не ssd. В случае совпадения — создается хардлинк на файл. Сейчас есть неудобство у скрипта в том виде какой он есть сейчас — если нужно подчистить бэкап — нужно удалить все хардлинки. Зачем удалять все хардлинки? Ну, бывают случаи когда бэкап какого-то определенного сервера сильно разрастается, и необходимо уменьшить его размер за счет добавления в исключений не критичных данных, после чего подчистить бэкап от этих данных. Насчет ключа, я не совсем прав был скрипт не я писал , там немного по-другому: Хардлинки делаются не долго. Из цифр которые я приводил в конце статьи, это можно примерно понять. А в чём собственно проблема с rsnapshort? Объясню почему не rsnapshot. В другом случае rsnapshot делать удаленный бэкапы не умеет, в силу как раз использования хардлинков да суть та же rsnapshot работает на базе rsync. В нашем случае это удалось обойти использованием rsync сервера, почему к этому не пришли разработчики rsnapshot — не понятно: Есть мысль, что удалённому серверу виднее, когда у него сеть и диски менее нагружены. В итоге мы сделали бекапный сервер который по очереди в несколько потоков ходит ко всем клиентам и делает с них снапшоты. Кстати да, забыл почему-то написать — мы то это сделали как раз на rsnapshot — он умеет со стороны сервера ходить к клиентам по ссх и забирать оттуда данные по рсинк, например. Этот вариант мы отмели из-за специфики работы. Имея большое количество серверов различных клиентов, очень не хочется оставлять дыру в виде рутового парольного доступа на ВСЕ сервера наших клиентов. Можете назвать это паранойей. А как связаны наличие рутового, да ещё и парольного доступа и бэкап с удалённой машины? А так вы наоборот оставляете дыру ещё большую: ТО есть разработчики rsnapshot предлагают организовать доступ по ключу. А что касается доступа на сервер бэкапа. А для операций ротации на стороне сервера бэкапов используется не привилегированный доступ. Для бэкапов каждого клиента заводится отдельный доступ. AllowUsers в конфиге sshd. Так что rsync over ssh ничуть не уступает в этом плане. То есть для хардлинков нужен рутовые права Можно тут подробнее? Что вы имеете в виду? Потребность в руте нужна для того что бы сохранить права файлов при бэкапе. При бэкапе с правами всё отлично как раз. Чуть подробнее можно прочитать тут. Тот, кто имеет доступ к бекапному серверу — в любом случае имеет доступ ко всем файлам. У ssh ключей можно прописывать со стороны сервера какие команды разрешено запускать при авторизации по этому ключу — на сколько я понимаю — оставить только rsync — решает вашу задачу. Я правильно понял, что вы считаете, что rsnapshot умеет делать бэкап исключительно с локальной машины на локальную, так как всё завязано на хардлинки? Или вам принципиально, чтобы именно клиент инициировал бэкап? Кстати, вы смотрели на duplicity и dar? Если смотрели, то почему не подошло? И, если я правильно догадываюсь по исходникам, что это для бекапа вдс на базе OpenVZ, то почему вы не переходите на ploop и на бекап его снапшотов, diff для которых за счет COW должен получатся даже меньше, чем как сейчас сейчас большой изменившийся файл будет на бекапном сервере продублирован целиком, если изменится хотя бы его один байт. Честно говоря в контексте той задачи мы не рассматривали duplicity и dar. Хотя мы с ними знакомы. В нашем случае принципиально было сделать легкое решение на базе rsync, поэтому не долго думаю мы начали писать свой скрипт. Насчет контейнеров — верно. Мы практически везде их используем, но мы их неограничиваем. И использовать ploop для нас нет смысла, поскольку контейнер обычно занимает весь раздел. Это все понятно, но в случае с ploop можно получить снапшоты с только изменёнными блоками как при блочной репликации в zfs, примерно. Хотя на не SSD дисках это потом начнет медленно работать, единственный минус. Я подсел на btrfs — очень удобный механизм снапшотов и инкрементального удалённого бекапа: Каждый снапшот всё ещё новый блочный дивайс? Каждый снапшот это как новая папка со своим блекджеком и… Можно примонтировать как девайс или работать как с папкой, если примонтировать уровень выше по дереву. А можно сохранить, передать и развернуть на удалённом сервере с помощью того же receive. Я общую концепцию знаю по знакомству с ZFS. Полгода-год назад тут был хороший обзор недоделанности btrfs. Тем более, если я верно понял, есть централизованный сервер. С ростом инфраструктуры поддерживать самописные скрипты — довольно накладно. Bacula — хорошее решение для корпоративного сектора и это как раз то, что нужно когда одна контора, один центральный сервер. У нас не так — есть много клиентов и все бекапятся кто-куда, у многих есть свои серверы для бекапов. Всем настраивать бакулу не целесообразно. Если всего два-три сервера и один сервер бекапов? И потом, нам критично быстрое восстановление из бекапа, а не ползанье по консоли бакулы она может и не самая плохая, но все же с ней процесс замедляется. Там легко настраиваются различные стораджи куда и какие бэкапы сливать , и есть веб-морды в которых есть права доступа, и бэкапы оттуда легко и быстро извлекаются. Что непредсказуемого вы видите в нашем решении? Простой скрипт, все прозрачно. Веб-морды это не наш метод. Только консоль, только харкор! Да и с веб-мордами все не так очевидно. Если бы они еще заводились с пол-пинка и работали как надо на всех дистрибутивах типа как Almir. Откройте для себя obnam и не плодите велосипедов: Дата основания 22 февраля Локация Москва Россия Сайт southbridge. Ограничение скорости обработки запросов в nginx 2,1k Сутки Неделя Месяц Почему нет русского Amazon, или где зарыта? Интересные публикации Хабрахабр Geektimes. Запуск Java классов и JAR-ов не по учебнику. Критическая уязвимость механизма аутентификации BIND позволяет похищать и изменять DNS-записи серверов. Во льдах Плавучего Континента: CSS и iOS Safari. Новый подход к кэшированию процессора GT. Линейное программирование в python силами библиотеки scipy. Стабильность нейтрона в атомном ядре GT. Разделы Публикации Хабы Компании Пользователи Песочница. Информация О сайте Правила Помощь Соглашение Конфиденциальность. Услуги Реклама Тарифы Контент Семинары.
Данное руководство поможет быстро создать резервные копии наиболее общих компонентов виртуального выделенного сервера, а именно файлов сайта и БД. В руководстве показано, как настроить ежедневное резервное копирование off-site то есть, на другой удалённый сервер , а также как использовать rsync для инкрементного копирования. Для выполнения описанных здесь действий понадобится rsync, cron и несколько простых команд bash. Замените эти условные данные своими значениями. Резервное копирование бывает полным копирует все данные и инкрементным копирует только изменения с момента последнего обновления бэкапа. Создайте каталог для резервного копирования:. Можно также добавить флаг v - czvf , чтобы получить расширенный вывод. Из названии файла для бэкапа следует, что эта начальная копия initial backup была заархивирована при помощи tar в формате gzip. Теперь на сервере есть два файла: Теперь можно настроить ежедневное резервное копирование при помощи crontab это планировщик задач Linux. Для примера настройте автоматическое резервное копирование в 3. Кроме того, cron может сообщить результаты по электронной почте. Итак, теперь каждый день в 3. В случае ошибки в сообщение будет содержать инструкции по её устранению. Чтобы скопировать резервные копии данных на другой удалённый сервер, используйте scp. Предполагается, что у вас уже есть заранее подготовленный виртуальный выделенный сервер по имени backup. Будет запрошен пароль пользователя backup. Чтобы создать такой файл, введите:. Файлы можно хранить в каталоге backups. Нужно скопировать открытый ключ в этот каталог:. Если ключ был установлен правильно, то файл будет скопирован без запроса пароля. Убедитесь, что файл перемещен:. Теперь можно автоматизировать перемещение резервных копий на удалённый сервер при помощи crontab. Это не самый надёжный способ автоматизировать эту задачу. Для автоматизации копирования бэкапа рекомендуется создать скрипт, а затем запланировать его запуск. Данный метод используется в руководстве для краткости и простоты. Что если на удалённом сервере тоже есть программное обеспечение для резервного копирования? В таком случае можно просто синхронизировать данные двух серверов и настроить один из них для выполнения резервного копирования. Кроме того, можно сохранить файлы с отметками. Для этого используется rsync. Первая команда создаёт каталог для хранения копии, а вторая копирует в него изменённые файлы отредактированные, созданные, удалённые. Чтобы запланировать этот бэкап, откройте cron:. Согласно предложенному ранее руководству по установке WordPress, БД называется wordpress, пользователь — wordpressuser, пароль — password. Замените эти условные данные своими данными. Эта команда создаёт SQL-файл initial. Чтобы запланировать бэкап БД, откройте cron и добавьте такие настройки:. Ваш e-mail не будет опубликован. Можно использовать следующие HTML -теги и атрибуты: Технологии Размещение серверов в надежных дата-центрах Европы. Вам прямо сейчас нужно 24 ядра и 72 Gb RAM? Цены VPS Наши выгодные тарифы докажут, что дешевый хостинг вы еще не знали! Money Back — 30 дней! Банковскими картами, электронной валютой, через терминалы Qiwi, Webmoney, PayPal, Новоплат и др. Резервное копирование сайта при помощи Rsync на Centos 6 Январь 1, Создайте каталог для резервного копирования: Инструмент tar может копировать несколько точек системы: Для удобства управления резервными копиями в название файла можно добавить дату создания копии: Копирование бэкапа на удаленный сервер Чтобы скопировать резервные копии данных на другой удалённый сервер, используйте scp. Чтобы создать такой файл, введите: Нужно скопировать открытый ключ в этот каталог: Скопируйте файл бэкапа на удалённый сервер: Убедитесь, что файл перемещен: Инкрементное резервное копирование Что если на удалённом сервере тоже есть программное обеспечение для резервного копирования? Чтобы запланировать этот бэкап, откройте cron: Чтобы запланировать бэкап БД, откройте cron и добавьте такие настройки: CentOS 6 , Rsync , WordPress Добавить комментарий Отменить ответ Ваш e-mail не будет опубликован. Рубрики Arch Linux Centos Cloud Server Debian FreeBSD FTP General Java LAMP Stack LEMP Stack Linux MariaDB mySQL PHP Python RHEL Ruby SSH Ubuntu VPS Без категорий.
Расписание футбольных матчей лиги европы
Оплатить стрелку картой сбербанка
Обшить частный дом сайдингом
Сколько нужно варить клубничное
Таблица размеров диаметра труб