Как сделать резервную копию своего сайта? Меня особенно интересует, когда у вас большой сайт (20 ГБ +) с тысячами файлов?
Есть что-нибудь умнее обычного tar -zcvf backup2010.tar.gz ./public_html/
После ответа на вышеуказанный вопрос, как вы поддерживаете последовательную процедуру резервного копирования?
Спасибо всем за любую помощь
rsync качественный инструмент для копирования только дельт (изменений в файлах):
rsync --partial --progress --rsh=ssh ./public_html/ user@remotehost.com:/permitted/path
Это создаст резервную копию минимального количества данных, которое возможно для синхронизации двух ваших каталогов.
Чтобы затем создать резервную копию, я бы рекомендовал запустить команду tar в вашем вопросе на удаленном компьютере, чтобы у вас все еще был архив за день, но использование полосы пропускания было минимально возможным. Вы можете включить дампы базы данных SQL (не сырые таблицы!) В резервную копию rsync, но убедитесь, что они не попадают в общедоступные каталоги!
Чтобы поддерживать согласованный процесс резервного копирования, используйте cron для этих задач.
И не забудьте создать сценарий и протестировать процесс восстановления! Плохая резервная копия ничего не стоит.
Исходя из предложенного вами использования tar, я предполагаю, что вы используете Unix. Это учитывая, бакула прочный как скала. Его довольно сложно настраивать, но как только вы его настроите, он сделает свое дело с большой надежностью. Есть ряд функций, которые вы можете использовать - несколько клиентов (конечно), несколько ленточных накопителей, клиенты unix / windows (и, возможно, MacOS тоже, хотя я не могу точно сказать), зашифрованные резервные копии лент, восстановление с нуля ( и другие функции аварийного восстановления), резервное копирование на диск или носитель WORM (например, DVD-R). Я не использовал все эти функции, но я использовал многие из них, и bacula спасла мой бекон в ряде случаев - и бекон моих пользователей во многих других.
Одно предложение, которое я передам от коллеги, с которым я согласен, заключается в том, что bacula намного лучше работает с ленточной библиотекой, чем с одним ленточным накопителем. Старый укладчик можно купить за бесценок (я использую дома укладчик DDS-4 на 6 лент, который я купил менее чем за 200 фунтов стерлингов), и если вы говорите о десятках гигабайт и тысячах файлов, я предполагают, что такие инвестиции, вероятно, находятся в пределах вашей досягаемости.
Я также согласен с тем, что преобладающее мнение состоит в том, что сейчас диски настолько дешевы, что резервное копирование на устройства с последовательной памятью (т. Е. На ленту) является устаревшей технологией. Все, что я могу сказать, это то, что за цену еще одной коробки лент я могу расширить свои возможности восстановления на определенный момент времени с четырех месяцев до восьми, и что неиспользуемые ленты могут быть перемещены гораздо легче, чем жесткий диск.
Уже есть страница с большим количеством вариантов, чем я могу сосчитать, в зависимости от ваших потребностей, по адресу Простое автоматическое резервное копирование в стиле моментальных снимков.
Инструмент, который я использую регулярно, rlbackup. rlbackup создает каталоги, например, hourly.0, hourly.1, daily.0, daily.1, daily.2, weekly.0, weekly.1 и так далее. Старые копии автоматически поворачиваются и удаляются. Самый дорогой пробег обычно будет самый первый почасовой прогон. При каждом последующем запуске будут передаваться только измененные, новые или удаленные файлы. Каталоги предоставляют «моментальный снимок», который легко просматривать. Считайте, что это вариант дедупликации для бедняков.
При всем вышесказанном, у rsync есть свои недостатки в производительности. Еженедельные новости Linux опубликовал статью при этом у rsync есть верхние ограничения относительно того, с чем он может хорошо справляться, а с чем - нет. Независимо от того, есть ли у вас миллионы файлов среднего размера или сотни больших файлов, вам необходимо проверить чистую производительность. Если у вас мало данных изменение на вашем сайте изо дня в день, но обычно все новое, это может быть не так уж и плохо.
В сценарии «файлы - это в основном новые файлы» rsync, вероятно, будет работать хорошо. Но если большая часть резервной копии - это база данных SQL, вам необходимо пересмотреть весь подход.
Для нашего сервера Windows мы используем WinSCP, у которого есть удобная функция для синхронизации локальных и удаленных каталогов для передачи файлов. Да, это нужно делать вручную, но после одной катастрофы с резервным копированием из-за «автоматических» резервных копий мне все равно. В любом случае достаточно нажать одну кнопку в конце дня.
На удаленном SSH-сервере у нас есть сценарий, который создает более старые копии этих резервных копий, поэтому, если нам нужна резервная копия менее свежая, чем самая последняя копия, мы можем перейти к архивам.
Мы используем внешние резервные копии, потому что что произойдет, если диск сервера выйдет из строя или, что еще хуже, сервер будет уничтожен наводнением или пожаром? Все локальные резервные копии означают, что мы вышли из бизнеса, если бы это было так.
Я использую много rsync. Внимательно прочтите документацию, есть много интересных возможностей, таких как сохранение резервных копий всех ваших измененных файлов. Rsync передает только измененные файлы, поэтому он очень эффективен, если у вас не слишком много файлов.
резервный менеджер очень интересно: простая установка на Debian, очень быстрая настройка, дифференциальное резервное копирование tarball, резервное копирование mysql, передача через samba, ftp ...
Также есть этот инструмент, который может быть интересен: rdiff-резервное копирование но у меня нет опыта с этим.
Ежедневно используйте cron для запуска этих инструментов, храните резервную копию на другом хосте, часто проверяйте свои резервные копии (лучше всего проводить тесты восстановления), пытайтесь зашифровать резервные копии (на случай, если кто-то их украл ...), получите несколько резервных копий вне площадки на случай больших катастроф ...
rsnapshot.org или написать свой собственный, используя методы из http://blog.interlinked.org/tutorials/rsync_time_machine.html
--link-dest = позволяет выполнить жесткую ссылку, чтобы ваша новая резервная копия содержала жесткие ссылки на неизмененные файлы и фактический файл для чего-то, что изменилось с момента последней резервной копии. После первоначального резервного копирования передаются только измененные файлы. Удаление предыдущего поколения не влияет на файлы в более поздних резервных копиях, а удаляет только жесткие ссылки. На диске занято полное резервное копирование + смены поколений. В идеале вы можете хранить много недель / месяцев резервных копий в зависимости от доступного пространства и того, сколько изменений в вашем наборе данных.
Мы используем комбинацию rsync и Рабочая группа JungleDisk для архивирования / резервного копирования нашего сайта и его файлов. Это довольно простая установка и не слишком дорогая, но первая синхронизация займет много времени.
я использую двуличие для резервного копирования на S3. Я выбираю целевые каталоги так, что делаю полные раз в квартал и увеличиваю каждую ночь. (При двуличности это так же просто, как выбор нового каталога назначения один раз в квартал).
Кроме того, я периодически восстанавливаю один или два файла, чтобы убедиться, что резервные копии не повреждены.
Мы используем BackupPC
Сейчас мой сайт невелик. Я вношу изменения локально и копирую файлы на сервер. Я использую SVN локально для сохранения большей части контента и копирования файлов bin (как на изображениях) в папки архива. Итак, это довольно просто и несущественно. Также, если я потеряю эти данные, их несложно восстановить или просто обновить изображения.
С данными у меня есть сценарий bash, который выполняет резервное копирование моей базы данных sql на сервере, и другой сценарий локально, который входит в систему с помощью ssh и извлекает резервные копии. Полностью автоматический (cron + оконный планировщик задач). Итак, все, что мне нужно беспокоиться, это заполнится ли мой сайт (мой сайт отправит мне письмо по электронной почте, прежде чем это произойдет), сменил ли я изображение, а не сделаю резервную копию, и если я забыл зарегистрировать свой новый код в SVN.
мне нравиться
s3cmd (http://s3tools.org/s3cmd)
Его довольно легко установить (Debian: apt-get install s3cmd).
Для хранения файлов на S3 вам потребуется учетная запись Amazon AWS. Затем простая команда может запустить вашу резервную копию, даже инкрементную или как решение для синхронизации, например:
s3cmd sync /srv/backup s3://your-bucket-name-at-amazon/
Убедитесь, что вы бежите
s3cms --configure
сначала введите свои учетные данные AWS.
Я написал этот небольшой сценарий, чтобы сделать именно то, о чем вы говорите.
Автоматические ежедневные резервные копии веб-каталогов и баз данных mysql с шифрованием des3, и все эти файлы элегантно отображаются в вашем веб-браузере.
Скриншот: http://i.stack.imgur.com/CC82a.png
Вы можете настроить веб-каталог и имя пользователя mysql, а также сколько дней хранить старые резервные копии.
Скачать здесь:
