🥇 په Yandex.Cloud کې د 1C-Bitrix ویب پاڼې سره د VDS زیاتیدونکي بیک اپ

زه اړتیا لرم چې په ورځ کې دوه ځله "2C-Bitrix: د سایټ مدیریت" (فایلونه او mysql ډیټابیس) کې د سایټ بیک اپ جوړ کړم او د 1 ورځو لپاره د بدلون تاریخ ذخیره کړم.

سایټ په VDS کې موقعیت لري چې CentOS 7 OS چلوي د 1C-Bitrix سره: ویب چاپیریال نصب شوی. سربیره پردې ، د خپل OS تنظیماتو بیک اپ کاپي جوړه کړئ.

اړتیاوې:

فریکونسی - په ورځ کې 2 ځله؛
د تیرو 90 ورځو لپاره کاپي وساتئ؛
د یوې ټاکلې نیټې لپاره د انفرادي فایلونو ترلاسه کولو وړتیا، که اړتیا وي؛
بیک اپ باید د VDS پرته بل ډیټا مرکز کې زیرمه شي؛
د هر ځای څخه بیک اپ ته د لاسرسي وړتیا (بل سرور، محلي کمپیوټر، او نور).

یو مهم ټکی د اضافي ځای او سیسټم سرچینو لږترلږه مصرف سره د ګړندي بیک اپ رامینځته کولو وړتیا وه.

دا د ټول سیسټم ګړندي کولو لپاره د سنیپ شاټ په اړه ندي ، مګر د فایلونو او ډیټابیس او د بدلون تاریخ په اړه.

لومړني معلومات:

د XEN مجازی کولو په اړه VDS؛
OS CentOS 7;
1C-Bitrix: د ویب چاپیریال؛
د "1C-Bitrix: د سایټ مدیریت" پر بنسټ ویب پاڼه، معیاري نسخه؛
د فایل اندازه 50 GB ده او وده کوي؛
د ډیټابیس اندازه 3 GB ده او وده کوي.

ما سمدلاسه په 1C-Bitrix کې جوړ شوی معیاري بیک اپ خارج کړ. دا یوازې د کوچنیو سایټونو لپاره مناسب دی، ځکه چې:

دا هر وخت د سایټ بشپړ کاپي جوړوي، نو هر کاپي به ورته ځای ونیسي لکه څنګه چې فایلونه اخلي، زما په قضیه کې دا 50 GB دی.
بیک اپ د PHP په کارولو سره ترسره کیږي، کوم چې د فایلونو دومره حجم سره ناممکن دی، دا به سرور ډیر کړي او هیڅکله به پای ته ونه رسیږي.
او البته، د بشپړ کاپي ذخیره کولو په وخت کې د 90 ورځو خبرې نشي کیدی.

هغه حل چې کوربه یې وړاندیز کوي یو بیک اپ ډیسک دی چې د VDS په څیر ورته ډیټا مرکز کې موقعیت لري ، مګر په مختلف سرور کې. تاسو کولی شئ د FTP له لارې د ډیسک سره کار وکړئ او خپل سکریپټونه وکاروئ ، یا که ISPManager په VDS کې نصب شوی وي نو بیا د دې بیک اپ ماډل له لارې. دا اختیار د ورته معلوماتو مرکز کارولو له امله مناسب نه دی.

له پورته ټولو څخه، زما لپاره غوره انتخاب په Yandex.Cloud (Object Storage) یا Amazon S3 (Amazon Simple Storage Service) کې زما د خپل سکریپټ په کارولو سره یو زیاتیدونکی بیک اپ دی.

دا اړتیا لري:

VDS ته ریښی لاسرسی؛
نصب شوي دوه اړخیزه اسانتیا؛
په Yandex.Cloud کې حساب.

زیاتیدونکي بیک اپ - یو میتود په کوم کې چې یوازې هغه معلومات چې د وروستي بیک اپ راهیسې بدل شوي آرشیف شوي.

ورته والی - د بیک اپ یوټیلیټ چې د rsync الګوریتم کاروي او کولی شي د ایمیزون S3 سره کار وکړي.

Yandex.Cloud vs Amazon S3

په دې حالت کې، زما لپاره د Yandex.Cloud او Amazon S3 ترمنځ هیڅ توپیر نشته. Yandex د ایمیزون S3 API ډیری برخه ملاتړ کوي، نو تاسو کولی شئ د S3 سره د کار کولو لپاره موجود حلونو په کارولو سره د هغې سره کار وکړئ. زما په قضیه کې، دا دوه اړخیزه ګټه ده.

د Yandex اصلي ګټه ممکن په روبل کې تادیه وي؛ که چیرې ډیری ډیټا شتون ولري، نو د تبادلې نرخ سره به هیڅ تړاو ونلري. د سرعت په شرایطو کې، د ایمیزون اروپایی ډیټا مرکزونه په Yandex کې د روسیې ډیټا مرکزونو سره پرتله کولو وړ کار کوي؛ د مثال په توګه، تاسو کولی شئ فرانکفورت وکاروئ. ما مخکې د ورته کارونو لپاره ایمیزون S3 کارولی و، اوس ما پریکړه وکړه چې د Yandex هڅه وکړم.

د Yandex.Cloud تنظیم کول

1. تاسو اړتیا لرئ په Yandex.Cloud کې د تادیې حساب جوړ کړئ. د دې کولو لپاره، تاسو اړتیا لرئ د خپل Yandex حساب له لارې Yandex.Cloud ته ننوځئ یا یو نوی جوړ کړئ.

2. یو "بادل" جوړ کړئ.

3. په "بادل" کې یو "کټالوګ" جوړ کړئ.

4. د "کتالوګ" لپاره د "خدمت حساب" جوړ کړئ.

5. د "خدمت حساب" لپاره کلیدونه جوړ کړئ.

6. کیلي خوندي کړئ، دوی به په راتلونکي کې اړین وي.

7. د "لارښود" لپاره "بالټ" جوړ کړئ، فایلونه به دې ته لاړ شي.

8. زه وړاندیز کوم چې یو حد وټاکئ او "سړه ذخیره" غوره کړئ.

په سرور کې د ټاکل شوي بیک اپ تنظیم کول

دا لارښود د ادارې لومړني مهارتونه په ګوته کوي.

1. په VDS کې د دوه اړخیزه اسانتیا نصب کړئ

yum install duplicity

2. د Mysql ډمپونو لپاره فولډر جوړ کړئ، زما په قضیه کې دا د VDS روټ کې /backup_db دی

3. د bash سکریپټونو /backup_scripts لپاره فولډر جوړ کړئ او لومړی سکریپټ جوړ کړئ چې بیک اپ ترسره کوي /backup_scripts/backup.sh

د سکریپټ منځپانګې:

#!`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. د لومړي ځل لپاره سکریپټ چل کړئ او پایله یې وګورئ؛ فایلونه باید په "بالټ" کې ښکاره شي.

`which bash` /backup_scripts/backup.sh

5. د روټ کارونکي لپاره کرون ته سکریپټ اضافه کړئ چې په ورځ کې 2 ځله چلوي، یا د هغه فریکونسۍ سره چې تاسو ورته اړتیا لرئ.

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

د Yandex.Cloud څخه ډاټا بیرته ترلاسه کول

1. د بیا رغونې فولډر جوړ کړئ /backup_restore

2. د بیا رغونې لپاره د بش سکریپټ جوړ کړئ /backup_scripts/restore.sh

زه د ځانګړي فایل بحالولو خورا مشهور مثال ورکوم:

#!`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. سکریپټ چل کړئ او پایلې ته انتظار وکړئ.

`which bash` /backup_scripts/backup.sh

په /backup_restore/ فولډر کې به تاسو د index.php فایل ومومئ چې مخکې یې بیک اپ کړی و.

تاسو کولی شئ د خپلو اړتیاو سره سم سمونونه غوره کړئ.

منفي نقل

دوه اړخیز یو نیمګړتیا لري - دا ممکنه نده چې د چینل کارولو محدودیت وټاکئ. د منظم چینل سره دا ستونزه نه رامینځته کوي ، مګر کله چې هره ورځ د سرعت چارج کولو سره د DDoS محافظت شوي چینل کاروئ ، زه غواړم د 1-2 میګابایټ حد تنظیم کړم.

د پایلې په توګه

په Yandex.Cloud یا Amazon S3 کې بیک اپ د سایټ او OS ترتیباتو یوه خپلواکه کاپي چمتو کوي چې د کوم بل سرور یا محلي کمپیوټر څخه لاسرسی کیدی شي. سربیره پردې ، دا کاپي یا د کوربه توب کنټرول پینل یا د بټریکس اډمین پینل کې نه لیدل کیږي ، کوم چې اضافي امنیت چمتو کوي.

په بدترین حالت کې، تاسو کولی شئ یو نوی سرور راټول کړئ او سایټ په هره نیټه کې ځای پرځای کړئ. که څه هم ترټولو مشهور فعالیت به د یوې ټاکلې نیټې لپاره د فایل لاسرسي وړتیا وي.

تاسو کولی شئ دا تخنیک په هر انجن کې د VDS یا وقف شوي سرورونو او سایټونو سره وکاروئ، نه یوازې 1C-Bitrix. OS ممکن د CentOS پرته بل وي، لکه Ubuntu یا Debian.

سرچینه: www.habr.com

په Yandex.Cloud کې د 1C-Bitrix ویب پاڼې سره د VDS زیاتیدونکي بیک اپ

Yandex.Cloud vs Amazon S3

د Yandex.Cloud تنظیم کول

په سرور کې د ټاکل شوي بیک اپ تنظیم کول

د Yandex.Cloud څخه ډاټا بیرته ترلاسه کول

د پایلې په توګه

Add a comment ځواب لغوه