Как сделать резервную копию работающей Сервер Linode?
Мы хотим сделать резервную копию всего на нашем сервере Debian, который работает удаленно на другом конце света (размещен на Linode), не выключая его.
Эта система запускает оболочку, электронную почту, XMPP / prosody и Интернет с парой простых настроек nginx.
Мы хотим сделать резервную копию файлов, связанных с этими вещами, на всякий случай. Например, файлы, которые пользователи хранят в своих домашних каталогах.
Нам не нужно точно копировать существующие настройки для каждого файла / etc; вместо этого, причина, по которой мы даже делаем резервное копирование, в первую очередь состоит в том, что мы можем переместить все это в новую установку (более новая версия Debian все еще находится на Linode).
Я вижу, что Linode предлагает услугу резервного копирования. Но в долгосрочной перспективе нам также понадобятся наши собственные резервные копии, здесь, на случай, если они исчезнут или произойдет что-то еще странное.
Причина, по которой существует этот вопрос, заключается в том, что когда я пытался делать резервные копии в прошлом, я сохранял допустив одну из этих двух ошибок:
- Я сказал: «Хорошо, я просто скопирую
/и все, что находится под ним», а затем застрял в каком-то странном бесконечном цикле либо из-за диска, которым я был копирование в было смонтировано в / media / backup, и оно копировалось рекурсивно [очевидно, что эта конкретная проблема здесь не применима, поскольку мы собираемся делать резервную копию через rsync или аналогичный], или он застрял, пытаясь скопировать некоторые «живые» вещи в / proc или / var или что-то еще, например, пытаясь не отставать от постоянно меняющихся журналов, или - Я сказал: «Хорошо, я просто возьму минимум того, что нам нужно… хм, домашние каталоги каждого, и каталоги нашего веб-сервера (все в
/ var) и давайте скопируем копию/ etcи всех старых писем в / var / vmail "и d, то я неизменно испортил права доступа к файлам или временные метки (на этот раз собираюсь убедиться, что я не создаю резервные копии файлов unix на диск FAT) или что-то забыл («о, черт, у меня было несколько пользовательских сценариев в / usr / local / bin, который я больше нигде не хранил, я забыл их достать, думаю, теперь они ушли ».
Таким образом, прямое копирование всего диска привело к ловушкам, а выборочное копирование каталогов привело к ловушкам. Я хочу знать, как это сделать правильно.
Вопрос о сбое сервера Что нужно для полной системы резервного копирования? охватывает философию и передовые методы, но я ищу эти более конкретные детали:
- Какие каталоги мне нужно скопировать, а какие исключить (учитывая, что это система, которая в настоящее время работает и обслуживает вики, чат XMPP, электронную почту - с новыми сообщениями, поступающими во время выполнения задания копирования)
- Что атрибуты файла, такие как отметки времени, владелец и группа, мне нужно представить, и как мне это сделать?← Думаю, я сам смогу ответить на эту половину вопроса, например… гм…
rsync -HXazДумаю, это хороший вариант для нас?-zobv на самом деле не имеет отношения к вопросу «что я сохраняю»
Многие советы по резервному копированию, которые я вижу, например, использование dd , похоже, предполагают, что привод отключен и не используется. Но разве я не должен исключать «живые» каталоги, такие как / proc и некоторые подкаталоги в / var (однако я знаю, что некоторые из вещей в / var нам определенно необходимо сохранить ) и / mount ? О чем еще мне нужно думать в этой ситуации? Тогда, думаю, я могу просто перехитрить это с помощью rsync и использовать кучу флагов - exclude .
Или есть лучшие идеи, особенно дружественные к FOSS?
Значит, вы хотите сделать резервную копию всего вашего диска без всех этих неприятных ошибок, а также отфильтровать все / proc и другие временные папки?
Можно подключить корневую папку в другую папку внутри файловой системы, например:
$ cd /mnt
$ mkdir drive
$ mount --bind / drive
Это даст вам все файлы на вашем диске, которые не считаются временными (например, папки / proc или / sys).
Теперь, когда у вас есть четкое представление о вашем корневую папку, вы можете просто скопировать ее на свой резервный диск, используя стандартный cp или rsync . Что-то вроде:
cp -R /mnt/drive /mnt/backupdrive
Это решает обе упомянутые вами проблемы:
- Вы не попадаете в рекурсию, потому что резервный диск не смонтирован внутри диска (точка зрения)
- , вы не пропустите любые важные файлы, потому что вы забираете их все
См. также: man mount (8)
На мой взгляд. Это зависит от того, на каком сервере и где у вас запущен сервер с внутренней командой linux, это невозможно, вы должны имитировать / передавать полные данные и библиотеки. Если вы работаете на vmware и хорошо настроены, он обеспечивает миграцию в реальном времени. В противном случае вам придется использовать сторонние инструменты. Надеюсь, что это поможет вам. Еще несколько ссылок Как сделать резервную копию действующего сервера?
Rsync - хорошая команда для синхронизации данных между серверами.
На самом деле вам нужно восстановить. Что бы вы ни делали, вы должны регулярно его восстанавливать, тестировать.
У Линоде есть служба резервного копирования. Снимки можно делать по ограниченному заранее определенному расписанию или с помощью API.
Преимущество резервных копий на основе моментальных снимков заключается в том, что они предлагают точный момент времени, поскольку данные не изменяются во время копирования. Снимки также можно легко восстановить на другом хосте, в данном случае на новом Linode.
Я использую BackupPC для своего небольшого виртуального частного сервера, это работает достаточно хорошо. BackupPC может использовать rsync под капотом и поддерживает полное и инкрементное резервное копирование.Взгляните на него и посмотрите, удовлетворит ли он ваши требования.
Запустите вашу систему на ZFS. Затем вы можете сделать мгновенный атомарный снимок, используя что-то вроде:
# zfs snap -r tank@name-of-backup
, где tank - это то, что называется вашим пулом ZFS.Этот моментальный снимок гарантированно является моментальным моментальным снимком файловой системы и всех ее дочерних файловых систем.
После того, как вы создали моментальный снимок, вы можете передать его на другой хост, используя zfs send ] и ssh .
В Linux все является файлом. Это возможно через rsync, но есть вещи, о которых нужно знать, и которые (в лучшем случае) трудно обойти.
Вы должны сначала подумать о репликации, особенно для баз данных. Также рекомендуется установить прокси / балансировщик нагрузки перед основным сервером, чтобы можно было легко переключаться между основным и зеркальным серверами во время перехода.
На уровне оборудования наилучшей ситуацией будет следующее: иметь зеркальный сервер на другой стороне, с тем же количеством портов Ethernet, той же разводкой жесткого диска и так далее. Все, что отличается, подразумевает необходимость изменения конфигурации системы.
т.е. если у вас два порта eth, вы хотите убедиться, что сетевая конфигурация, брандмауэр и т. д. совпадают с именем интерфейса на обоих серверах, и в случае, если оно отличается, вам нужно либо изменить конфигурацию после rsync, либо изменить имя устройства на втором ( пункт назначения) сервер.
То же, что и схема разделов. Вы должны создать те же разделы, что и на вашем основном сервере, но если вы создадите их с нуля, вы получите разные UUID, поэтому вам нужно будет изменить fstab, grub, mdadm (если задействован soft-raid) и т. Д. .
Но есть также много вещей, которые могут пойти не так, как, например, базы данных, которые могут быть несовместимыми, если не были предварительно остановлены (перед выполнением rsync).
Лучшей стратегией будет сначала подготовить оборудование и файловую систему (разделы) - в соответствии с конфигурацией основного сервера. Затем смонтируйте пустые паритоны через промежуточную систему (например, live CD с временно установленным ssh-сервером). Вы создаете пустой / proc, / dev, / sys, а затем rsync остальное, например:
rsync -avz -H --delete /etc /bin (...and so on) destserver:/mnt/yourrootfs/
Затем вам нужно установить grub на устройство и работать над настройкой, чтобы сделать его загрузочным, изменить конфигурацию сети, fstab и другие вещи. упомянутый ранее.
Вы также можете попробовать установить новую систему (с той же версией, которую вы используете на своем основном сервере), затем выключить ее, смонтировать через другую временную систему (например, live cd), а затем заменить что-нибудь, кроме / proc, / sys, / dev и / boot с помощью rsync.
Но это только общая идея. Все может усложняться в зависимости от того, что у вас на самом деле есть на этом сервере, какова ваша конфигурация, сеть и настройки оборудования. И, в конце концов, это может быть действительно сложно или невозможно сделать без заметных простоев.
Доступно 2 решения, в которых вам не нужно (больше) полагаться на недостающие биты, а также на пропуск одного элемента в вашем списке из-за неполного контрольного списка или, может быть, из-за того, что упущено что-то важное. .
Во-первых, если вы переместите это на платформу с некоторым большим контролем над базовой аппаратной платформой, вы сможете делать снимки всех файлов на диске во время работы сервера. Например, на AWS вы можете сделать снимок диска EBS и даже заплатить только за разницу, когда позже сделаете еще один снимок.
Во-вторых, я рекомендую сценарий для настройки всего вашего сервера с системой управления конфигурацией, такой как Ansible. Это
документирует все, что вы настроили в системе управления версиями
, что позволит вам протестировать воссоздание сервера из резервной копии или с нуля, чтобы убедиться, что ваши скрипты обновлены.
позволит вам повторно запустить скрипт на более новой операционной система, как правило, с весьма незначительными изменениями.