У меня есть несколько небольших виртуальных частных серверов под управлением Ubuntu 11.04. В настоящее время у меня есть VirtualMin, управляющий резервными копиями для сервера, однако он выполняет резервное копирование только домашних папок пользователей и конфигурации различных вещей, связанных с Apache, FTP или еще чем-то, настроенными для поддержки отдельного виртуального хоста.
Я хотел бы сделать что-нибудь более надежное. Я хотел бы иметь возможность, в случае возникновения чрезвычайной ситуации, иметь возможность сделать самую последнюю резервную копию, переместить ее на новый VPS, разархивировать / распаковать ее, и новый VPS будет по существу клоном старого.
В настоящее время все резервные копии хранятся на Amazon S3, и я бы хотел сохранить их в таком виде. Я также не хотел бы полагаться на конкретный инструмент для восстановления (например, хранение в пользовательских / проприетарных двоичных файлах).
По сути, как я могу создать резервную копию моего сервера, чтобы я мог распаковать резервную копию на новый сервер и заставить их вести себя так же. Я понимаю, что есть особые соображения по поводу баз данных, у меня уже есть стратегия резервного копирования для MySQL.
Резервное копирование с помощью TAR
В Linux прекрасно то, что все является файлом. Поскольку все является файлом, все, что вам нужно сделать для резервного копирования и восстановления вашей системы, - это скопировать все файлы обратно (за некоторыми исключениями, упомянутыми ниже). Предполагая, что подготовка VPS устанавливает базовую операционную систему, вы можете просто архивировать с помощью tar и gzip всю файловую систему и где-нибудь сохранить файл tar.gz. Восстановление - это просто вопрос восстановления существующих файлов, желательно в однопользовательском режиме.
Немного более простой способ
Раньше я использовал tar, и он работает, но я предпочитаю настроить rdiff-backup и backupninja, что значительно упрощает создание инкрементных резервных копий. У этого метода есть несколько преимуществ:
Что исключить
В любом случае есть несколько каталогов, которые могут не понадобиться для резервного копирования или восстановления:
/lost+found - сюда отправляются файлы, когда ваша файловая система повреждена и fsck пытается что-то исправить. Если что-то здесь закончится, вы, вероятно, в любом случае предпочтете восстановить данные из вчерашней резервной копии./mnt и /media - зависит от того, что там смонтировано, если вы монтируете там удаленные файловые системы, вы, вероятно, не захотите создавать их резервную копию с помощью образа локальной системы/proc - это специальная файловая система для процессов - она будет частью вашей базовой операционной системы при создании нового VPS и не требует восстановления/sys и /dev - информация о драйверах и оборудовании - будет частью установки новой ОС, и перезапись может что-то сломать/tmp - временные файлы обычно не нуждаются в резервном копировании, и там можно создавать большие файлы, которые занимают место в ваших резервных копиях./var/cache/apt - здесь apt хранит загруженные пакеты, чтобы их можно было легко переустановить. Я не беспокоюсь о резервном копировании, потому что он может стать огромным, и все, что там есть, можно легко загрузить сноваКак и в случае с кешем apt, у вас могут быть другие каталоги, содержащие большие, легко загружаемые повторно файлы, поэтому исключите их. Нет смысла оплачивать хранение в S3 файлов, которые можно просто загрузить снова.
Проверьте свои резервные копии!
Резервные копии бесполезны, если вы не можете их восстановить. Поскольку вы используете VPS, вам должно быть очень легко развернуть новую виртуальную машину и восстановить ее, не затрагивая ваш основной сервер. Большинство провайдеров VPS взимают плату только за часы / дни, которые он фактически работает, поэтому это будет стоить всего несколько долларов.
Запишите, как именно восстановить резервные копии и какие проблемы вы преодолели при их тестировании - когда придет реальное время, вы будете нервничать, и хорошо иметь заметки, которые помогут вам в этом процессе.
Другие ошибки
Если вы выполняете восстановление на другой машине, возможно, они предоставили другой IP-адрес. Убедитесь, что вы изменили /etc/network/interfaces сразу после восстановления в соответствии с вашим новым IP-адресом, иначе перезагрузка заблокирует вас. Также проверьте любую программу брандмауэра, которую вы используете, чтобы увидеть, не нужно ли что-то изменить. Если это не тест и вы действительно восстанавливаетесь на другой сервер, вам также необходимо изменить IP-адреса в конфигурациях программного обеспечения вашего сервера и DNS-серверах.
Восстановление таким способом пройдет гладко только при восстановлении до той же версии ОС. Например, восстановление до более новой версии Ubuntu может сломаться, иногда странным образом, о котором вы не замечаете до нескольких недель или месяцев. Если вам нужно выполнить восстановление до другой версии, вам лучше скопировать только файлы конфигурации и пользовательские данные и установить любое программное обеспечение через ОС, как если бы это была новая установка.