Скрипти бекапа файлів з Linux в хмарні сховища (CentOS)

Не так давно, ми розміщували статтю про підключення популярних безкоштовних хмарних сховищ на сервері з CentOS 7. У цій статті ми покажемо, як можна використовувати дані сховища для резервного копіювання даних з вашого сервера. Я використовую ці скрипти для додаткового резервного копіювання файлів сайту і бази даних зі свого Linux VPS сервера.

зміст:

Backup даних на OneDrive ізLinux CentOS
Резервне копіювання на Google Диск.
Скрипт бекапу на Яндекс.Діск з Linux

Backup даних на OneDrive ізLinux CentOS

Ми будемо виконувати резервне копіювання сайту і бази даних, а також виконувати перевірку на "вік" бекапа (видаляти бекапи тижневої давності) і відправляти на пошту звіт з повною інформацією виконання скрипта. Власне, сам bash скрипт:

#! / Bin / bash # Копіюємо файли сайту в тимчасову директорію rsync -avzr --progress / var / www / html / / var / www / tmp / backup / >> result.txt # Виконуємо дамп бази, поміщаємо файл дампа в тимчасову директорію mysqldump joomla> /var/www/tmp/backup/backup.sql # Створюємо архів тимчасової директорії tar -cvzf backup - $ (date +% y% m% d) .tar.gz --absolute-names / var / www / tmp / backup / >> result.txt # Перевіряємо директорію хмари на наявність старих резервних копій, якщо такі є, видаляємо find / root / OneDrive / backup / -name "backup * .tar.gz" -mtime +7 -exec rm -f \; >> result.txt # Копіюємо створений раніше архів в хмару rsync -avzr --progress /root/bin/backup*.tar.gz / root / OneDrive / backup / >> result.txt # Видаляємо архів з директорії скрипта rm -rf /root/bin/backup*.tar.gz >> result.txt # Виконуємо синхронізацію з хмарою з прапором -local-first, що дозволить видалити старі бекапи з хмари, якщо ми їх видаляли локально і закачати нові бекапи onedrive --local-first --synchronize >> result.txt # Відправляємо лист із вкладеним файлом, де відображений весь процес резервного копіювання (замініть на свій ящик) echo "Подивіться файл на наявність помилок і виправте їх" | mail -a "/root/bin/result.txt" -s "Резервна копія створена" - ******@gmail.com # Чистимо директорії від непотрібних файлів rm -rf /root/bin/result.txt && rm -rf / var / www / tmp / backup / *

Попередньо перед написанням статті, я створив вже кілька резервних копій, щоб можна було продемонструвати, що скрипт працює коректно (видаляє старі бекапи і закачує нові).

Я запустив 3 рази вручну. Були створені кілька резервних копій, після чого вони всі успішно були відправлені в хмару:

ls -la / root / OneDrive / backup /

total 28260 drwxr-xr-x 2 root root 102 Sep 3 17:02. drwxr-xr-x 5 root root 94 Sep 3 11: 15 ... -rw-r - r-- 1 root root 9643081 Sep 3 17:00 backup-1909031700.tar.gz -rw-r - r-- 1 root root 9643082 Sep 3 17:01 backup-1909031701.tar.gz -rw-r - r-- 1 root root 9643083 Sep 3 17:02 backup-1909031702.tar.gz Initializing the Synchronization Engine ... Syncing changes from local path first before downloading changes from OneDrive ... Deleting item from OneDrive: backup / backup-1909031700.tar.gz Deleting item from OneDrive: backup / backup-1909031701.tar.gz Deleting item from OneDrive: backup / backup-1909031702.tar.gz Uploading new file ./backup/backup-1909031704.tar.gz... Uploading 100% | oooooooooooooooooooooooooooooooooooooooo | DONE IN 00:00:04 done. Processing 6 changes

Перевіряємо хмара, все три архіву з резервних копій тут:

Наступним кроком, я видалив створені резервні копії з директорії на сервері і знову запустив скрипт. Висновок вмісту директорії на сервері:

ls -la / root / OneDrive / backup /

total 9420 drwxr-xr-x 2 root root 38 Sep 3 17:04. drwxr-xr-x 5 root root 94 Sep 3 11: 15 ... -rw-r - r-- 1 root root 9643082 Sep 3 17:04 backup-1909031704.tar.gz

Пройшовши в веб-інтерфейс OneDrive я побачив, що резервні копії видалили і звідти, автоматично.

Так само після виконання скрипта, мені прийшов лист на пошту:

Ось і все, на цьому резервне копіювання на OneDrive закінчено.

Резервне копіювання на Google Диск.

З резервним копіюванням в Google Диск в се вийшло не так просто як з OneDrive, хоча сама настройка досить проста. Основна проблема виникла з видаленням старих резервних копій з Google Drive, так як на сервер не монтується директорія сховища. Але після довгого вивчення довідки drive help, вдалося модернізувати наш уже раніше використовуваний скрипт.

#! / Bin / bash # Видаляємо файли які старше 7 днів з g.drive / Usr / sbin / drive list -q "modifiedDate < '$(date -d '-7 day"+%Y-%m-%d')'" | cut -d" " -f1 - | xargs -L 1 drive delete -i rsync -avzr --progress / var / www / html / / var / www / tmp / backup / >> result.txt mysqldump joomla> /var/www/tmp/backup/backup.sql tar -cvzf backup - $ (date +% Y% m% d) .tar.gz --absolute-names / var / www / tmp / backup / >> result.txt # Закачуємо файл на g.drive / Usr / sbin / drive upload -f /root/bin/backup*.tar.gz >> result.txt rm -rf /root/bin/backup*.tar.gz >> result.txt echo "Подивіться файл на наявність помилок і виправте їх" | mail -a "/root/bin/result.txt" -s "Резервна копія створена" - ******@gmail.com rm -rf /root/bin/result.txt rm -rf / var / www / tmp / backup / *

Решта кроки в скрипті я не розписував, так як вони повторюються з попередніми.

Запустивши скрипт, він виконався:

sh backup_gdrive.sh

Removed file 'DSC_2151.NEF' Removed file 'DSC_2153.NEF' Removed file 'DSC_2159.NEF' Removed file 'DSC_2226.NEF' Removed file 'DSC_2225.NEF'

Перевіримо наявність файлу в Google Drive: drive list

Id Title Size Created 1oay3-FAWBZRjHtma1cRTLrOvf3t8hRpD backup-20190904.tar.gz 9.6 MB 2019-09-04 14:43:25

З веб-інтерфейсу його так само видно, як і з консолі:

Таким чином ми отримуємо скрипт, який виконує перевірку на наявність старих резервних копій в хмарі Google Диск, видаляє їх якщо вони потрапляють під вимоги, після чого створює резервну копію сайту і відправляє її в цей же хмара.

Скрипт бекапу на Яндекс.Діск з Linux

Дане хмарне сховище я залишив на закуску, так як резервне копіювання в Яндекс.Діск є найпростішим, тому що ми змонтували хмарне сховище Яндекс через WebDav як окреме дисковий утсройство. Спосіб все той же, ми запускаємо скрипт, тільки лише з невеликою різницею, не потрібно робити синхронізацію або заливку файлів спеціальними командами, працюємо як зі звичайним серверним каталогом. Синхронізація каталогу виконується за допомогою rsync. Скрипт буде мати вигляд:

#! / Bin / bash rsync -avzr --progress / var / www / html / / var / www / tmp / backup / >> result.txt mysqldump joomla> /var/www/tmp/backup/backup.sql tar -cvzf backup - $ (date +% Y% m% d) .tar.gz --absolute-names / var / www / tmp / backup / >> result.txt find / mnt / yad / -name "backup * .tar.gz" -mtime +7 -exec rm -f \; >> result.txt rsync -avzr --progress /root/bin/backup*.tar.gz / mnt / yad / >> result.txt rm -rf /root/bin/backup*.tar.gz >> result.txt echo "Подивіться файл на наявність помилок і виправте їх" | mail -a "/root/bin/result.txt" -s "Резервна копія створена" - ****@gmail.com rm -rf /root/bin/result.txt rm -rf / var / www / tmp / backup / *

Все те ж саме, тільки без зайвих команд. Якщо у вас інші шляхи до хмарних сховищ, міняйте в скрипті на свої.

В кінці статті хотілося б додати. Я розмістив зазначені скрипти в окрему директорію і запускають їх по крону. Якщо дисковий простір на ваших хмарних дисках дозволяє часто створювати бекапи, створюйте їх якомога частіше, я рекомендую не рідше ніж один раз на 3 дні. Використовуйте ресурси хмарних сховищ на всі 100%.

Приклади завдань в кроні:

0 0 * * 6 /root/bin/backup.sh - запускаємо скрипт бекапа щосуботи о 00-00
0 0 * / 3 * * /root/bin/backup.sh - запускаємо скрипт бекапа кожні 3 дні в 00-00

І так далі, налаштуйте бекапи як вам зручно, коли навантаження на сервері мінімальна.