Tôi cần tạo bản sao lưu trang web trên “2C-Bitrix: Quản lý trang web” (tệp và cơ sở dữ liệu mysql) hai lần một ngày và lưu trữ lịch sử thay đổi trong 1 ngày.
Trang web được đặt trên VDS chạy hệ điều hành CentOS 7 với 1C-Bitrix: Môi trường web được cài đặt. Ngoài ra, hãy tạo một bản sao lưu cài đặt hệ điều hành của bạn.
Yêu cầu:
- Tần suất - 2 lần một ngày;
- Giữ bản sao trong 90 ngày qua;
- Khả năng lấy các tệp riêng lẻ cho một ngày cụ thể, nếu cần thiết;
- Bản sao lưu phải được lưu trữ ở trung tâm dữ liệu không phải VDS;
- Khả năng truy cập bản sao lưu từ mọi nơi (máy chủ khác, máy tính cục bộ, v.v.).
Một điểm quan trọng là khả năng tạo bản sao lưu nhanh chóng với mức tiêu thụ tối thiểu không gian bổ sung và tài nguyên hệ thống.
Đây không phải là một ảnh chụp nhanh để khôi phục nhanh chóng toàn bộ hệ thống mà là về các tệp, cơ sở dữ liệu cũng như lịch sử các thay đổi.
Dữ liệu nguồn:
- VDS về ảo hóa XEN;
- Hệ điều hành CentOS 7;
- 1C-Bitrix: Môi trường web;
- Trang web dựa trên “1C-Bitrix: Quản lý trang web”, Phiên bản tiêu chuẩn;
- Kích thước tệp là 50 GB và sẽ tăng lên;
- Kích thước cơ sở dữ liệu là 3 GB và sẽ tăng lên.
Tôi ngay lập tức loại trừ bản sao lưu tiêu chuẩn được tích hợp trong 1C-Bitrix. Nó chỉ phù hợp cho các trang web nhỏ, bởi vì:
- Nó tạo một bản sao đầy đủ của trang web mọi lúc, vì vậy mỗi bản sao sẽ chiếm cùng một dung lượng như các tệp chiếm, trong trường hợp của tôi là 50 GB.
- Việc sao lưu được thực hiện bằng PHP, điều này là không thể với khối lượng tệp như vậy, nó sẽ làm quá tải máy chủ và sẽ không bao giờ hoàn tất.
- Và tất nhiên, không thể nói đến 90 ngày nào khi lưu trữ một bản sao đầy đủ.
Giải pháp mà nhà cung cấp dịch vụ lưu trữ đưa ra là một đĩa sao lưu nằm trong cùng trung tâm dữ liệu với VDS, nhưng trên một máy chủ khác. Bạn có thể làm việc với đĩa qua FTP và sử dụng các tập lệnh của riêng mình hoặc nếu ISPManager được cài đặt trên VDS thì thông qua mô-đun sao lưu của nó. Tùy chọn này không phù hợp do sử dụng cùng một trung tâm dữ liệu.
Từ tất cả những điều trên, lựa chọn tốt nhất đối với tôi là sao lưu gia tăng bằng cách sử dụng tập lệnh của riêng tôi trong Yandex.Cloud (Object Storage) hoặc Amazon S3 (Amazon Simple Storage Service).
Điều này yêu cầu:
- quyền truy cập root vào VDS;
- cài đặt tiện ích trùng lặp;
- tài khoản trong Yandex.Cloud.
Sao lưu gia tăng — một phương pháp trong đó chỉ những dữ liệu đã thay đổi kể từ lần sao lưu cuối cùng mới được lưu trữ.
trùng lặp — một tiện ích sao lưu sử dụng thuật toán rsync và có thể hoạt động với Amazon S3.
Yandex.Cloud so với Amazon S3
Trong trường hợp này, đối với tôi không có sự khác biệt giữa Yandex.Cloud và Amazon S3. Yandex hỗ trợ phần lớn API của Amazon S3 nên bạn có thể làm việc với nó bằng cách sử dụng các giải pháp hiện có để làm việc với S3. Trong trường hợp của tôi, đây là tiện ích trùng lặp.
Ưu điểm chính của Yandex có thể là thanh toán bằng rúp, nếu có nhiều dữ liệu thì sẽ không có mối liên hệ nào với tỷ giá hối đoái. Về tốc độ, các trung tâm dữ liệu châu Âu của Amazon hoạt động tương đương với các trung tâm dữ liệu Yandex của Nga; ví dụ: bạn có thể sử dụng Frankfurt. Trước đây tôi đã sử dụng Amazon S3 cho các tác vụ tương tự, bây giờ tôi quyết định dùng thử Yandex.
Thiết lập Yandex.Cloud
1. Bạn cần tạo tài khoản thanh toán trong Yandex.Cloud. Để thực hiện việc này, bạn cần đăng nhập vào Yandex.Cloud thông qua tài khoản Yandex của mình hoặc tạo một tài khoản mới.
2. Tạo một "Đám mây".
3. Trong “Đám mây” tạo một “Danh mục”.
4. Đối với “Danh mục”, hãy tạo một “tài khoản dịch vụ”.
5. Tạo khóa cho “Tài khoản dịch vụ”.
6. Hãy lưu lại chìa khóa, chúng sẽ cần thiết trong tương lai.
7. Đối với “Thư mục”, hãy tạo một “Nhóm”, các tập tin sẽ được đưa vào đó.
8. Tôi khuyên bạn nên đặt giới hạn và chọn “Kho lưu trữ lạnh”.
Thiết lập sao lưu theo lịch trình trên máy chủ
Hướng dẫn này giả định các kỹ năng quản trị cơ bản.
1. Cài đặt tiện ích nhân bản trên VDS
yum install duplicity2. Tạo một thư mục cho các kết xuất mysql, trong trường hợp của tôi là /backup_db trong thư mục gốc VDS
3. Tạo một thư mục cho các tập lệnh bash /backup_scripts và tạo tập lệnh đầu tiên sẽ thực hiện sao lưu /backup_scripts/backup.sh
Nội dung kịch bản:
#!`which bash`
# /backup_scripts/backup.sh
# Это условие проверяет не идёт ли в данный момент процесс резервного копирования, если идёт, то на email отправляется сообщение об ошибке (этот блок можно не использовать)
if [ -f /home/backup_check.mark ];
then
DATE_TIME=`date +"%d.%m.%Y %T"`;
/usr/sbin/sendmail -t <<EOF
From:backup@$HOSTNAME
To:<Ваш EMAIL>
Subject:Error backup to YANDEX.CLOUD
Content-Type:text/plain; charset=utf-8
Error backup to YANDEX.CLOUD
$DATE_TIME
EOF
else
# Основной блок отвечающий за резервное копирование
# Если нет ощибки ставим метку и запускаем backup
echo '' > /home/backup_check.mark;
# Удаляем файлы с дампами базы оставшиеся от предыдущего backup
/bin/rm -f /backup_db/*
# Делаем дамп всех mysql баз, предполагается что доступ добавлен в файле /root/.my.cnf
DATETIME=`date +%Y-%m-%d_%H-%M-%S`;
`which mysqldump` --quote-names --all-databases | `which gzip` > /backup_db/DB_$DATETIME.sql.gz
# Добавляем данные для отправки в Яндекс.
export PASSPHRASE=<Придумайте пароль для шифрования архива>
export AWS_ACCESS_KEY_ID=<Идентификатор ключа полученный у Яндекса>
export AWS_SECRET_ACCESS_KEY=<Секретный ключ полученный у Яндекса>
# Запускаем duplicity для резервирования необходимых папок на сервере.
# Данная команда будет создавать полный backup раз в месяц и до следующего месяца добавлять инкрементальные к нему
# -- exclude это папки, которые нужно исключить, я исключаю все папки с кешем битрикса
# --include папки которые нужно резервировать в моём случае это:
# - /backup_db
# - /home
# - /etc
# s3://storage.yandexcloud.net/backup , backup это имя созданного выше бакета
# Техническая особенность и значения некоторых параметров:
# Две строки "--exclude='**'" и "/" нужны, чтобы можно было выше оперировать --include и --exclude для разных папок. Эти две строчки сначала добавляют в бэкап весь сервер "/", потом исключают его "--exclude='**'"
# --full-if-older-than='1M' - создавать полную копию каждый месяц
# --volsize='512' - максимальный размер каждого из файлов в бэкапе в мегабайтах
# --log-file='/var/log/duplicity.log' - куда писать лог файл
`which duplicity`
--s3-use-ia --s3-european-buckets
--s3-use-new-style
--s3-use-multiprocessing
--s3-multipart-chunk-size='128'
--volsize='512'
--no-print-statistics
--verbosity=0
--full-if-older-than='1M'
--log-file='/var/log/duplicity.log'
--exclude='**/www/bitrix/backup/**'
--exclude='**/www/bitrix/cache/**'
--exclude='**/www/bitrix/cache_image/**'
--exclude='**/www/bitrix/managed_cache/**'
--exclude='**/www/bitrix/managed_flags/**'
--exclude='**/www/bitrix/stack_cache/**'
--exclude='**/www/bitrix/html_pages/*/**'
--exclude='**/www/bitrix/tmp/**'
--exclude='**/www/upload/tmp/**'
--exclude='**/www/upload/resize_cache/**'
--include='/backup_db'
--include='/home'
--include='/etc'
--exclude='**'
/
s3://storage.yandexcloud.net/backup
# Данная команда нужна для чистки.
# Она оставляет 3 последних полных backup и ассоциированных с ними инкрементальных backup.
# Т.о. у меня остаются backup за 3 месяца, т.к. первая команда каждый месяц делает новый полный backup
`which duplicity` remove-all-but-n-full 3 --s3-use-ia --s3-european-buckets --s3-use-new-style --verbosity=0 --force s3://storage.yandexcloud.net/backup
unset PASSPHRASE
unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY
# Удаляем метку об идущем backup
/bin/rm -f /home/backup_check.mark;
fi4. Chạy tập lệnh lần đầu tiên và kiểm tra kết quả, các tập tin sẽ xuất hiện trong “Bucket”.
`which bash` /backup_scripts/backup.sh
5. Thêm tập lệnh vào cron để người dùng root chạy 2 lần một ngày hoặc với tần suất bạn cần.
10 4,16 * * * `which bash` /backup_scripts/backup.shKhôi phục dữ liệu từ Yandex.Cloud
1. Tạo thư mục khôi phục /backup_restore
2. Tạo tập lệnh bash để khôi phục /backup_scripts/restore.sh
Tôi đưa ra ví dụ phổ biến nhất về việc khôi phục một tệp cụ thể:
#!`which bash`
export PASSPHRASE=<Пароль для шифрования архива используемый при бэкапе>
export AWS_ACCESS_KEY_ID=<Идентификатор ключа полученный у Яндекса>
export AWS_SECRET_ACCESS_KEY=<Секретный ключ полученный у Яндекса>
# 3 примера, раскомментировать нужный
# Получить статус backup
#`which duplicity` collection-status s3://storage.yandexcloud.net/backup
# Восстановить index.php из корня сайта
#`which duplicity` --file-to-restore='home/bitrix/www/index.php' s3://storage.yandexcloud.net/backup /backup_restore/index.php
# Восстановить index.php из корня сайта 3х дневной давности
#`which duplicity` --time='3D' --file-to-restore='home/bitrix/www/index.php' s3://storage.yandexcloud.net/backup /backup_restore/index.php
unset PASSPHRASE
unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY3. Chạy script và chờ kết quả.
`which bash` /backup_scripts/backup.shTrong thư mục /backup_restore/ bạn sẽ tìm thấy tệp index.php đã được sao lưu trước đó.
Bạn có thể thực hiện các điều chỉnh tốt hơn để phù hợp với nhu cầu của mình.
Trừ sự trùng lặp
tính trùng lặp có một nhược điểm - không thể đặt giới hạn sử dụng kênh. Với kênh thông thường, điều này không gây ra vấn đề gì, nhưng khi sử dụng kênh được bảo vệ DDoS với tính năng sạc tốc độ mỗi ngày, tôi muốn có thể đặt giới hạn 1-2 megabit.
Là một kết luận
Sao lưu trong Yandex.Cloud hoặc Amazon S3 cung cấp một bản sao độc lập của cài đặt hệ điều hành và trang web có thể được truy cập từ bất kỳ máy chủ hoặc máy tính cục bộ nào khác. Hơn nữa, bản sao này không hiển thị trong bảng điều khiển lưu trữ hoặc trong bảng quản trị Bitrix, điều này cung cấp tính bảo mật bổ sung.
Trong trường hợp xấu nhất, bạn có thể lắp ráp một máy chủ mới và triển khai trang web vào bất kỳ ngày nào. Mặc dù chức năng phổ biến nhất sẽ là khả năng truy cập tệp vào một ngày cụ thể.
Bạn có thể sử dụng kỹ thuật này với bất kỳ máy chủ và trang web VDS hoặc Chuyên dụng nào trên bất kỳ công cụ nào, không chỉ 1C-Bitrix. Hệ điều hành cũng có thể khác với CentOS, chẳng hạn như Ubuntu hoặc Debian.
Nguồn: www.habr.com