Inkrementalna sigurnosna kopija VDS-a s web-lokacijom na 1C-Bitrixu u Yandex.Cloud

Bilo mi je potrebno da napravim rezervnu kopiju sajta na 2C-Bitrix: Upravljanje sajtom 1 puta dnevno (fajlovi i mysql baza podataka) i pohranim istoriju promena 90 dana.

Stranica se nalazi na VDS-u koji koristi CentOS 7 sa instaliranim "1C-Bitrix: Web Environment". Osim toga, napravite sigurnosnu kopiju postavki OS-a.

Uslovi:

• Učestalost - 2 puta dnevno;
• Čuvajte kopije u posljednjih 90 dana;
• Mogućnost dobijanja pojedinačnih fajlova za određeni datum, ako je potrebno;
• Sigurnosna kopija mora biti pohranjena u podatkovnom centru koji nije VDS;
• Mogućnost pristupa sigurnosnoj kopiji s bilo kojeg mjesta (drugi server, lokalni računar, itd.).

Važna stvar bila je mogućnost brzog kreiranja rezervnih kopija uz minimalnu potrošnju dodatnog prostora i sistemskih resursa.

Ovdje se ne radi o snimku za brzo vraćanje cijelog sistema, već o datotekama i bazi podataka i historiji promjena.

Početni podaci:

• VDS na XEN virtuelizaciji;
• OS CentOS 7;
• 1C-Bitrix: Web okruženje;
• Sajt baziran na "1C-Bitrix: Upravljanje sajtom", Standardna verzija;
• Veličina datoteke je 50 GB i raste;
• Veličina baze podataka je 3 GB i rasti će.

Standardna sigurnosna kopija ugrađena u 1C-Bitrix - odmah isključena. Pogodan je samo za male lokacije, jer:

• Svaki put pravi kompletnu kopiju sajta, odnosno svaka kopija zauzima onoliko prostora koliko ja zauzimam fajlove, u mom slučaju to je 50 GB.
• Backup se radi pomoću PHP-a, što je nemoguće sa ovakvim količinama fajlova, preopteretiti će server i nikada se neće završiti.
• I naravno, ne može biti govora ni o kakvim 90 dana kada se čuva puna kopija.

Rješenje koje hoster nudi je backup disk koji se nalazi u istom podatkovnom centru kao i VDS, ali na drugom serveru. Sa diskom možete raditi preko FTP-a i koristiti vlastite skripte, ili ako je ISPManager instaliran na VDS, onda preko njegovog backup modula. Ova opcija nije prikladna zbog korištenja istog podatkovnog centra.

Od svega navedenog, najbolji izbor za mene je inkrementalna sigurnosna kopija prema mom scenariju u Yandex.Cloud (Object Storage) ili Amazon S3 (Amazon Simple Storage Service).

Ovo zahtijeva:

• root pristup VDS-u;
• instaliran uslužni program za dupličnost;
• račun u Yandex.Cloud.

inkrementalni backup - metoda u kojoj se arhiviraju samo podaci koji su promijenjeni od posljednje sigurnosne kopije.

duplicity - uslužni program za pravljenje rezervnih kopija koji koristi rsync algoritme i može raditi sa Amazon S3.

Yandex.Cloud vs Amazon S3

Za mene u ovom slučaju nema razlike između Yandex.Clouda i Amazon S3. Yandex podržava glavni dio Amazon S3 API-ja, tako da možete raditi s njim koristeći rješenja koja su dostupna za rad sa S3. U mom slučaju, ovo je uslužni program za dupličnost.

Glavna prednost Yandexa može biti plaćanje u rubljama, ako ima puno podataka, onda neće biti veze na kurs. Što se tiče brzine, Amazonovi evropski podatkovni centri rade srazmjerno ruskim u Yandexu, na primjer, možete koristiti Frankfurt. Prethodno sam koristio Amazon S3 za slične zadatke, sada sam odlučio isprobati Yandex.

Postavljanje Yandex.Clouda

1. Morate kreirati račun za naplatu u Yandex.Cloud. Da biste to učinili, morate se prijaviti na Yandex.Cloud putem svog Yandex računa ili kreirati novi.

2. Kreirajte oblak.


3. U "Cloud" kreirajte "Katalog".


4. Za "Katalog" kreirajte "Servisni nalog".


5. Za "Servisni račun" kreirajte ključeve.


6. Sačuvajte ključeve, trebat će vam u budućnosti.


7. Za "Katalog" kreirajte "Bucket", fajlovi će pasti u njega.


8. Preporučujem da postavite ograničenje i odaberete "Cold Storage".

Postavljanje planiranih rezervnih kopija na serveru

Ovaj vodič pretpostavlja osnovne administrativne vještine.

1. Instalirajte uslužni program za dupličnost na VDS

yum install duplicity

2. Kreirajte folder za mysql dumpove, u mom slučaju to je /backup_db u korijenu VDS-a

3. Kreirajte folder za bash skripte /backup_scripts i napravite prvu skriptu koja će napraviti sigurnosnu kopiju /backup_scripts/backup.sh

Sadržaj skripte:

#!`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. Pokrenite skriptu po prvi put i provjerite rezultat, fajlovi bi se trebali pojaviti u Bucket-u.

`which bash` /backup_scripts/backup.sh

5. Dodajte skriptu u cron da se root korisnik izvršava 2 puta dnevno, ili onoliko često koliko vam je potrebno.

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

Oporavak podataka iz Yandex.Cloud

1. Napravite folder za vraćanje /backup_restore

2. Napravite bash skriptu za vraćanje /backup_scripts/restore.sh

Dajem najtraženiji primjer oporavka određene datoteke:

#!`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. Pokrenite skriptu i pričekajte rezultat.

`which bash` /backup_scripts/backup.sh

U folderu /backup_restore/ pronaći ćete datoteku index.php koja je prethodno bila uključena u rezervnu kopiju.

Možete izvršiti finija podešavanja koja odgovaraju vašim potrebama.

minus dvoličnost

Dvostrukost ima jedan nedostatak - ne postoji način da se postavi ograničenje upotrebe kanala. Kod normalnog kanala to ne stvara problem, ali kod kanala zaštićenog od DDoS-a sa naplatom brzine po danu, želio bih da mogu postaviti ograničenje od 1-2 megabita.

Kao zaključak

Izrada sigurnosne kopije u Yandex.Cloud ili Amazon S3 pruža nezavisnu kopiju stranice i postavki OS-a kojima se može pristupiti s bilo kojeg drugog servera ili lokalnog računara. Istovremeno, ova kopija nije vidljiva ni na kontrolnom panelu hostinga ni na Bitrix admin panelu, što pruža dodatnu sigurnost.

U najnesretnijem ishodu, možete izgraditi novi server i postaviti lokaciju za bilo koji datum. Iako će najtraženija funkcionalnost biti mogućnost pristupa datoteci za određeni datum.

Ovu tehniku ​​možete koristiti sa bilo kojim VDS ili Namjenskim serverima i web lokacijama na svim mašinama, ne samo 1C-Bitrix. OS također može biti drugačiji od CentOS-a, kao što je Ubuntu ili Debian.

izvor: www.habr.com