🥇Inkrementell VDS-säkerhetskopiering med en webbplats på 1C-Bitrix i Yandex.Cloud

Det var nödvändigt för mig att säkerhetskopiera webbplatsen till 2C-Bitrix: Site Management 1 gånger om dagen (filer och mysql-databas) och lagra en historik över ändringar i 90 dagar.

Webbplatsen ligger på en VDS som kör CentOS 7 med "1C-Bitrix: Web Environment" installerad. Gör dessutom en säkerhetskopia av OS-inställningarna.

krav:

Frekvens - 2 gånger om dagen;
Spara kopior för de senaste 90 dagarna;
Möjligheten att få enskilda filer för ett specifikt datum, om det behövs;
Säkerhetskopieringen måste lagras i ett annat datacenter än VDS;
Möjligheten att komma åt säkerhetskopian var som helst (en annan server, lokal dator, etc.).

En viktig punkt var möjligheten att snabbt skapa säkerhetskopior med minimal förbrukning av ytterligare utrymme och systemresurser.

Det här handlar inte om en ögonblicksbild för en snabb återställning av hela systemet, utan om filer och databasen och förändringshistoriken.

Initial data:

VDS på XEN-virtualisering;
OS CentOS 7;
1C-Bitrix: Webbmiljö;
Webbplats baserad på "1C-Bitrix: Site Management", standardversion;
Filstorleken är 50 GB och kommer att växa;
Databasstorleken är 3 GB och kommer att växa.

Standard backup inbyggd i 1C-Bitrix - utesluts omedelbart. Det är endast lämpligt för små platser, eftersom:

Gör en komplett kopia av sidan varje gång, respektive, varje kopia kommer att ta lika mycket plats som jag tar upp filerna, i mitt fall är det 50 GB.
Säkerhetskopiering görs med PHP, vilket är omöjligt med sådana volymer av filer, det kommer att överbelasta servern och kommer aldrig att ta slut.
Och naturligtvis kan det inte vara tal om några 90 dagar när en hel kopia lagras.

Lösningen som hostaren erbjuder är en backup-skiva placerad i samma datacenter som VDS, men på en annan server. Du kan arbeta med disken via FTP och använda dina egna skript, eller om ISPManager är installerat på VDS, sedan genom dess backup-modul. Det här alternativet är inte lämpligt på grund av användningen av samma datacenter.

Av allt ovanstående är det bästa valet för mig en inkrementell säkerhetskopiering enligt mitt eget scenario i Yandex.Cloud (Object Storage) eller Amazon S3 (Amazon Simple Storage Service).

Detta kräver:

root-åtkomst till VDS;
installerat duplicity-verktyg;
konto i Yandex.Cloud.

inkrementell säkerhetskopiering - en metod där endast data som har ändrats sedan den senaste säkerhetskopieringen arkiveras.

falskhet - ett säkerhetskopieringsverktyg som använder rsync-algoritmer och kan fungera med Amazon S3.

Yandex.Cloud vs Amazon S3

Det är ingen skillnad mellan Yandex.Cloud och Amazon S3 i det här fallet för mig. Yandex stöder huvuddelen av Amazon S3 API, så du kan arbeta med det med de lösningar som är tillgängliga för att arbeta med S3. I mitt fall är det här dupliceringsverktyget.

Den största fördelen med Yandex kan vara betalning i rubel, om det finns mycket data kommer det inte att finnas någon länk till kursen. Hastighetsmässigt fungerar Amazons europeiska datacenter i proportion till ryska i Yandex, till exempel kan du använda Frankfurt. Jag använde tidigare Amazon S3 för liknande uppgifter, nu bestämde jag mig för att prova Yandex.

Konfigurera Yandex.Cloud

1. Du måste skapa ett faktureringskonto i Yandex.Cloud. För att göra detta måste du logga in på Yandex.Cloud via ditt Yandex-konto eller skapa ett nytt.

2. Skapa moln.

3. Skapa en "Katalog" i "molnet".

4. Skapa ett "Servicekonto" för "Katalog".

5. Skapa nycklar för "Servicekonto".

6. Behåll nycklarna, du kommer att behöva dem i framtiden.

7. För "Katalog" skapa en "Bucket", kommer filer att falla in i den.

8. Jag rekommenderar att sätta en gräns och välja "Kylförvaring".

Konfigurera schemalagda säkerhetskopieringar på servern

Denna guide förutsätter grundläggande administrativa färdigheter.

1. Installera duplicity-verktyget på VDS

yum install duplicity

2. Skapa en mapp för mysql-dumpar, i mitt fall är det /backup_db i VDS-roten

3. Skapa en mapp för bash-skript /backup_scripts och gör det första skriptet som kommer att säkerhetskopiera /backup_scripts/backup.sh

Skriptinnehåll:

#!`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. Kör skriptet för första gången och kontrollera resultatet, filer bör visas i hinken.

`which bash` /backup_scripts/backup.sh

5. Lägg till ett skript till cron så att rootanvändaren exekveras 2 gånger om dagen, eller så ofta du behöver.

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

Dataåterställning från Yandex.Cloud

1. Skapa en återställningsmapp /backup_restore

2. Gör bash restore script /backup_scripts/restore.sh

Jag ger det mest efterfrågade exemplet på att återställa en specifik 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. Kör skriptet och vänta på resultatet.

`which bash` /backup_scripts/backup.sh

I mappen /backup_restore/ hittar du filen index.php som tidigare ingick i säkerhetskopian.

Du kan göra finare justeringar för att passa dina behov.

minus dubbelhet

Duplicity har en nackdel - det finns inget sätt att sätta en kanalanvändningsgräns. Med en vanlig kanal skapar detta inga problem, men med en DDoS-skyddad kanal med hastighet per dag debitering skulle jag vilja kunna sätta en gräns på 1-2 megabit.

Som slutsats

Säkerhetskopiering i Yandex.Cloud eller Amazon S3 ger en oberoende kopia av webbplatsen och OS-inställningar som kan nås från vilken annan server eller lokal dator som helst. Samtidigt är denna kopia inte synlig vare sig i värdkontrollpanelen eller i Bitrix adminpanel, vilket ger ytterligare säkerhet.

I det mest olyckliga resultatet kan du bygga en ny server och distribuera webbplatsen för vilket datum som helst. Även om den mest efterfrågade funktionen kommer att vara möjligheten att komma åt filen för ett visst datum.

Du kan använda denna teknik med alla VDS eller dedikerade servrar och webbplatser på alla motorer, inte bara 1C-Bitrix. OS kan också vara annat än CentOS, som Ubuntu eller Debian.

Källa: will.com

Inkrementell VDS-säkerhetskopiering med en webbplats på 1C-Bitrix i Yandex.Cloud

Yandex.Cloud vs Amazon S3

Konfigurera Yandex.Cloud

Konfigurera schemalagda säkerhetskopieringar på servern

Dataåterställning från Yandex.Cloud

Som slutsats

Lägg en kommentar Avbryt svar