Incremental VDS tergum cum situs in 1C-Bitrix in Yandex.Cloud

Mihi opus est ut tergum situs in "2C-Bitrix: Site Management" (lima et mysql database) bis in die condere historiam mutationum per XC dies.

Situm in VDS currentem CentOS 7 OS cum 1C-Bitrix situm est: Interretialis Ambitus inauguratus est. Accedit, exemplum tergum fac occasus tui OS.

requisita:

• Frequentia - 2 times in day;
• Codices proximis XC diebus servant;
• Facultas obtinendi singulas tabulas ad certum diem, si opus sit;
• Tergum reponendum est in centrum datae praeter VDS;
• Facultas ad tergum alicunde accedere (alicui servo, locali computatori, etc.).

Magni momenti erat facultas tergum creandi cum minima consummatione spatii accessionis et subsidiorum systematis.

Hoc non est de snapshot cito systema totum restituendi, sed de files et datorum et historiarum mutationum.

Notitia initialis:

• VDS on XEN virtualization;
• OS CentOS 7;
• 1C-Bitrix: Ambitus interreti;
• Site based on "1C-Bitrix: Site Management", Standard version;
• Tabella magnitudo 50 GB et crescet;
• Magnitudo datorum 3 GB est et crescet.

Vexillum tergum in 1C-Bitrix constructum statim exclusi. Exiguis locis idoneus est, quod;

• Plenum exemplum situs omni tempore facit, uterque exemplar tantumdem spatii capiet quantum tabulae sumendae, in casu meo 50 GB.
• Tergum factum est utens PHP, quod cum talibus voluminibus imaginum impossibile est, hoc servo onerare et numquam finire potest.
• Et sane non potest esse sermo de ullis XC diebus in pleno exemplari actarum.

Solutio hostiarius offert orbis tergum in eodem centri notitia posito quod VDS est, sed in alio servo. Cum disco per FTP laborare potes et scriptis tuis utere, aut si ISPManager in VDS inauguratus est, per eius moduli tergum. Haec optio non convenit ex usu centri eiusdem notitiae.

Ex omnibus supradictis, optima electio mihi est incremental tergum utens scripto proprio in Yandex.Cloud (Object Storage) vel Amazon S3 (Amazon Simple Storage Service).

Hoc postulat;

• radix aditum VDS;
• inauguratus est duplicitatis utilitas;
• rationem apud Yandex.Cloud.

Incremental tergum - methodus in qua sola notitia quae mutata est cum novissimum tergum scrinium est.

fallaciaeque - utilitas tergum, qua rsync algorithmis utitur et cum Amazonibus S3. operari potest.

Yandex.Cloud vs Amazon S3

Nihil interest inter Yandex.Cloud and Amazon S3 in hoc casu pro me. Yandex Amazonum S3 API molem sustinet, ut cum ea operari potes utens solutionibus quae ad operandum cum S3 existunt. In me, haec est utilitas duplicitatis.

Praecipua utilitas Yandex mercedem in rublis esse potest, si data est sors, nulla nexus erit ad commutationem rate. Secundum velocitatem, Amazonum centra Europaea data operant comparabiles cum centris Russicis in Yandex, exempli gratia, Francofurto uti potes. Ego antea ad similia opera S3 Amazonia usus sum, nunc Yandex experiri decrevi.

Yandex.Cloud eriges

1. In Yandex.Cloud mercedem rationem creare debes. Hoc facere, debes Yandex.Cloud per tuum Yandex rationem vel novam creare.

2. Nubes crea.


3. In "Nube" creo "Catalogus".


4. Nam "Catalogus" creare "Servitium rationem".


5. Nam "Ratio Muneris" claves creant.


6. Serva claves, eas in futuro indigebis.


7. Pro "Catalogo" creare "Situla", fasciculi in illud cadent.


8. Commendo terminum constituendum et "Cold Repono".

Occasus tergum sursum profecta in calculonis servi

Hic dux basic artes administrationis assumit.

1. Instrue in VDS duplicitatis utilitatem

yum install duplicity

2. Facere folder pro mysql dumps, in casu meo est /backup_db in radice VDS

3. Facere folder pro bash scriptorum /backup_scripts et fac primum scriptum quod faciet tergum /backup_scripts/backup.sh

Scriptor contentus:

#!`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. Scriptum primum curre et eventum deprime, lima in "Situla" apparebit.

`which bash` /backup_scripts/backup.sh

5. Scriptum cron addere pro usuario radicis ad currendum 2 vicibus in die, vel cum frequentia debes.

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

Recuperandae notitia ex Yandex.Cloud

1. Fac restituo folder / backup_restore

2. Fac vercundus restituet litteras /backup_scripts/restitue.sh

Gratiam maxime do exemplo limae specificae restituendae:

#!`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. Curre scriptum et expecta exitum.

`which bash` /backup_scripts/backup.sh

In /backup_restore/ folder invenies index.php lima quae antea subnixa erat.

Recommodationes melius facere potes ad usus tuos aptandos.

minus duplicitate

Duplicitas unum incommodum habet - modus non est modus ut canalis usus. Cum canali regulari hoc problema non creat, sed cum canali DDoS protecto utens velociter per diem incurrens, limes 1-2 megabitarum imponere posse velim.

Conclusio

Tergum in Yandex.Cloud or Amazon S3 praebet exemplar sui iuris situs et OS occasus qui accedere possunt ab aliquo alio servo vel computatrum locali. Hoc autem exemplum non apparet vel in panelli potestate obnoxius vel in tabula admin Bitrix, quae securitatem tutiores praebet.

Pessimo in casu missionis, convenire potes novum cultorem et quovis tempore locum explicas. Quamvis popularis functionis facultas erit accessurum fasciculum ad certum diem.

Hac arte uti potes cum quibusvis VDS vel Dedicatis servitoribus ac sitibus in quibusvis machinis, non 1C-Bitrix. Potest etiam esse OS alius quam CentOS, ut Ubuntu vel Debian.

Source: www.habr.com