ProHoster > blog > administratie > Incrementele VDS-back-up met een site op 1C-Bitrix in Yandex.Cloud

Incrementele VDS-back-up met een site op 1C-Bitrix in Yandex.Cloud

Ik moest twee keer per dag een backup maken van de site op “2C-Bitrix: Site Management” (bestanden en MySQL-database) en de geschiedenis van de wijzigingen 1 dagen bewaren.

De site bevindt zich op een VDS met CentOS 7 en "1C-Bitrix: Web Environment" geïnstalleerd. Maak daarnaast een back-up van de OS-instellingen.

vereisten:

  • Frequentie: 2 keer per dag;
  • Bewaar kopieën van de laatste 90 dagen;
  • De mogelijkheid om indien nodig individuele bestanden voor een specifieke datum op te halen;
  • De back-up moet worden opgeslagen in een ander datacentrum dan de VDS;
  • De mogelijkheid om overal toegang te hebben tot de back-up (een andere server, een lokale computer, enz.).

Een belangrijk punt was de mogelijkheid om snel back-ups te maken met minimaal gebruik van extra ruimte en systeembronnen.

Het gaat hierbij niet om een ​​momentopname om snel het hele systeem te herstellen, maar specifiek om bestanden en de database en de geschiedenis van wijzigingen.

Initiële data:

  • VDS op XEN-virtualisatie;
  • Besturingssysteem CentOS 7;
  • 1C-Bitrix: Webomgeving;
  • Website gebaseerd op "1C-Bitrix: Site Management", Standaardversie;
  • De bestandsgrootte is 50 GB en zal toenemen;
  • De omvang van de database bedraagt ​​3 GB en zal nog toenemen.

Standaardback-up ingebouwd in 1C-Bitrix — direct uitgesloten. Alleen geschikt voor kleine sites, omdat:

  • Maakt iedere keer een volledige kopie van de site, dus iedere kopie neemt evenveel ruimte in beslag als de bestanden; in mijn geval is dat 50 GB.
  • De back-up wordt gemaakt met behulp van PHP, wat bij zulke grote bestanden onmogelijk is. Het overbelast de server en de back-up wordt nooit voltooid.
  • En uiteraard kan er bij het bewaren van een complete kopie geen sprake zijn van 90 dagen.

De oplossing die biedt hosterDit is een back-upschijf die zich in hetzelfde datacenter bevindt als de VDS, maar op een andere server. U kunt de schijf benaderen via FTP en uw eigen scripts gebruiken, of, als ISPManager op de VDS is geïnstalleerd, via de back-upmodule ervan. Deze optie is niet geschikt omdat deze hetzelfde datacenter gebruikt.

Uit alle bovenstaande overwegingen lijkt mij een incrementele back-up, met behulp van mijn eigen scenario in Yandex.Cloud (Object Storage) of Amazon S3 (Amazon Simple Storage Service), de beste keuze.

Dit vereist:

  • root-toegang tot VDS;
  • geïnstalleerd dupliciteitshulpprogramma;
  • account in Yandex.Cloud.

Incrementele back-up — een methode waarbij alleen gegevens worden gearchiveerd die zijn gewijzigd sinds de laatste back-up.

dubbelhartigheid — een back-uphulpprogramma dat gebruikmaakt van rsync-algoritmen en kan werken met Amazon S3.

Yandex.Cloud versus Amazon S3

Er is in dit geval voor mij geen verschil tussen Yandex.Cloud en Amazon S3. Yandex ondersteunt het hoofdonderdeel van de Amazon S3 API, dus je kunt ermee werken met de oplossingen die er zijn voor S3. In mijn geval is dat het hulpprogramma Duplicity.

Het belangrijkste voordeel van Yandex is misschien wel de betaling in roebels. Als er veel data is, is er geen koppeling met de wisselkoers. Qua snelheid werken de Europese datacenters van Amazon vergelijkbaar met die van Rusland in Yandex; je kunt bijvoorbeeld Frankfurt gebruiken. Ik gebruikte voorheen Amazon S3 voor vergelijkbare taken, maar nu heb ik besloten om Yandex te proberen.

Yandex.Cloud instellen

1. Je moet een betaalaccount aanmaken in Yandex.Cloud. Hiervoor moet je inloggen op Yandex.Cloud via je Yandex-account of een nieuw account aanmaken.

2. Creëer een "Cloud".
Incrementele VDS-back-up met een site op 1C-Bitrix in Yandex.Cloud

3. Maak een "Catalogus" aan in de "Cloud".
Incrementele VDS-back-up met een site op 1C-Bitrix in Yandex.Cloud

4. Maak voor de 'Catalogus' een 'Serviceaccount' aan.
Incrementele VDS-back-up met een site op 1C-Bitrix in Yandex.Cloud

5. Maak sleutels voor het "Service Account".
Incrementele VDS-back-up met een site op 1C-Bitrix in Yandex.Cloud

6. Bewaar de sleutels, u heeft ze later nodig.
Incrementele VDS-back-up met een site op 1C-Bitrix in Yandex.Cloud

7. Maak voor de 'Catalogus' een 'Bucket' waarin de bestanden worden geplaatst.
Incrementele VDS-back-up met een site op 1C-Bitrix in Yandex.Cloud

8. Ik raad aan om een ​​limiet in te stellen en 'Cold Storage' te selecteren.
Incrementele VDS-back-up met een site op 1C-Bitrix in Yandex.Cloud

Geplande back-ups instellen op de server

Voor deze handleiding wordt ervan uitgegaan dat u over basisvaardigheden in administratie beschikt.

1. Installeer het Duplicity-hulpprogramma op VDS

yum install duplicity

2. Maak een map voor mysql dumps, in mijn geval is dat /backup_db in de root van de VDS

3. Maak een map voor bash-scripts /backup_scripts en maak het eerste script dat de back-up zal uitvoeren /backup_scripts/backup.sh

Inhoud van het script:

#!`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. Voer het script voor de eerste keer uit en controleer het resultaat; bestanden zouden in de 'Bucket' moeten verschijnen.

`which bash` /backup_scripts/backup.sh

Incrementele VDS-back-up met een site op 1C-Bitrix in Yandex.Cloud

5. Voeg een script toe aan cron dat de rootgebruiker twee keer per dag kan uitvoeren, of met de frequentie die u nodig hebt.

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

Gegevensherstel van Yandex.Cloud

1. Maak een herstelmap /backup_restore

2. Maak een bash-script voor herstel /backup_scripts/restore.sh

Ik geef het meest populaire voorbeeld van het herstellen van een specifiek bestand:

#!`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. Voer het script uit en wacht op het resultaat.

`which bash` /backup_scripts/backup.sh

In de map /backup_restore/ vindt u het bestand index.php dat eerder in de back-up was opgenomen.

U kunt de instellingen verder verfijnen om ze aan te passen aan uw behoeften.

Minus dubbelhartigheid

Duplicity heeft één nadeel: er is geen mogelijkheid om een ​​limiet in te stellen op het kanaalgebruik. Met een regulier kanaal is dit geen probleem, maar bij gebruik van een kanaal met DDoS-beveiliging en dagelijkse snelheidsfacturering zou ik graag een limiet van 1-2 megabit willen kunnen instellen.

Als conclusie

Door een back-up te maken naar Yandex.Cloud of Amazon S3 krijgt u een onafhankelijke kopie van uw website en besturingssysteeminstellingen die toegankelijk is vanaf elke andere server of lokale computer. Deze kopie is voor niemand zichtbaar. controle panelen noch via hosting, noch via het Bitrix-beheerpaneel, dat extra beveiliging biedt.

In het ergste geval kunt u een nieuwe server samenstellen en de site voor elke gewenste datum implementeren. De meest populaire functionaliteit zal echter de mogelijkheid zijn om een ​​bestand voor een specifieke datum te openen.

Deze methode kan worden gebruikt met elke VDS of dedicated servers en sites op elke engine, niet alleen 1C-Bitrix. Het besturingssysteem kan ook anders zijn dan CentOS, bijvoorbeeld Ubuntu of Debian.

Bron: www.habr.com