Я запускаю веб-сайт LAMP в Linux 10.0.4 LTS. Я системный администратор-новичок (хотя я и разработчик), и мне нужен совет о том, как лучше всего реализовать резервное копирование для моего веб-сайта. Моя база данных - это mySQL, и ВСЕ мои таблицы базы данных используют механизм базы данных InnoDb.
Вот требования к резервному копированию, которые я хочу реализовать:
Включает в себя инкрементные и полные резервные копии базы данных mysql. Я хотел бы иметь ежечасные инкрементные резервные копии, а также ежедневные, еженедельные и ежемесячные резервные копии. Но мне не ясно, какую ротацию использовать для этих различных наборов данных резервного копирования, а также как ими управлять ( и что еще более важно, как восстановить базу данных из набора полных / инкрементных резервных копий на дату)
Я хочу сжать и зашифровать данные, чтобы хранить их удаленно (Amazon S3)
Я хочу, чтобы это было полностью автоматизировано (т.е. запускалось как задание cron).
Примечание. Мой сервер «безголовый» в том смысле, что на нем нет окон X или другого графического интерфейса пользователя, поэтому я думаю о реализации резервного копирования с помощью сценария bash. В качестве альтернативы, если есть программное обеспечение, которое может помочь мне запустить такое резервное копирование, его необходимо запускать из командной строки.
Мне нужно сделать резервную копию:
Вот мои вопросы:
Есть ли существующее программное обеспечение, которое я могу использовать для этого, или мне нужно написать свое собственное (сценарий bash)?
Какую стратегию резервного копирования рекомендуется использовать (с точки зрения того, что выполняется ежечасно, ежедневно, еженедельно и т. Д.) И как восстановить веб-сайт с определенного момента времени?
Если мне придется написать свой собственный сценарий bash (я также являюсь новичком в написании сценариев на bash), я буду благодарен, если кто-нибудь предоставит скелетный сценарий, который поможет мне начать работу.
[Редактировать]
symcbean: не могли бы вы перечислить, какая дополнительная информация вам нужна от меня, чтобы дать «более индивидуальный совет»? Что касается бюджета, то можно сказать, что он нулевой. Итак, я не могу раскошелиться на что-то большее, кроме (выделенного) хостинга сервера + хранилища Amazon S3. Вот почему мне нужно будет либо использовать программное обеспечение с открытым исходным кодом, либо написать свой собственный сценарий bash, используя доступные инструменты в Linux.
Это новый веб-сайт, и изначально объем резервных копий данных, вероятно, будет меньше 1 Гб, но я полностью ожидаю, что объем данных будет расти как минимум примерно на 100 Мб в день. Это очень быстро складывается, если я делаю полные резервные копии ежедневно и отправляю файлы резервных копий по проводам на Amazon S3.
Я предложил инкрементное резервное копирование, потому что хочу сэкономить на расходах на полосу пропускания (не говоря уже о нагрузке на сервер), связанных с потенциальной передачей нескольких гигабайт данных каждый день.
Кроме того, никто (пока) не объяснил, как переключаться между [ежечасным?], Ежедневным, еженедельным и ежемесячным резервным копированием.
Существует много (сильно различающейся) информации / мнений относительно резервных копий. Я просто хочу знать, каковы рекомендуемые «лучшие практики» в моей конкретной ситуации, как описано выше.
Если требуется дополнительная информация, чтобы иметь возможность предложить более «индивидуальную рекомендацию», дайте мне знать, чтобы я мог предоставить необходимую информацию.
ежечасное инкрементное резервное копирование, а также ежедневное, еженедельное и ежемесячное резервное копирование
Я настоятельно рекомендую не использовать mysqldump в вашей действующей системе. Даже с таблицами innodb будет сложно получить согласованные резервные копии из работающей системы.
Как обычно, здесь вы не указали ни подробных указаний на ограничения с точки зрения доступа и бюджета, ни четкого указания того, чего вы здесь пытаетесь достичь.
Я бы рекомендовал использовать репликацию mysql для поддержки базы данных горячего резерва. Но для получения согласованного снимка системы вам необходимо отключить репликацию на клиенте, запустить mysqldump, затем включить репликацию и сохранить файл дампа в полной резервной копии.
Что касается программного обеспечения - вы, очевидно, выросли в среде MSWindows. Написание скриптов легко, и все инструменты для сжатия, шифрования, присвоения имен и перемещения файлов входят в стандартную комплектацию дистрибутива Linux - вопрос только в том, как вы их используете. При этом я предпочитаю программное обеспечение для резервного копирования файлов afio, которое обычно не включается в минимальные установки (у вас будут tar, cpio, gzip, rsync, ssh). Если у вас есть Google для afio, вы найдете множество документов, объясняющих его достоинства по сравнению с инструментами по умолчанию.
Резервную копию можно использовать только в том случае, если вы знаете, как и можете ли вы ее восстановить.
ИМХО, инкрементальные бэкапы - пустая трата времени. Конечно, это имело смысл, когда носитель для резервного копирования был дорогим - это уже не тот случай - хранение относительно дешево по сравнению с затратами вашего времени и усилий, а также с ценностью данных. Последнее, что вам нужно при восстановлении системы, - это продумать, какую последовательность резервных копий восстановить, чтобы получить целостный образ - и если у вас есть неудачная резервная копия в наборе, все может пойти совершенно неправильно.
Лучшим решением будет репликация с горячим резервом (с использованием rsync для файлов и репликации mysql для базы данных). Затем периодически создавайте внешние изображения (по сети, на магнитную ленту, dvd ...) в режиме ожидания.
Если вам действительно не хватает денег, то «горячий резерв» может легко существовать на втором диске в той же коробке, что и действующий сайт, но в качестве предпочтения я бы рекомендовал отдельную машину.
Некоторое время назад у меня был аналогичный вопрос, касающийся баз данных ... возможно, вы захотите просмотреть: Как восстановить только ОДНУ базу данных mysql из коллективной резервной копии
Что касается rsync, вы можете просмотреть следующий сайт: http://www.sanitarium.net/golug/rsync_backups_2010.html
Чем мы занимаемся на работе, кроме центрального резервного сервера, на котором мы регулярно меняем диски на внешний источник. В нашем отделе есть настройка rsync, и на каждом веб-сервере есть настройка учетной записи для пары ключей. Таким образом, у нас есть одно устройство, которое будет подключаться к каждому из наших веб-серверов, выполнять mysqldump и выполнять rsynch для mysqldump вместе с указанными нами веб-каталогами.
Для восстановления: вы можете использовать rsynch для восстановления до определенного дня.
В инкрементальном режиме это вопрос настройки различных заданий cron для выполнения с желаемыми интервалами.
Я могу предоставить более подробную информацию об этом, если вам интересно. Это был сценарий, созданный в доме.