Bilo mi je potrebno napraviti sigurnosnu kopiju stranice na 2C-Bitrix: Site Management 1 puta dnevno (datoteke i mysql baza podataka) i pohraniti povijest promjena 90 dana.
Stranica se nalazi na VDS-u koji pokreće CentOS 7 s instaliranim "1C-Bitrix: Web Environment". Osim toga, napravite sigurnosnu kopiju postavki OS-a.
Zahtjevi:
- Učestalost - 2 puta dnevno;
- Čuvajte kopije zadnjih 90 dana;
- Mogućnost dobivanja pojedinačnih datoteka 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 poslužitelj, lokalno računalo itd.).
Važna točka bila je mogućnost brzog stvaranja sigurnosnih kopija uz minimalnu potrošnju dodatnog prostora i resursa sustava.
Ovdje se ne radi o snimku za brzo vraćanje cijelog sustava, već o datotekama i bazi podataka te povijesti promjena.
Početni podaci:
- VDS na XEN virtualizaciji;
- OS CentOS 7;
- 1C-Bitrix: Web okruženje;
- Stranica temeljena na "1C-Bitrix: Upravljanje web stranicom", standardna verzija;
- Veličina datoteke je 50 GB i povećavat će se;
- 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 stranice, jer:
- Svaki put napravi potpunu kopiju stranice, odnosno svaka će kopija zauzeti onoliko prostora koliko ja zauzimam datoteka, u mom slučaju to je 50 GB.
- Backup se radi pomoću PHP-a, što je nemoguće s takvim količinama datoteka, preopteretit će poslužitelj i nikada neće završiti.
- I naravno, ne može biti govora o bilo kakvih 90 dana kada se pohranjuje puna kopija.
Rješenje koje nudi domaćinOvo je sigurnosna kopija diska koja se nalazi u istom podatkovnom centru kao i VDS, ali na drugom poslužitelju. Disku možete pristupiti putem FTP-a i koristiti vlastite skripte ili, ako je ISPManager instaliran na VDS-u, putem njegovog modula za sigurnosnu kopiju. Ova opcija nije prikladna jer koristi isti podatkovni centar.
Od svega navedenog, najbolji izbor za mene je inkrementalna sigurnosna kopija prema vlastitom scenariju u Yandex.Cloud (Object Storage) ili Amazon S3 (Amazon Simple Storage Service).
To zahtijeva:
- root pristup VDS-u;
- instaliran uslužni program za dvostrukost;
- račun u Yandex.Cloudu.
inkrementalna sigurnosna kopija - metoda u kojoj se arhiviraju samo podaci koji su promijenjeni od posljednje sigurnosne kopije.
dvoličnost - uslužni program za sigurnosno kopiranje koji koristi algoritme rsync i može raditi s Amazonom S3.
Yandex.Cloud protiv Amazon S3
Za mene u ovom slučaju nema razlike između Yandex.Clouda i Amazona 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 dvostrukost.
Glavna prednost Yandexa može biti plaćanje u rubljima, ako ima puno podataka, tada neće biti veze na tečaj. Što se tiče brzine, Amazonovi europski podatkovni centri rade razmjerno 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 stvoriti račun za naplatu u Yandex.Cloudu. Da biste to učinili, morate se prijaviti na Yandex.Cloud putem svog Yandex računa ili stvoriti novi.
2. Stvorite oblak.

3. U "Cloudu" kreirajte "Katalog".

4. Za "Katalog" kreirajte "Uslužni račun".

5. Za "Uslužni račun" kreirajte ključeve.

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

7. Za "Katalog" kreirajte "Kušicu", datoteke će pasti u nju.

8. Preporučujem postavljanje ograničenja i odabir "Hladno skladištenje".

Postavljanje planiranih sigurnosnih kopija na poslužitelju
Ovaj vodič podrazumijeva osnovne administrativne vještine.
1. Instalirajte uslužni program duplicity na VDS
yum install duplicity2. Napravite mapu za mysql ispise, u mom slučaju to je /backup_db u korijenu VDS-a
3. Napravite mapu za bash skripte /backup_scripts i napravite prvu skriptu koja će sigurnosno kopirati /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;
fi4. Pokrenite skriptu prvi put i provjerite rezultat, datoteke bi se trebale pojaviti u spremniku.
`which bash` /backup_scripts/backup.sh
5. Dodajte skriptu u cron za root korisnika koja će se izvršavati 2 puta dnevno ili koliko god je potrebno.
10 4,16 * * * `which bash` /backup_scripts/backup.shOporavak podataka iz Yandex.Clouda
1. Napravite mapu za vraćanje /backup_restore
2. Napravi 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_KEY3. Pokrenite skriptu i pričekajte rezultat.
`which bash` /backup_scripts/backup.shU mapi /backup_restore/ pronaći ćete datoteku index.php koja je prethodno bila uključena u sigurnosnu kopiju.
Možete napraviti finije prilagodbe prema svojim potrebama.
minus duplicity
Dvostrukost ima jedan nedostatak - ne postoji način da se postavi ograničenje korištenja kanala. S normalnim kanalom to ne stvara problem, ali s DDoS zaštićenim kanalom s naplatom brzine po danu, volio bih postaviti ograničenje od 1-2 megabita.
Kao zaključak
Sigurnosno kopiranje na Yandex.Cloud ili Amazon S3 pruža neovisnu kopiju postavki vaše web stranice i operativnog sustava kojima se može pristupiti s bilo kojeg drugog poslužitelja ili lokalnog računala. Ova kopija nije vidljiva nikome. upravljačke ploče hostinga, niti u Bitrix administratorskoj ploči, koja pruža dodatnu sigurnost.
U najnesretnijem ishodu, možete izgraditi novi poslužitelj i postaviti web mjesto za bilo koji datum. Iako će najtraženija funkcija biti mogućnost pristupa datoteci za određeni datum.
Ovu tehniku možete koristiti s bilo kojim VDS ili namjenskim poslužiteljima i stranicama na svim motorima, ne samo 1C-Bitrix. OS također može biti različit od CentOS-a, kao što je Ubuntu ili Debian.
Izvor: www.habr.com
