🥇Inkrementell VDS-sikkerhetskopi med et nettsted på 1C-Bitrix i Yandex.Cloud

Det var nødvendig for meg å sikkerhetskopiere nettstedet til 2C-Bitrix: Site Management 1 ganger om dagen (filer og mysql-database) og lagre en endringshistorikk i 90 dager.

Siden er plassert på en VDS som kjører CentOS 7 med "1C-Bitrix: Web Environment" installert. Ta i tillegg en sikkerhetskopi av OS-innstillingene.

krav:

Frekvens - 2 ganger om dagen;
Oppbevar kopier for de siste 90 dagene;
Evnen til å få individuelle filer for en bestemt dato, om nødvendig;
Sikkerhetskopien må lagres i et annet datasenter enn VDS;
Muligheten til å få tilgang til sikkerhetskopien fra hvor som helst (en annen server, lokal datamaskin, etc.).

Et viktig poeng var muligheten til raskt å lage sikkerhetskopier med minimalt forbruk av ekstra plass og systemressurser.

Dette handler ikke om et øyeblikksbilde for en rask gjenoppretting av hele systemet, men om filer og databasen og endringshistorikken.

Innledende data:

VDS på XEN-virtualisering;
OS CentOS 7;
1C-Bitrix: Webmiljø;
Nettsted basert på "1C-Bitrix: Site Management", standardversjon;
Filstørrelsen er 50 GB og vil vokse;
Databasestørrelsen er 3 GB og vil vokse.

Standard sikkerhetskopiering innebygd i 1C-Bitrix - ekskludert umiddelbart. Den er kun egnet for små nettsteder, fordi:

Lager en komplett kopi av siden hver gang, henholdsvis hver kopi vil ta like mye plass som jeg tar opp filene, i mitt tilfelle er det 50 GB.
Sikkerhetskopiering gjøres ved hjelp av PHP, noe som er umulig med slike volumer av filer, det vil overbelaste serveren og vil aldri ta slutt.
Og selvfølgelig kan det ikke være snakk om noen 90 dager når du lagrer en full kopi.

Løsningen som hosteren tilbyr er en backup-disk plassert i samme datasenter som VDS, men på en annen server. Du kan jobbe med disken via FTP og bruke dine egne skript, eller hvis ISPManager er installert på VDS, deretter gjennom backupmodulen. Dette alternativet er ikke egnet på grunn av bruken av samme datasenter.

Fra alle de ovennevnte er det beste valget for meg en inkrementell sikkerhetskopi i henhold til mitt eget scenario i Yandex.Cloud (Object Storage) eller Amazon S3 (Amazon Simple Storage Service).

Dette krever:

root-tilgang til VDS;
installert duplicity-verktøy;
konto i Yandex.Cloud.

inkrementell backup - en metode der kun data som er endret siden siste sikkerhetskopiering arkiveres.

dobbelthet - et sikkerhetskopieringsverktøy som bruker rsync-algoritmer og kan fungere med Amazon S3.

Yandex.Cloud vs Amazon S3

Det er ingen forskjell mellom Yandex.Cloud og Amazon S3 i dette tilfellet for meg. Yandex støtter hoveddelen av Amazon S3 API, slik at du kan jobbe med den ved å bruke løsningene som er tilgjengelige for arbeid med S3. I mitt tilfelle er dette duplisitetsverktøyet.

Den største fordelen med Yandex kan være betaling i rubler, hvis det er mye data, vil det ikke være noen kobling til kurset. Når det gjelder hastighet, fungerer Amazons europeiske datasentre i forhold til russiske i Yandex, for eksempel kan du bruke Frankfurt. Jeg brukte tidligere Amazon S3 til lignende oppgaver, nå bestemte jeg meg for å prøve Yandex.

Sette opp Yandex.Cloud

1. Du må opprette en faktureringskonto i Yandex.Cloud. For å gjøre dette må du logge på Yandex.Cloud via Yandex-kontoen din eller opprette en ny.

2. Lag sky.

3. I "Cloud" oppretter du en "Catalog".

4. Opprett en "Servicekonto" for "Katalog".

5. Opprett nøkler for "Servicekonto".

6. Behold nøklene, du vil trenge dem i fremtiden.

7. For "Catalog" oppretter du en "Bucket", filer vil falle inn i den.

8. Jeg anbefaler å sette en grense og velge "Kjøllagring".

Sette opp planlagte sikkerhetskopier på serveren

Denne veiledningen forutsetter grunnleggende administrative ferdigheter.

1. Installer duplicity-verktøyet på VDS

yum install duplicity

2. Opprett en mappe for mysql-dumper, i mitt tilfelle er det /backup_db i VDS-roten

3. Opprett en mappe for bash-skript /backup_scripts og lag det første skriptet som vil sikkerhetskopiere /backup_scripts/backup.sh

Skriptinnhold:

#!`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. Kjør skriptet for første gang og sjekk resultatet, filene skal vises i bøtten.

`which bash` /backup_scripts/backup.sh

5. Legg til et skript til cron for at root-brukeren skal kjøres 2 ganger om dagen, eller så ofte du trenger.

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

Datagjenoppretting fra Yandex.Cloud

1. Lag en gjenopprettingsmappe /backup_restore

2. Lag bash restore script /backup_scripts/restore.sh

Jeg gir det mest etterspurte eksemplet på å gjenopprette en bestemt fil:

#!`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. Kjør skriptet og vent på resultatet.

`which bash` /backup_scripts/backup.sh

I /backup_restore/-mappen finner du index.php-filen som tidligere var inkludert i sikkerhetskopien.

Du kan gjøre finere justeringer for å passe dine behov.

minus dobbelthet

Duplisitet har én ulempe - det er ingen måte å sette en grense for kanalbruk. Med en vanlig kanal skaper ikke dette noe problem, men med en DDoS-beskyttet kanal med hastighet per dag fakturering vil jeg gjerne kunne sette en grense på 1-2 megabit.

Som en konklusjon

Sikkerhetskopiering i Yandex.Cloud eller Amazon S3 gir en uavhengig kopi av nettstedet og OS-innstillingene som kan nås fra enhver annen server eller lokal datamaskin. Samtidig er ikke denne kopien synlig verken i vertskontrollpanelet eller i Bitrix adminpanel, noe som gir ekstra sikkerhet.

I det mest uheldige utfallet kan du bygge en ny server og distribuere nettstedet for enhver dato. Selv om den mest etterspurte funksjonaliteten vil være muligheten til å få tilgang til filen for en bestemt dato.

Du kan bruke denne teknikken med alle VDS- eller dedikerte servere og nettsteder på alle motorer, ikke bare 1C-Bitrix. OS kan også være annet enn CentOS, for eksempel Ubuntu eller Debian.

Kilde: www.habr.com

Inkrementell VDS-sikkerhetskopi med et nettsted på 1C-Bitrix i Yandex.Cloud

Yandex.Cloud vs Amazon S3

Sette opp Yandex.Cloud

Sette opp planlagte sikkerhetskopier på serveren

Datagjenoppretting fra Yandex.Cloud

Som en konklusjon

Legg til en kommentar Avbryt svar