🥇Sandaran tambahan VDS dengan tapak pada 1C-Bitrix dalam Yandex.Cloud

Saya perlu membuat sandaran tapak pada "2C-Bitrix: Pengurusan Tapak" (fail dan pangkalan data mysql) dua kali sehari dan menyimpan sejarah perubahan selama 1 hari.

Tapak ini terletak pada VDS yang menjalankan OS CentOS 7 dengan 1C-Bitrix: Persekitaran Web dipasang. Selain itu, buat salinan sandaran tetapan OS anda.

Keperluan:

Kekerapan - 2 kali sehari;
Simpan salinan selama 90 hari terakhir;
Keupayaan untuk mendapatkan fail individu untuk tarikh tertentu, jika perlu;
Sandaran mesti disimpan di pusat data selain VDS;
Keupayaan untuk mengakses sandaran dari mana-mana sahaja (pelayan lain, komputer tempatan, dll.).

Perkara penting ialah keupayaan untuk membuat sandaran dengan cepat dengan penggunaan ruang tambahan dan sumber sistem yang minimum.

Ini bukan tentang syot kilat untuk memulihkan keseluruhan sistem dengan cepat, tetapi mengenai fail dan pangkalan data serta sejarah perubahan.

Data awal:

VDS pada virtualisasi XEN;
OS CentOS 7;
1C-Bitrix: Persekitaran web;
Tapak web berdasarkan "1C-Bitrix: Pengurusan Tapak", versi Standard;
Saiz fail ialah 50 GB dan akan berkembang;
Saiz pangkalan data ialah 3 GB dan akan berkembang.

Saya segera mengecualikan sandaran standard yang dibina ke dalam 1C-Bitrix. Ia hanya sesuai untuk tapak kecil, kerana:

Ia membuat salinan penuh tapak setiap kali, jadi setiap salinan akan menggunakan jumlah ruang yang sama seperti yang digunakan oleh fail, dalam kes saya ia adalah 50 GB.
Sandaran dilakukan menggunakan PHP, yang mustahil dengan jumlah fail sedemikian, ia akan membebankan pelayan dan tidak akan selesai.
Dan sudah tentu, tidak boleh bercakap tentang mana-mana 90 hari apabila menyimpan salinan penuh.

Penyelesaian yang menawarkan hosterIni ialah cakera sandaran yang terletak di pusat data yang sama dengan VDS, tetapi pada pelayan yang berbeza. Anda boleh mengakses cakera melalui FTP dan menggunakan skrip anda sendiri, atau, jika ISPManager dipasang pada VDS, melalui modul sandarannya. Pilihan ini tidak sesuai kerana ia menggunakan pusat data yang sama.

Daripada semua perkara di atas, pilihan terbaik untuk saya ialah sandaran tambahan menggunakan skrip saya sendiri dalam Yandex.Cloud (Storan Objek) atau Amazon S3 (Perkhidmatan Storan Mudah Amazon).

Ini memerlukan:

akses root kepada VDS;
utiliti duplikat yang dipasang;
akaun dalam Yandex.Cloud.

Sandaran tambahan — kaedah di mana hanya data yang telah berubah sejak sandaran terakhir diarkibkan.
bermuka dua — utiliti sandaran yang menggunakan algoritma rsync dan boleh berfungsi dengan Amazon S3.

Yandex.Cloud lwn Amazon S3

Dalam kes ini, tiada perbezaan antara Yandex.Cloud dan Amazon S3 untuk saya. Yandex menyokong sebahagian besar API Amazon S3, jadi anda boleh bekerja dengannya menggunakan penyelesaian yang wujud untuk bekerja dengan S3. Dalam kes saya, ini adalah utiliti duplikat.

Kelebihan utama Yandex mungkin pembayaran dalam rubel; jika terdapat banyak data, tidak akan ada sambungan ke kadar pertukaran. Dari segi kelajuan, pusat data Eropah Amazon berfungsi setanding dengan pusat data Rusia di Yandex; sebagai contoh, anda boleh menggunakan Frankfurt. Saya sebelum ini menggunakan Amazon S3 untuk tugasan yang serupa, kini saya memutuskan untuk mencuba Yandex.

Menyediakan Yandex.Cloud

1. Anda perlu membuat akaun pembayaran dalam Yandex.Cloud. Untuk melakukan ini, anda perlu log masuk ke Yandex.Cloud melalui akaun Yandex anda atau buat yang baharu.

2. Buat "Awan".

3. Dalam "Cloud" buat "Katalog".

4. Untuk "Katalog" buat "Akaun perkhidmatan".

5. Buat kunci untuk "Akaun Perkhidmatan".

6. Simpan kunci, ia akan diperlukan pada masa akan datang.

7. Untuk "Direktori" buat "Bucket", fail akan masuk ke dalamnya.

8. Saya mengesyorkan menetapkan had dan memilih "Storan Sejuk".

Menyediakan sandaran berjadual pada pelayan

Panduan ini mengambil alih kemahiran asas pentadbiran.

1. Pasang utiliti pendua pada VDS

yum install duplicity

2. Buat folder untuk pembuangan mysql, dalam kes saya ia adalah /backup_db dalam akar VDS

3. Buat folder untuk skrip bash /backup_scripts dan buat skrip pertama yang akan melakukan backup /backup_scripts/backup.sh

Kandungan skrip:

#!`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. Jalankan skrip buat kali pertama dan semak hasilnya; fail harus muncul dalam "Badi".

`which bash` /backup_scripts/backup.sh

5. Tambahkan skrip pada cron untuk pengguna root dijalankan 2 kali sehari, atau dengan kekerapan yang anda perlukan.

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

Memulihkan data daripada Yandex.Cloud

1. Buat folder pemulihan /backup_restore

2. Buat skrip bash untuk pemulihan /backup_scripts/restore.sh

Saya memberikan contoh yang paling popular untuk memulihkan fail tertentu:

#!`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. Jalankan skrip dan tunggu hasilnya.

`which bash` /backup_scripts/backup.sh

Dalam folder /backup_restore/ anda akan menemui fail index.php yang telah disandarkan sebelum ini.

Anda boleh membuat pelarasan yang lebih halus untuk memenuhi keperluan anda.

Tolak pertindihan

duplicity mempunyai satu kelemahan - tidak mungkin untuk menetapkan had penggunaan saluran. Dengan saluran biasa ini tidak menimbulkan masalah, tetapi apabila menggunakan saluran yang dilindungi DDoS dengan pengecasan laju setiap hari, saya ingin dapat menetapkan had 1-2 megabit.

Sebagai kesimpulan

Membuat sandaran ke Yandex.Cloud atau Amazon S3 menyediakan salinan bebas tetapan laman web dan OS anda yang boleh diakses dari mana-mana pelayan atau komputer tempatan lain. Salinan ini tidak dapat dilihat oleh sesiapa pun. panel kawalan hosting, mahupun dalam panel admin Bitrix, yang menyediakan keselamatan tambahan.

Dalam senario kes terburuk, anda boleh memasang pelayan baharu dan menggunakan tapak pada bila-bila tarikh. Walaupun fungsi yang paling popular adalah keupayaan untuk mengakses fail untuk tarikh tertentu.

Anda boleh menggunakan teknik ini dengan mana-mana VDS atau pelayan dan tapak khusus pada mana-mana enjin, bukan hanya 1C-Bitrix. OS juga mungkin selain daripada CentOS, seperti Ubuntu atau Debian.

Sumber: www.habr.com