Мы хотим сделать резервную копию всего на нашем сервере Debian, который работает удаленно на другом конце света (размещен на Linode), не выключая его.
Эта система запускает оболочку, электронную почту, XMPP / prosody и веб с парой простых настроек nginx.
Мы хотим сделать резервную копию файлов, связанных с этими вещами, на всякий случай. Например, файлы, которые пользователи хранят в своих домашних каталогах.
Нам не нужно в точности копировать существующие настройки для каждого файла / etc; вместо этого, причина, по которой мы даже делаем резервную копию, в первую очередь, заключается в том, что мы можем переместить все это в новую установку (более новая версия Debian все еще находится на Linode).
Я вижу, что Linode предлагает услугу резервного копирования. Но в долгосрочной перспективе нам также понадобятся наши собственные резервные копии на случай, если они исчезнут или произойдет что-то еще странное.
Причина, по которой существует этот вопрос, заключается в том, что, когда я пытался делать резервные копии в прошлом, я продолжал делать одну из этих двух ошибок:
/ и все, что находится под ним ", а затем застрял в каком-то странном бесконечном цикле либо из-за того, что диск, на который я копировал, был смонтирован в / media / backup, и он копировал себя рекурсивно [очевидно, что эта конкретная проблема здесь не применима, поскольку мы собираемся резервное копирование over rsync или аналогичный], или он застрял, пытаясь скопировать некоторые «живые» вещи в / proc или / var или что-то еще, например, пытаясь не отставать от постоянно меняющихся журналов, или/var) и возьмем копию /etc и все старые письма в / var / vmail ", а затем я неизменно испортил права доступа к файлам или временные метки (на этот раз я не буду делать резервные копии файлов unix на диск FAT) или что-то забыл (" о, черт, У меня было несколько пользовательских скриптов в / usr / local / bin, которые я больше нигде не хранил, я забыл их достать, думаю, они уже ушли ").Таким образом, прямое копирование всего диска вверх привело к ошибкам, а выборочное копирование каталогов привело к ошибкам. Я хочу знать, как это сделать правильно.
Вопрос о сбое сервера Что нужно для полноценной системы резервного копирования? охватывает философию и передовой опыт, но я ищу более конкретные детали:
rsync -HXaz Думаю, это хороший вариант для нас? В -z obv на самом деле не имеет отношения к вопросу "что я сохраняю"Я вижу много советов по резервному копированию, например использование dd, похоже, предполагает, что диск отключен и не используется. Но разве я не должен исключать «живые» каталоги, такие как / proc и некоторые подкаталоги в / var (однако, некоторые вещи в / var, я знаю, что мы определенно делать нужно сохранить) и / монтировать? О чем еще мне нужно думать в этой ситуации? Тогда, я думаю, я могу просто перебить его с помощью rsync и использовать кучу --exclude флаги.
Или есть идеи получше, особенно дружественные к СОПО?
Итак, вы хотите сделать резервную копию всего вашего диска без всех этих неприятных ошибок, а также отфильтровать все / proc и другие временные папки?
Можно смонтировать корневую папку в другую папку в файловой системе, например:
$ cd /mnt
$ mkdir drive
$ mount --bind / drive
Это даст вам все файлы на вашем диске, которые не считаются временными (например, папки / proc или / sys).
Теперь, когда у вас есть четкое представление о вашей корневой папке, вы можете просто скопировать ее на свой резервный диск, используя стандартные cp или rsync. Что-то вроде:
cp -R /mnt/drive /mnt/backupdrive
Это решает обе упомянутые вами проблемы:
Смотрите также: крепление на человека (8)
В 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.
Но это всего лишь общая идея. Все может усложниться в зависимости от того, что у вас на самом деле есть на этом сервере, какова ваша конфигурация, сеть и настройки оборудования. И, в конце концов, это может быть действительно сложно или невозможно сделать без заметных простоев.
На самом деле вы хотите восстановить. Что бы вы ни делали, вы должны регулярно его восстанавливать, тестировать.
У Linode есть служба резервного копирования. Моментальные снимки можно делать по ограниченному заранее определенному расписанию или с помощью API.
Преимущество резервного копирования на основе моментальных снимков заключается в том, что они предлагают точный момент времени, поскольку данные не меняются во время копирования. Снимки также можно легко восстановить на другом хосте, в данном случае на новом Linode.
Запустите вашу систему на ZFS. Затем вы можете сделать мгновенный атомарный снимок, используя что-то вроде:
# zfs snap -r tank@name-of-backup
где tank как называется ваш пул ZFS. Этот моментальный снимок гарантированно является мгновенным моментальным снимком файловой системы и всех ее дочерних файловых систем.
После того, как вы создали снимок, вы можете перенести его на другой хост, используя zfs send и ssh.
Я использую BackupPC для своего небольшого виртуального частного сервера, это работает достаточно хорошо. BackupPC может использовать rsync под капотом и поддерживает полное и инкрементное резервное копирование. Взгляните на него и посмотрите, удовлетворит ли он ваши требования.
Я считаю, что это зависит от того, на каком сервере и где вы запускаете сервер с внутренней командой Linux, это невозможно, вам нужно имитировать / передавать полные данные и библиотеки. Если вы работаете на vmware и хорошо настроены, он обеспечивает миграцию в реальном времени. В противном случае вам придется использовать сторонние инструменты. Надеюсь, что это поможет вам. Еще несколько ссылок Как мне сделать резервную копию живого сервера?
Rsync - хорошая команда для синхронизации данных между серверами.
Доступны 2 решения, в которых вам не нужно (больше) полагаться на недостающие биты, а также на пропуск одного пункта из вашего списка из-за неполного контрольного списка или, может быть, просто из-за того, что упущено что-то важное.
Во-первых, если вы переместите это на платформу с некоторым дополнительным контролем над базовой аппаратной платформой, вы можете делать снимки всех файлов на диске во время работы сервера. Например, на AWS вы можете сделать снимок диска EBS и даже заплатить только за разницу, когда позже сделаете еще один снимок.
Во-вторых, я рекомендую сценарий для настройки вашего полного сервера с системой управления конфигурацией, такой как Ansible. Это будет
документируйте все, что вы настроили в системе управления версиями
позволяет протестировать воссоздание сервера из резервной копии или с нуля, чтобы убедиться, что ваши скрипты обновлены
позволяют повторно запустить сценарий в более новой операционной системе, обычно с весьма незначительными изменениями.