🥇Inkrementel backup af VDS med et websted på 1C-Bitrix i Yandex.Cloud

Det var nødvendigt for mig at tage backup af webstedet til 2C-Bitrix: Site Management 1 gange om dagen (filer og mysql-database) og gemme en historik over ændringer i 90 dage.

Siden er placeret på en VDS, der kører CentOS 7 med "1C-Bitrix: Web Environment" installeret. Derudover skal du lave en sikkerhedskopi af OS-indstillingerne.

Krav:

Frekvens - 2 gange om dagen;
Gem kopier for de sidste 90 dage;
Evnen til at få individuelle filer til en bestemt dato, hvis det er nødvendigt;
Sikkerhedskopien skal opbevares i et andet datacenter end VDS;
Muligheden for at få adgang til sikkerhedskopien fra hvor som helst (en anden server, lokal computer osv.).

Et vigtigt punkt var muligheden for hurtigt at lave backups med minimalt forbrug af ekstra plads og systemressourcer.

Det handler ikke om et øjebliksbillede til en hurtig gendannelse af hele systemet, men om filer og databasen og historikken for ændringer.

Indledende data:

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

Standard backup indbygget i 1C-Bitrix - ekskluderet med det samme. Det er kun egnet til små steder, fordi:

Laver en komplet kopi af siden hver gang, henholdsvis hver kopi vil fylde lige så meget som jeg optager filerne, i mit tilfælde er det 50 GB.
Sikkerhedskopiering udføres ved hjælp af PHP, hvilket er umuligt med sådanne mængder af filer, det vil overbelaste serveren og vil aldrig ende.
Og selvfølgelig kan der ikke være tale om nogen 90 dage, når en fuld kopi opbevares.

Løsningen, der tilbyder værtDette er en backupdisk, der er placeret i samme datacenter som VDS'en, men på en anden server. Du kan tilgå disken via FTP og bruge dine egne scripts, eller, hvis ISPManager er installeret på VDS'en, via dens backupmodul. Denne mulighed er ikke egnet, da den bruger det samme datacenter.

Fra alt det ovenstående er det bedste valg for mig en trinvis sikkerhedskopiering i henhold til mit eget scenario i Yandex.Cloud (Object Storage) eller Amazon S3 (Amazon Simple Storage Service).

Dette kræver:

root-adgang til VDS;
installeret dobbeltfunktionsværktøj;
konto i Yandex.Cloud.

trinvis backup - en metode, hvor kun data, der er ændret siden sidste sikkerhedskopiering, arkiveres.
dobbelthed - et backupværktøj, der bruger rsync-algoritmer og kan arbejde med Amazon S3.

Yandex.Cloud vs Amazon S3

Der er ingen forskel mellem Yandex.Cloud og Amazon S3 i dette tilfælde for mig. Yandex understøtter hoveddelen af Amazon S3 API, så du kan arbejde med det ved hjælp af de løsninger, der er tilgængelige til at arbejde med S3. I mit tilfælde er dette dobbelthedsværktøjet.

Den største fordel ved Yandex kan være betaling i rubler, hvis der er mange data, vil der ikke være noget link til kurset. Hastighedsmæssigt fungerer Amazons europæiske datacentre i forhold til russiske i Yandex, for eksempel kan du bruge Frankfurt. Jeg brugte tidligere Amazon S3 til lignende opgaver, nu besluttede jeg at prøve Yandex.

Opsætning af Yandex.Cloud

1. Du skal oprette en faktureringskonto i Yandex.Cloud. For at gøre dette skal du logge ind på Yandex.Cloud via din Yandex-konto eller oprette en ny.

2. Opret sky.

3. I "Cloud" opret et "Katalog".

4. Til "Katalog" skal du oprette en "Servicekonto".

5. Opret nøgler til "Servicekonto".

6. Gem nøglerne, du får brug for dem i fremtiden.

7. For "Katalog" oprette en "Bucket", vil filer falde ind i det.

8. Jeg anbefaler at sætte en grænse og vælge "Cold Storage".

Opsætning af planlagte sikkerhedskopier på serveren

Denne vejledning antager grundlæggende administrative færdigheder.

1. Installer duplicity-værktøjet på VDS'en

yum install duplicity

2. Opret en mappe til mysql-dumps, i mit tilfælde er det /backup_db i VDS-roden

3. Opret en mappe til bash-scripts /backup_scripts og lav det første script, der tager backup af /backup_scripts/backup.sh

Script indhold:

#!`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 scriptet for første gang og tjek resultatet, filerne skulle vises i Bucket.

`which bash` /backup_scripts/backup.sh

5. Tilføj et script til cron, så root-brugeren kan udføres 2 gange om dagen, eller så ofte du har brug for det.

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

Datagendannelse fra Yandex.Cloud

1. Lav en gendannelsesmappe /backup_restore

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

Jeg giver det mest efterspurgte eksempel på gendannelse af 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 scriptet og vent på resultatet.

`which bash` /backup_scripts/backup.sh

I mappen /backup_restore/ finder du filen index.php, som tidligere var inkluderet i sikkerhedskopien.

Du kan lave finere justeringer, så de passer til dine behov.

minus dobbelthed

Duplicity har én ulempe - der er ingen måde at sætte en kanalbrugsgrænse på. Med en normal kanal giver det ikke noget problem, men med en DDoS-beskyttet kanal med hastighed per dag fakturering vil jeg gerne kunne sætte en grænse på 1-2 megabit.

Som konklusion

Sikkerhedskopiering til Yandex.Cloud eller Amazon S3 giver en uafhængig kopi af dit websted og dine operativsystemindstillinger, som kan tilgås fra enhver anden server eller lokal computer. Denne kopi er ikke synlig for nogen. kontrolpaneler hosting, og heller ikke i Bitrix-administrationspanelet, som giver ekstra sikkerhed.

I det mest uheldige resultat kan du bygge en ny server og implementere webstedet til enhver dato. Selvom den mest efterspurgte funktionalitet vil være muligheden for at få adgang til filen for en bestemt dato.

Du kan bruge denne teknik med alle VDS- eller dedikerede servere og websteder på alle motorer, ikke kun 1C-Bitrix. OS kan også være andet end CentOS, såsom Ubuntu eller Debian.

Kilde: www.habr.com