🥇Papildoma VDS atsarginė kopija naudojant svetainę 1C-Bitrix sistemoje Yandex.Cloud

Man reikėjo 2 kartus per dieną sukurti atsarginę svetainės kopiją į 1C-Bitrix: Site Management (failai ir mysql duomenų bazė) ir saugoti pakeitimų istoriją 90 dienų.

Svetainė yra VDS, kuriame veikia CentOS 7 ir įdiegta „1C-Bitrix: Web Environment“. Be to, pasidarykite atsarginę OS nustatymų kopiją.

reikalavimai:

Dažnumas - 2 kartus per dieną;
Saugoti kopijas paskutines 90 dienų;
Galimybė prireikus gauti atskirus failus konkrečiai datai;
Atsarginė kopija turi būti saugoma kitame nei VDS duomenų centre;
Galimybė pasiekti atsarginę kopiją iš bet kurios vietos (kito serverio, vietinio kompiuterio ir pan.).

Svarbus momentas buvo galimybė greitai sukurti atsargines kopijas sunaudojant minimalų papildomos vietos ir sistemos išteklių.

Tai ne apie momentinį vaizdą, kad būtų galima greitai atkurti visą sistemą, bet apie failus ir duomenų bazę bei pakeitimų istoriją.

Pradiniai duomenys:

VDS ant XEN virtualizacijos;
OS CentOS 7;
1C-Bitrix: žiniatinklio aplinka;
Svetainė, pagrįsta „1C-Bitrix: Site Management“, standartinė versija;
Failo dydis yra 50 GB ir augs;
Duomenų bazės dydis yra 3 GB ir augs.

Į 1C-Bitrix integruota standartinė atsarginė kopija – iš karto neįtraukiama. Jis tinka tik mažoms svetainėms, nes:

Kiekvieną kartą padaro pilną svetainės kopiją, atitinkamai kiekviena kopija užims tiek vietos, kiek aš užimu failus, mano atveju tai yra 50 GB.
Atsarginė kopija daroma naudojant PHP, kas su tokiais failų kiekiais neįmanoma, tai perkraus serverį ir niekada nesibaigs.
Ir, žinoma, negali būti nė kalbos apie 90 dienų, kai saugoma visa kopija.

Prieglobos serverio siūlomas sprendimas yra atsarginis diskas, esantis tame pačiame duomenų centre kaip ir VDS, bet kitame serveryje. Galite dirbti su disku per FTP ir naudoti savo scenarijus arba, jei ISPManager yra įdiegtas VDS, tada per jo atsarginį modulį. Ši parinktis netinka, nes naudojamas tas pats duomenų centras.

Iš visų aukščiau pateiktų dalykų man geriausias pasirinkimas yra atsarginė kopija pagal mano paties scenarijų Yandex.Cloud (Object Storage) arba Amazon S3 (Amazon Simple Storage Service).

Tam reikia:

root prieiga prie VDS;
įdiegta duplicity programa;
paskyra Yandex.Cloud.

laipsniškas atsarginis kopijavimas - metodas, kai archyvuojami tik duomenys, kurie pasikeitė nuo paskutinės atsarginės kopijos.

dviveidiškumas - atsarginė priemonė, kuri naudoja rsync algoritmus ir gali dirbti su Amazon S3.

„Yandex.Cloud“ prieš „Amazon S3“.

Man šiuo atveju nėra jokio skirtumo tarp Yandex.Cloud ir Amazon S3. „Yandex“ palaiko pagrindinę „Amazon S3“ API dalį, todėl galite dirbti su ja naudodamiesi sprendimais, kurie yra dirbantys su S3. Mano atveju tai yra dvilypumo programa.

Pagrindinis „Yandex“ pranašumas gali būti mokėjimas rubliais, jei yra daug duomenų, nuorodos į kursą nebus. Kalbant apie greitį, „Amazon“ Europos duomenų centrai veikia proporcingai su rusiškais „Yandex“, pavyzdžiui, galite naudoti Frankfurtą. Anksčiau panašioms užduotims naudojau „Amazon S3“, dabar nusprendžiau išbandyti „Yandex“.

„Yandex.Cloud“ nustatymas

1. Turite sukurti atsiskaitomąją paskyrą „Yandex.Cloud“. Norėdami tai padaryti, turite prisijungti prie „Yandex.Cloud“ naudodami „Yandex“ paskyrą arba sukurti naują.

2. Sukurkite debesį.

3. „Debesyje“ sukurkite „Katalogą“.

4. „Katalogui“ sukurkite „Paslaugos paskyrą“.

5. „Paslaugos paskyrai“ sukurkite raktus.

6. Išsaugokite raktus, jų prireiks ateityje.

7. „Katalogui“ sukurkite „kibirą“, failai pateks į jį.

8. Rekomenduoju nustatyti limitą ir pasirinkti „Šaltasis sandėlis“.

Suplanuotų atsarginių kopijų nustatymas serveryje

Šiame vadove pateikiami pagrindiniai administraciniai įgūdžiai.

1. Įdiekite duplicity įrankį VDS

yum install duplicity

2. Sukurkite aplanką mysql dumps, mano atveju jis yra /backup_db VDS šaknyje

3. Sukurkite aplanką bash scenarijams /backup_scripts ir sukurkite pirmąjį scenarijų, kurio atsarginė kopija bus sukurta /backup_scripts/backup.sh

Scenarijaus turinys:

#!`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. Pirmą kartą paleiskite scenarijų ir patikrinkite rezultatą, failai turėtų pasirodyti kišene.

`which bash` /backup_scripts/backup.sh

5. Pridėkite scenarijų prie cron, kad root naudotojas būtų vykdomas 2 kartus per dieną arba taip dažnai, kaip jums reikia.

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

Duomenų atkūrimas iš Yandex.Cloud

1. Sukurkite atkūrimo aplanką /backup_restore

2. Padarykite bash atkūrimo scenarijų /backup_scripts/restore.sh

Pateikiu labiausiai pageidaujamą konkretaus failo atkūrimo pavyzdį:

#!`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. Paleiskite scenarijų ir laukite rezultato.

`which bash` /backup_scripts/backup.sh

Aplanke /backup_restore/ rasite failą index.php, kuris anksčiau buvo įtrauktas į atsarginę kopiją.

Galite atlikti smulkesnius pakeitimus, kad atitiktų jūsų poreikius.

atėmus dviveidiškumą

Duplicity turi vieną trūkumą – nėra galimybės nustatyti kanalo naudojimo limito. Su normaliu kanalu tai nesukelia problemų, bet su DDoS apsaugotu kanalu su spartos per dieną atsiskaitymu, norėčiau, kad būtų galima nustatyti 1-2 megabitų limitą.

Kaip išvada

Atsarginės kopijos kūrimas „Yandex.Cloud“ arba „Amazon S3“ suteikia nepriklausomą svetainės ir OS nustatymų kopiją, kurią galima pasiekti iš bet kurio kito serverio ar vietinio kompiuterio. Tuo pačiu metu šios kopijos nematyti nei prieglobos valdymo skydelyje, nei Bitrix administratoriaus skydelyje, o tai suteikia papildomą saugumą.

Labiausiai apgailėtinu atveju galite sukurti naują serverį ir įdiegti svetainę bet kuriai datai. Nors labiausiai pageidaujama funkcija bus galimybė pasiekti failą tam tikrai datai.

Šią techniką galite naudoti su bet kokiu VDS arba skirtu serveriu ir svetainėmis bet kuriuose varikliuose, ne tik 1C-Bitrix. OS taip pat gali būti ne „CentOS“, pvz., „Ubuntu“ arba „Debian“.

Šaltinis: www.habr.com

Papildoma VDS atsarginė kopija naudojant svetainę 1C-Bitrix sistemoje Yandex.Cloud

„Yandex.Cloud“ prieš „Amazon S3“.

„Yandex.Cloud“ nustatymas

Suplanuotų atsarginių kopijų nustatymas serveryje

Duomenų atkūrimas iš Yandex.Cloud

Kaip išvada

Добавить комментарий Atšaukti atsakymą