Inkrementaalinen VDS-varmuuskopiointi sivustolla 1C-Bitrixissä Yandex.Cloudissa

Minun piti tehdä varmuuskopiot sivustosta "2C-Bitrix: Site Management" -sivustolla (tiedostot ja mysql-tietokanta) kahdesti päivässä ja tallentaa muutoshistoria 1 päivän ajan.

Sivusto sijaitsee VDS:ssä, jossa on CentOS 7 -käyttöjärjestelmä, johon on asennettu 1C-Bitrix: Web Environment. Tee lisäksi varmuuskopio käyttöjärjestelmän asetuksista.

vaatimukset:

• Taajuus - 2 kertaa päivässä;
• Säilytä kopiot viimeisten 90 päivän ajan;
• Mahdollisuus hankkia yksittäisiä tiedostoja tietylle päivämäärälle tarvittaessa;
• Varmuuskopio on tallennettava muuhun datakeskukseen kuin VDS:ään;
• Mahdollisuus käyttää varmuuskopiota mistä tahansa (toisesta palvelimesta, paikallisesta tietokoneesta jne.).

Tärkeä asia oli kyky luoda nopeasti varmuuskopioita minimaalisella lisätilan ja järjestelmäresurssien kulutuksella.

Tämä ei koske tilannekuvaa koko järjestelmän nopeaa palauttamista varten, vaan tiedostoista ja tietokannasta ja muutoshistoriasta.

taustaa:

• VDS XEN-virtualisoinnissa;
• käyttöjärjestelmä CentOS 7;
• 1C-Bitrix: Web-ympäristö;
• Verkkosivusto perustuu "1C-Bitrix: Site Management", vakioversioon;
• Tiedoston koko on 50 Gt ja se kasvaa;
• Tietokannan koko on 3 Gt ja se kasvaa.

Suljin heti pois 1C-Bitrixiin sisäänrakennetun vakiovarmuuskopion. Se sopii vain pienille sivustoille, koska:

• Se tekee koko kopion sivustosta joka kerta, joten jokainen kopio vie saman verran tilaa kuin tiedostot, minun tapauksessani se on 50 Gt.
• Varmuuskopiointi tehdään PHP:llä, mikä on mahdotonta sellaisilla tiedostomäärillä, se ylikuormittaa palvelinta eikä valmistu koskaan.
• Ja tietenkään ei voi puhua mistään 90 päivästä, kun koko kopio säilytetään.

Isännöitsijän tarjoama ratkaisu on varmuuskopiolevy, joka sijaitsee samassa tietokeskuksessa kuin VDS, mutta eri palvelimella. Voit työskennellä levyn kanssa FTP:n kautta ja käyttää omia skriptejäsi, tai jos ISPManager on asennettu VDS:ään, sen varmuuskopiointimoduulin kautta. Tämä vaihtoehto ei sovellu saman datakeskuksen käytön vuoksi.

Kaikista yllä olevista paras valinta minulle on asteittainen varmuuskopiointi käyttämällä omaa komentosarjaani Yandex.Cloudissa (Object Storage) tai Amazon S3:ssa (Amazon Simple Storage Service).

Tämä edellyttää:

• juuripääsy VDS:ään;
• asennettu duplicity-apuohjelma;
• tili Yandex.Cloudissa.

Inkrementaalinen varmuuskopiointi — menetelmä, jossa vain tiedot, jotka ovat muuttuneet edellisen varmuuskopion jälkeen, arkistoidaan.

kaksinaamaisuus — rsync-algoritmeja käyttävä varmuuskopio-apuohjelma, joka voi toimia Amazon S3:n kanssa.

Yandex.Cloud vs Amazon S3

Tässä tapauksessa minulle ei ole eroa Yandex.Cloudin ja Amazon S3:n välillä. Yandex tukee suurinta osaa Amazon S3 API:sta, joten voit työskennellä sen kanssa käyttämällä S3:n kanssa työskentelyyn olemassa olevia ratkaisuja. Minun tapauksessani tämä on kaksinaamaisuusapuohjelma.

Yandexin tärkein etu voi olla maksaminen ruplissa; jos tietoja on paljon, valuuttakurssiin ei ole yhteyttä. Nopeudeltaan Amazonin eurooppalaiset palvelinkeskukset toimivat verrattavissa Yandexin venäläisten palvelinkeskusten kanssa, voit käyttää esimerkiksi Frankfurtia. Käytin aiemmin Amazon S3:a vastaaviin tehtäviin, nyt päätin kokeilla Yandexia.

Yandex.Cloudin määrittäminen

1. Sinun on luotava maksutili Yandex.Cloudissa. Tätä varten sinun on kirjauduttava sisään Yandex.Cloudiin Yandex-tilisi kautta tai luotava uusi.

2. Luo "pilvi".


3. Luo "Pilvessä" "Katalogi".


4. Luo "Katalogia" varten "Palvelutili".


5. Luo avaimet "Palvelutilille".


6. Säästä avaimet, niitä tarvitaan jatkossa.


7. Luo "Hakemistolle" "Bucket", tiedostot menevät siihen.


8. Suosittelen asettamaan rajan ja valitsemaan "Kylmävarasto".

Ajoitetun varmuuskopion määrittäminen palvelimelle

Tämä opas edellyttää hallinnon perustaidot.

1. Asenna duplicity-apuohjelma VDS:ään

yum install duplicity

2. Luo kansio mysql-vedoksista, minun tapauksessani se on /backup_db VDS-juuressa

3. Luo kansio bash-skripteille /backup_scripts ja tee ensimmäinen komentosarja, joka tekee varmuuskopiot /backup_scripts/backup.sh

Käsikirjoituksen sisältö:

#!`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. Suorita skripti ensimmäistä kertaa ja tarkista tulos; tiedostojen pitäisi näkyä "Bucketissa".

`which bash` /backup_scripts/backup.sh

5. Lisää komentosarja croniin, jotta pääkäyttäjä voi suorittaa sen 2 kertaa päivässä tai tarvitsemallasi taajuudella.

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

Tietojen palauttaminen Yandex.Cloudista

1. Tee palautuskansio /backup_restore

2. Tee bash-skripti palautusta varten /backup_scripts/restore.sh

Annan suosituimman esimerkin tietyn tiedoston palauttamisesta:

#!`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. Suorita skripti ja odota tulosta.

`which bash` /backup_scripts/backup.sh

/backup_restore/-kansiosta löydät index.php-tiedoston, joka oli aiemmin varmuuskopioitu.

Voit tehdä tarkempia säätöjä tarpeidesi mukaan.

Miinus päällekkäisyys

kaksoisuudella on yksi haittapuoli - kanavan käyttörajaa ei ole mahdollista asettaa. Tavallisella kanavalla tämä ei tuota ongelmaa, mutta käytettäessä DDoS-suojattua kanavaa nopealla latauksella päivässä, haluaisin pystyä asettamaan 1-2 megabitin rajan.

Johtopäätöksenä

Varmuuskopiointi Yandex.Cloudissa tai Amazon S3:ssa tarjoaa itsenäisen kopion sivustosta ja käyttöjärjestelmän asetuksista, joita voidaan käyttää mistä tahansa muusta palvelimesta tai paikallisesta tietokoneesta. Lisäksi tämä kopio ei näy isännöinnin ohjauspaneelissa tai Bitrixin hallintapaneelissa, mikä tarjoaa lisäturvaa.

Pahimmassa tapauksessa voit koota uuden palvelimen ja ottaa sivuston käyttöön milloin tahansa. Vaikka suosituin toiminto on mahdollisuus käyttää tiedostoa tiettynä päivänä.

Voit käyttää tätä tekniikkaa minkä tahansa VDS- tai Dedicated-palvelimen ja -sivuston kanssa millä tahansa moottorilla, ei vain 1C-Bitrixissä. Käyttöjärjestelmä voi olla myös muu kuin CentOS, kuten Ubuntu tai Debian.

Lähde: will.com