Αυξητική δημιουργία αντιγράφων ασφαλείας VDS με ιστότοπο στο 1C-Bitrix στο Yandex.Cloud

Ήταν απαραίτητο για μένα να δημιουργήσω αντίγραφα ασφαλείας του ιστότοπου στο 2C-Bitrix: Site Management 1 φορές την ημέρα (αρχεία και βάση δεδομένων mysql) και να αποθηκεύσω ένα ιστορικό αλλαγών για 90 ημέρες.

Ο ιστότοπος βρίσκεται σε ένα VDS που εκτελεί το CentOS 7 με εγκατεστημένο το "1C-Bitrix: Web Environment". Επιπλέον, δημιουργήστε ένα αντίγραφο ασφαλείας των ρυθμίσεων του λειτουργικού συστήματος.

απαιτήσεις:

  • Συχνότητα - 2 φορές την ημέρα.
  • Διατηρήστε αντίγραφα για τις τελευταίες 90 ημέρες.
  • Η δυνατότητα λήψης μεμονωμένων αρχείων για μια συγκεκριμένη ημερομηνία, εάν είναι απαραίτητο.
  • Το αντίγραφο ασφαλείας πρέπει να αποθηκευτεί σε κέντρο δεδομένων διαφορετικό από το VDS.
  • Δυνατότητα πρόσβασης στο αντίγραφο ασφαλείας από οπουδήποτε (άλλος διακομιστής, τοπικός υπολογιστής κ.λπ.).

Ένα σημαντικό σημείο ήταν η δυνατότητα γρήγορης δημιουργίας αντιγράφων ασφαλείας με ελάχιστη κατανάλωση πρόσθετου χώρου και πόρων συστήματος.

Δεν πρόκειται για ένα στιγμιότυπο για μια γρήγορη επαναφορά ολόκληρου του συστήματος, αλλά για αρχεία και τη βάση δεδομένων και το ιστορικό των αλλαγών.

Δεδομένα προέλευσης:

  • VDS για εικονικοποίηση XEN.
  • OS CentOS 7;
  • 1C-Bitrix: Περιβάλλον Ιστού.
  • Ιστότοπος που βασίζεται σε "1C-Bitrix: Διαχείριση τοποθεσίας", Τυπική έκδοση.
  • Το μέγεθος του αρχείου είναι 50 GB και θα αυξηθεί.
  • Το μέγεθος της βάσης δεδομένων είναι 3 GB και θα αυξηθεί.

Τυπικό αντίγραφο ασφαλείας ενσωματωμένο στο 1C-Bitrix - αποκλείεται αμέσως. Είναι κατάλληλο μόνο για μικρές τοποθεσίες, επειδή:

  • Κάνει ένα πλήρες αντίγραφο του ιστότοπου κάθε φορά, αντίστοιχα, κάθε αντίγραφο θα πιάνει όσο χώρο πιάνω εγώ τα αρχεία, στην περίπτωσή μου είναι 50 GB.
  • Η δημιουργία αντιγράφων ασφαλείας γίνεται με χρήση PHP, κάτι που είναι αδύνατο με τέτοιους όγκους αρχείων, θα υπερφορτώσει τον διακομιστή και δεν θα τελειώσει ποτέ.
  • Και φυσικά, δεν μπορεί να γίνει λόγος για 90 ημέρες κατά την αποθήκευση ενός πλήρους αντιγράφου.

Η λύση που προσφέρει το hoster είναι ένας δίσκος αντιγράφων ασφαλείας που βρίσκεται στο ίδιο κέντρο δεδομένων με το VDS, αλλά σε διαφορετικό διακομιστή. Μπορείτε να εργαστείτε με το δίσκο μέσω FTP και να χρησιμοποιήσετε τα δικά σας σενάρια ή εάν το ISPManager είναι εγκατεστημένο στο VDS, τότε μέσω της μονάδας δημιουργίας αντιγράφων ασφαλείας. Αυτή η επιλογή δεν είναι κατάλληλη λόγω της χρήσης του ίδιου κέντρου δεδομένων.

Από όλα τα παραπάνω, η καλύτερη επιλογή για μένα είναι ένα σταδιακό αντίγραφο ασφαλείας σύμφωνα με το δικό μου σενάριο στο Yandex.Cloud (Αποθήκευση αντικειμένων) ή στο Amazon S3 (Amazon Simple Storage Service).

Αυτό απαιτεί:

  • πρόσβαση root στο VDS.
  • εγκατεστημένο βοηθητικό πρόγραμμα duplicity?
  • λογαριασμό στο Yandex.Cloud.

σταδιακή δημιουργία αντιγράφων ασφαλείας - μια μέθοδος στην οποία αρχειοθετούνται μόνο τα δεδομένα που έχουν αλλάξει από το τελευταίο αντίγραφο ασφαλείας.

διπροσωπία - ένα βοηθητικό πρόγραμμα δημιουργίας αντιγράφων ασφαλείας που χρησιμοποιεί αλγόριθμους rsync και μπορεί να λειτουργήσει με το Amazon S3.

Yandex.Cloud εναντίον Amazon S3

Δεν υπάρχει διαφορά μεταξύ Yandex.Cloud και Amazon S3 σε αυτήν την περίπτωση για μένα. Το Yandex υποστηρίζει το κύριο μέρος του Amazon S3 API, ώστε να μπορείτε να εργαστείτε μαζί του χρησιμοποιώντας τις λύσεις που είναι διαθέσιμες για εργασία με το S3. Στην περίπτωσή μου, αυτό είναι το βοηθητικό πρόγραμμα duplicity.

Το κύριο πλεονέκτημα του Yandex μπορεί να είναι η πληρωμή σε ρούβλια, εάν υπάρχουν πολλά δεδομένα, τότε δεν θα υπάρχει σύνδεση με το μάθημα. Όσον αφορά την ταχύτητα, τα ευρωπαϊκά κέντρα δεδομένων της Amazon λειτουργούν ανάλογα με τα ρωσικά στο Yandex, για παράδειγμα, μπορείτε να χρησιμοποιήσετε τη Φρανκφούρτη. Στο παρελθόν χρησιμοποιούσα το Amazon S3 για παρόμοιες εργασίες, τώρα αποφάσισα να δοκιμάσω το Yandex.

Ρύθμιση του Yandex.Cloud

1. Πρέπει να δημιουργήσετε έναν λογαριασμό χρέωσης στο Yandex.Cloud. Για να το κάνετε αυτό, πρέπει να συνδεθείτε στο Yandex.Cloud μέσω του λογαριασμού σας Yandex ή να δημιουργήσετε έναν νέο.

2. Δημιουργία Cloud.
Αυξητική δημιουργία αντιγράφων ασφαλείας VDS με ιστότοπο στο 1C-Bitrix στο Yandex.Cloud

3. Στο "Cloud" δημιουργήστε έναν "Κατάλογο".
Αυξητική δημιουργία αντιγράφων ασφαλείας VDS με ιστότοπο στο 1C-Bitrix στο Yandex.Cloud

4. Για τον "Κατάλογο" δημιουργήστε έναν "Λογαριασμό υπηρεσίας".
Αυξητική δημιουργία αντιγράφων ασφαλείας VDS με ιστότοπο στο 1C-Bitrix στο Yandex.Cloud

5. Για το "Λογαριασμός υπηρεσίας" δημιουργήστε κλειδιά.
Αυξητική δημιουργία αντιγράφων ασφαλείας VDS με ιστότοπο στο 1C-Bitrix στο Yandex.Cloud

6. Κράτα τα κλειδιά, θα τα χρειαστείς στο μέλλον.
Αυξητική δημιουργία αντιγράφων ασφαλείας VDS με ιστότοπο στο 1C-Bitrix στο Yandex.Cloud

7. Για τον "Κατάλογο" δημιουργήστε έναν "Κάδο", τα αρχεία θα πέσουν σε αυτόν.
Αυξητική δημιουργία αντιγράφων ασφαλείας VDS με ιστότοπο στο 1C-Bitrix στο Yandex.Cloud

8. Σας συνιστώ να θέσετε ένα όριο και να επιλέξετε "Cold Storage".
Αυξητική δημιουργία αντιγράφων ασφαλείας VDS με ιστότοπο στο 1C-Bitrix στο Yandex.Cloud

Ρύθμιση προγραμματισμένων αντιγράφων ασφαλείας στον διακομιστή

Αυτός ο οδηγός προϋποθέτει βασικές διοικητικές δεξιότητες.

1. Εγκαταστήστε το βοηθητικό πρόγραμμα duplicity στο VDS

yum install duplicity

2. Δημιουργήστε έναν φάκελο για τις λωρίδες mysql, στην περίπτωσή μου είναι /backup_db στη ρίζα του VDS

3. Δημιουργήστε ένα φάκελο για σενάρια bash /backup_scripts και δημιουργήστε το πρώτο σενάριο που θα δημιουργήσει αντίγραφο ασφαλείας /backup_scripts/backup.sh

Περιεχόμενο σεναρίου:

#!`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;

fi

4. Εκτελέστε το σενάριο για πρώτη φορά και ελέγξτε το αποτέλεσμα, τα αρχεία θα πρέπει να εμφανιστούν στον Κάδο.

`which bash` /backup_scripts/backup.sh

Αυξητική δημιουργία αντιγράφων ασφαλείας VDS με ιστότοπο στο 1C-Bitrix στο Yandex.Cloud

5. Προσθέστε ένα σενάριο στο cron ώστε ο χρήστης root να εκτελείται 2 φορές την ημέρα ή όσο συχνά θέλετε.

10 4,16 * * * `which bash` /backup_scripts/backup.sh

Ανάκτηση δεδομένων από το Yandex.Cloud

1. Δημιουργήστε έναν φάκελο επαναφοράς /backup_restore

2. Δημιουργία σεναρίου επαναφοράς bash /backup_scripts/restore.sh

Δίνω το πιο ζητούμενο παράδειγμα ανάκτησης ενός συγκεκριμένου αρχείου:

#!`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_KEY

3. Εκτελέστε το σενάριο και περιμένετε το αποτέλεσμα.

`which bash` /backup_scripts/backup.sh

Στο φάκελο /backup_restore/ θα βρείτε το αρχείο index.php που περιλαμβανόταν προηγουμένως στο αντίγραφο ασφαλείας.

Μπορείτε να κάνετε πιο λεπτές προσαρμογές ανάλογα με τις ανάγκες σας.

μείον τη διπροσωπία

Η διπλοτυπία έχει ένα μειονέκτημα - δεν υπάρχει τρόπος να ορίσετε ένα όριο χρήσης καναλιού. Με ένα κανονικό κανάλι, αυτό δεν δημιουργεί πρόβλημα, αλλά με ένα κανάλι με προστασία DDoS με χρέωση ανά ημέρα, θα ήθελα να μπορώ να βάλω ένα όριο 1-2 megabit.

Σαν συμπέρασμα

Η δημιουργία αντιγράφων ασφαλείας στο Yandex.Cloud ή στο Amazon S3 παρέχει ένα ανεξάρτητο αντίγραφο των ρυθμίσεων του ιστότοπου και του λειτουργικού συστήματος που είναι προσβάσιμα από οποιονδήποτε άλλο διακομιστή ή τοπικό υπολογιστή. Ταυτόχρονα, αυτό το αντίγραφο δεν είναι ορατό ούτε στον πίνακα ελέγχου φιλοξενίας ούτε στον πίνακα διαχείρισης του Bitrix, κάτι που παρέχει πρόσθετη ασφάλεια.

Στο πιο ατυχές αποτέλεσμα, μπορείτε να δημιουργήσετε έναν νέο διακομιστή και να αναπτύξετε τον ιστότοπο για οποιαδήποτε ημερομηνία. Αν και η πιο απαιτούμενη λειτουργικότητα θα είναι η δυνατότητα πρόσβασης στο αρχείο για μια συγκεκριμένη ημερομηνία.

Μπορείτε να χρησιμοποιήσετε αυτήν την τεχνική με οποιονδήποτε VDS ή με αποκλειστικούς διακομιστές και ιστότοπους σε οποιουσδήποτε κινητήρες, όχι μόνο με 1C-Bitrix. Το λειτουργικό σύστημα μπορεί επίσης να είναι διαφορετικό από το CentOS, όπως το Ubuntu ή το Debian.

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο