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

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

Ο ιστότοπος βρίσκεται σε ένα 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 ημέρες κατά την αποθήκευση ενός πλήρους αντιγράφου.

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

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

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

  • πρόσβαση root στο VDS;
  • εγκατεστημένο βοηθητικό πρόγραμμα διπλής όψης;
  • λογαριασμό στο Yandex.Cloud.

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

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

Yandex.Cloud έναντι Amazon S3

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

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

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

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

2. Δημιουργήστε ένα "Σύννεφο".
Αυξητική δημιουργία αντιγράφων ασφαλείας 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. Συνιστώ να ορίσετε ένα όριο και να επιλέξετε "Ψυκτική Αποθήκευση".
Αυξητική δημιουργία αντιγράφων ασφαλείας VDS με ιστότοπο στο 1C-Bitrix στο Yandex.Cloud

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

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

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

yum install duplicity

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

3. Δημιουργήστε έναν φάκελο για τα bash scripts /backup_scripts και δημιουργήστε το πρώτο script που θα εκτελέσει το αντίγραφο ασφαλείας /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. Προσθέστε ένα script στο cron για να εκτελείται από τον χρήστη root δύο φορές την ημέρα ή με τη συχνότητα που χρειάζεστε.

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

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

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

2. Δημιουργήστε ένα bash script για το recovery /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 ή Dedicated servers και sites σε οποιαδήποτε μηχανή αναζήτησης, όχι μόνο 1C-Bitrix. Το λειτουργικό σύστημα μπορεί επίσης να διαφέρει από το CentOS, για παράδειγμα Ubuntu ή Debian.

Πηγή: www.habr.com