1 / 26

Резервное копирование: нужно ли делать бэкапы , как часто, сценарии использования

Резервное копирование: нужно ли делать бэкапы , как часто, сценарии использования. Александр Демидов «1С-Битрикс». Исследование Strategic Research Institute. 30% предпринимателей после утраты данных прекращают предпринимательскую деятельность в течение года.

ashanti
Télécharger la présentation

Резервное копирование: нужно ли делать бэкапы , как часто, сценарии использования

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Резервное копирование: нужно ли делать бэкапы, как часто, сценарии использования Александр Демидов «1С-Битрикс»

  2. Исследование Strategic Research Institute • 30% предпринимателей после утраты данных прекращают предпринимательскую деятельность в течение года. • 60% предпринимателей, потерявших ВСЕ данные, прекращают предпринимательскую деятельность в течение 6 месяцев после этого. Не забывайте «сохраняться»

  3. Общие принципы Для разных сценариев сбоев – разные бэкапы Нужно бэкапить файлы и базу данных Это нужно делать постоянно, а не перед аварией  Нужно бэкапитьконфиги и настройки серверов и софта Полезно проводить учения по восстановлению системы Нужно уметь восстанавливаться быстро и уверенно Восстановление можно частично автоматизировать

  4. Лишь 1 из 10 сайтов имеет «правильный» бэкап Изолированность Целостность Версионность Безопасность

  5. Бэкап базы данных Репликация – не бэкап. Но может выполнить некоторые его функции (например, при использовании pt-slave-delay). Для восстановления целого сервера БД в случае аварии используем образ машин со всеми дисками – делаем целостный бэкапRAID’а, используя файловую систему, поддерживающую freeze и механизм snapshot’ов. Логические (mysqldump) и бинарные инкрементальные (Xtrabackup) бэкапы используются для восстановления отдельных баз или таблиц, поврежденных в случае некорректных операций в системе или ошибок пользователей. Второй тип бэкапов делается на выделенном slave, на который не распределяется общая нагрузка. Тем самым ресурсоемкие операции создания бэкапов не влияют на работу пользователей.

  6. Бэкапфайлов – традиционно: tar + gz/bz2: Есть везде Элементарный скрипт напишет любой программист Каждый раз полный бэкап, большие объемы Есть псевдо-инкрементальный бэкап. Он неудобный Много мелких файлов - проблемы Если не SSD, то тормозят прочие дисковые операции Достать один файл - распаковывать все

  7. Альтернативы rsync csync2 lsyncd rdiff-backup csync2 + inotify + самописные скрипты bacula И т.д.

  8. Нюансы *sync* - не бэкапы, в «зеркало» контента Как и в случае с базой, могут использоваться для создания резервных копий (чтобы не делать этого на «бою»)

  9. inotify Defaults /proc/sys/fs/inotify/max_user_watches 8192 /proc/sys/fs/inotify/max_user_instances 128 /proc/sys/fs/inotify/max_queued_events 16384

  10. Как делать бэкапRAID? Для Amazon EC2 есть удобный механизм snapshot’ов. Как сделать целостный бэкапRAIDиз нескольких дисков? А лучше – всей машины в целом Используем файловую систему, поддерживающую freeze (xfs, утилита xfs_freeze; или на новых ядрах Linux и ext3/ext4 и механизм fsfreeze). Делаем freeze файловой системы (в случае MySQL правильно предварительно сделать FLUSH TABLES WITH READ LOCK). Делаем снэпшоты всех дисков. «Размораживаем» файловую систему. Для бэкапа файлов – достаточно, но если хотим быстро и удобно переезжать между AZ (Availability Zones), используем более высокий уровень абстракции и оперируем образами целых машин – AMI (Amazon Machine Image).

  11. Где хранить бэкап? • Облачные хранилища (например, Amazon S3) • Доступность – 99.99% • Надежность – 99.999999999% • ACL • Шифрование (server-side, client-side) • Версионность • Резервирование собственными средствами

  12. «Глубина» хранения • По одному на день • Еженедельный • Ежемесячный

  13. Дополнительно - Glacier

  14. Мониторинг всех процессов бэкапов Лог работы скрипта (>) – обновился за N часов Лог ошибокработы скрипта (2>)– должен быть пуст

  15. Как упростить процесс? Безопасность: унестинадругойдиск, сервер, к другомупровайдеру. Раньшедлясозданиярезервнойкопиибылонужно: заключитьдоговор с провайдером, настроить, развернутьбэкап. С облачнымбэкапомдоговоровненужно, настроекненужно, а бэкапсразусохраняется в облаке «1С-Битрикс».

  16. Облачный бэкап Каждому лицензионному ключу бесплатно выделяется место в облаке (в зависимости от редакции). Хранение бэкапа в облаке «1С-Битрикс» полностью безопасно. У нас нет доступа к этим данным.

  17. Безопасность в облаке Облако 1С-Битрикс Пароль архива Шифрование blowfish Бэкап restore.php

  18. Как настроить автоматический бэкап Если сайт работает на собственном окружении Настроить выполнение агентов на cron, запуская каждую минуту/bitrix/modules/main/tools/cron_events.php ИЛИ Поставить на нужное время задачу на cron на запуск/bitrix/modules/main/tools/backup.php

  19. Как работает автоматический бэкап cron cron_events.php почта агенты время X backup.php

  20. Если обновлены до 14 версии

  21. Облако 1С-Битрикс Независимость от провайдерасайт легко перенести Надежностьданные многократно резервируются в облаке Доступностьв любом месте можете развернуть бэкап Простотане требуется заключать договор с провайдером, не требуется настройка Безопасностьваши данные шифруются, даже сотрудники 1С-Битрикс не имеют к ним доступа

  22. Бэкап настроек и конфигурации системного ПО Система контроля версий etckeeper Образы машин с «чистой» конфигурацией RPM-пакеты Chef и т.п.

  23. Резюме Имея правильно спроектированную систему резервного копирования, а также отлаженные процессы работы с резервными копиями, можно быстро восстановить работоспособность проекта или отдельных его элементов, даже в случае критических сбоев, в том числе с потерей данных.

  24. Спасибо за внимание! Вопросы? Александр Демидов demidov@1c-bitrix.ru +7-926-521-3700 @demidov http://www.1c-bitrix.ru

More Related