В настоящее время я использую виртуальный сервер под управлением Ubuntu Linux. Компания, разместившая его, не делает никаких резервных копий, но они предлагают мне возможность делать резервные копии через FTP. Таким образом, я получаю доступ к FTP-ресурсу, равному размеру хранилища моего основного сервера. Доступной помощи больше, чем Это данные вашей учетной записи FTP, получайте удовольствие! но я предполагаю, что я должен написать небольшой скрипт и запустить его как задание cron. Они продвигают свое решение для резервного копирования, как будто это лучшая и простая вещь в мире, но сейчас я вижу много открытых вопросов.
Поэтому я спрашиваю не о том, как написать сценарий оболочки, а о том, что он должен делать.
Сначала мне нужно решить, хочу ли я просто резервное копирование некоторых папок с данными (например, htdocs и недавний дамп БД) или если я хочу зеркало всего сервера. Я бы хотел сделать последнее, потому что меня беспокоит не только потеря данных, но и все трудности с настройкой сервера с нуля, что обычно занимает у меня несколько дней.
Далее, мне интересно, возникнут ли у меня проблемы при резервном копировании файлы, к которым в настоящее время осуществляется доступ каким-то образом, может быть, даже написано. Останутся ли у меня поврежденные файлы в моей резервной копии, резервное копирование просто остановится или нормальная работа сервера будет прервана?
Если бы у меня было вдвое больше места для резервных копий, чем у моего основного сервера, я бы загрузить резервную копию n, а после успеха удалите резервную копию n-1. Но у меня есть только пространство, равное жесткому диску моего сервера, поэтому я не могу хранить резервные копии n и n-1 одновременно. Но если я сделаю это наоборот (то есть удалю резервную копию n-1, а затем начну загружать резервную копию n), я прохожу время без какой-либо резервной копии, чего я бы хотел избежать.
Если бы у меня был физический доступ к этому серверу или хотя бы доступ к файлу, создающему образ виртуального жесткого диска моего VServer, я бы просто сделайте резервную копию этого образа и восстановите его целиком. Но, к сожалению, у меня нет такого доступа.
И последнее, мне тоже интересно как я должен восстановить эти данные на случай, если основное хранилище уйдет. Возможно ли в Linux позволить системе перезаписывать себя данными резервной копии во время работы? Даже если можно указать системе загружать все через ftp, хранить их прямо в корне файловой системы / и перезаписывать все, что там есть, мне все равно придется удалить все файлы, которые есть сейчас, но не присутствовали в резервное копирование.
Любая помощь и идеи приветствуются!
Попробуйте ftplicity - хорошее руководство можно найти на HowToForge: http://www.howtoforge.com/ftp-backups-with-duplicity-ftplicity-debian-etch
Чтобы ответить на другие ваши вопросы:
имеет смысл делать резервную копию только конфигурации сервера (/ etc), ваших пользовательских данных (/ home, / usr / local, ...), а не всего сервера. Восстановление ubuntu можно легко выполнить с помощью dpkg, см. «Dpkg get-selections» на ubuntugeek.com/clone-your-ubuntu-installation.html.
да, файлы, которые в настоящее время записываются, будут вызывать проблемы с резервным копированием (базы данных MySQL, почтовые спуфайлы и т. д.), поэтому обычно лучше всего взглянуть на все службы, резервные копии которых вам нужны, и изучить их документацию
без резервного копирования всего сервера и с помощью tar вы сможете хранить несколько наборов резервных копий на ftp-сервере
восстановление должно быть простым: вы ведь получите рабочий виртуальный сервер? Используйте dpkg set-selections для обновления пакетов, восстановления / и т.д., перезагрузки (или перезагрузки служб) и копирования вашей даты пользователя обратно
Честно говоря, я бы не стал беспокоиться. FTP небезопасен и незашифрован - любой может перехватить ваш трафик и украсть ваши данные.
Настройте настоящую систему резервного копирования (rdiff-backup через SSH - неплохой выбор для такого рода настройки) и держитесь подальше от изящных BS вашего провайдера. Резервные копии слишком важны, а диски слишком дешевы, чтобы идти на глупый риск.