Автобекапи з CentOS в Google Drive

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Вітання, я Ігор Сусяк і знайомство з компютерами почав ще далекого 1996 го року на 286 х монохромах з 5и дюймовими дискетами під час навчання в Івано-Франківському інституті нафти і газу)

Так повелось, що весь цей час працював з Windows-системами, включаючи серверні варіанти.

Та вже третій рік впроваджую українську CRM+ERP, яка хоститься виключно на CentOS Linux сімейства RedHat. Звичайно, на всі ситуації є штатні адміни і програмісти, проте інколи потрібно діяти оперативно. Наприклад — встановити чи продовжити SSL сертифікат, або збільшити місце на сервері. То ж потрохи розбираюсь сам, дрібненькими кроками, довбаючи гугл і ютуб, а деколи знаходячи відповіді в схоже налаштованих серверах.

Цього разу клієнт придумав дублювати копії бази даних з його сервера в Німеччині на стандартний, захищений двофакторною автентифікацією, Google Drive. Що ж, я вже вмів тоді копіювати файли чи папки з сервера на сервер і наївно вірив в швидке закінчення місії — то з цікавістю прийняв замовлення, яке оцінив в декілька годин і...провозився рівно два місяці. Не кожного дня, звичайно, але знаєте як буває — заходами на вихідні і обдумування чи перевірку в робочі дні за першої-ліпшої нагоди.

Спочатку, звичайно, спробував всі методи з першої сторінки пошуку гугла. Та нічого не спрацьовувало — як правило стопорилось на автентифікації Google Drive з командного рядку лінукса. Основна причина — немає офіційного рішення для Linux.

Що ж — клієнт лояльний, думаю зможу вмовити використати будь-який інший хмарний сервіс. Тестую Dropbox, OneDrive, і в одному з рішень натрапив на варіант синхронізації з MEGA. Не пройшло і місяця — а рішення знайдено, бази даних успішно скопійовано стандартним кроном, який спрацьовує щоночі! Виглядало це щастя так:

Проте біда прийшла звідки не чекали — виявляється все спрацьовувало, бо я мав власний акаунт MEGA, який зареєстрований декілька років тому. А всі новостворені, уявіть собі, не проходять авторизацію. Ще декілька тижнів на спілкування з техпідтримкою — результату немає, та ж відписка про third-party application і їхній megacmd, до якої немає інструкції.

З того горя запитав в знайомого DevOps’а — чи варта рухатись в напрямку копій на Google Drive. А він каже, щоб не парився і звичайна практика — бекапити все на сервіс S3 за $10 в місяць за терабайт.

Я майже змирився, але оскільки дедлайни не обумовлені — спробував ще раз покопатись в універсальних функціях копіювання rsync, пробуючи також rclone. І цього разу, після енної спроби, знайшов налаштування, де можна авторизувати Google Drive прямо з командного рядка. Це неймовірне відчуття першовідкривача дозволило повернути віру в приналежність до гордого племені homo sapiens. Щастя є, його не може не бути!

Хто ще не втомився — йдемо покроково:

авторизація по SSH з root доступом. В більшості випадків інструкції рекомендують інсталювати кастомні рішення через нерутового юзера, створюйте так:

www.digitalocean.com/...​user-on-centos-quickstart

встановлюємо rclone командою sudo yum install rclone, тисніть (y) на знак згоди.

якщо встановлення пройшло успішно — запускаємо rclone config і маємо отримати таке:

Current remotes:

Name                 Type
====                 ====
gdrive               drive

e) Edit existing remote
n) New remote
d) Delete remote
r) Rename remote
c) Copy remote
s) Set configuration password
q) Quit config
e/n/d/r/c/s/q>

вибираємо n) New remote і другим рядком вписуємо назву з’єднання, наприклад gdrive

далі пропонує список, де вибираємо 12й, пишемо drive

Type of storage to configure.

Enter a string value. Press Enter for the default ("").

Choose a number from below, or type in your own value

 1 / A stackable unification remote, which can appear to merge the contents of several remotes
   \ "union"
 2 / Alias for a existing remote
   \ "alias"
 3 / Amazon Drive
   \ "amazon cloud drive"
 4 / Amazon S3 Compliant Storage Provider (AWS, Alibaba, Ceph, Digital Ocean, Dreamhost, IBM COS, Minio, etc)
   \ "s3"
 5 / Backblaze B2
   \ "b2"
 6 / Box
   \ "box"
 7 / Cache a remote
   \ "cache"
 8 / Dropbox
   \ "dropbox"
 9 / Encrypt/Decrypt a remote
   \ "crypt"
10 / FTP Connection
   \ "ftp"
11 / Google Cloud Storage (this is not Google Drive)
   \ "google cloud storage"
12 / Google Drive
   \ "drive"
13 / Hubic
   \ "hubic"
14 / JottaCloud
   \ "jottacloud"
15 / Koofr
   \ "koofr"
16 / Local Disk
   \ "local"
17 / Mega
   \ "mega"
18 / Microsoft Azure Blob Storage
   \ "azureblob"
19 / Microsoft OneDrive
   \ "onedrive"
20 / OpenDrive
   \ "opendrive"
21 / Openstack Swift (Rackspace Cloud Files, Memset Memstore, OVH)
   \ "swift"
22 / Pcloud
   \ "pcloud"
23 / QingCloud Object Storage
   \ "qingstor"
24 / SSH/SFTP Connection
   \ "sftp"
25 / Webdav
   \ "webdav"
26 / Yandex Disk
   \ "yandex"
27 / http Connection
   \ "http"
Storage> drive

Дві наступні опції можна по замовчуванні, ентерами і вибираємо повний доступ, тиснемо 1

** See help for drive backend at: https://rclone.org/drive/ **

Google Application Client Id
Setting your own is recommended.
See https://rclone.org/drive/#making-your-own-client-id for how to create your own.
If you leave this blank, it will use an internal key which is low performance.
Enter a string value. Press Enter for the default ("").
client_id>
Google Application Client Secret
Setting your own is recommended.
Enter a string value. Press Enter for the default ("").
client_secret>
Scope that rclone should use when requesting access from drive.
Enter a string value. Press Enter for the default ("").
Choose a number from below, or type in your own value
 1 / Full access all files, excluding Application Data Folder.
   \ "drive"
 2 / Read-only access to file metadata and file contents.
   \ "drive.readonly"
   / Access to files created by rclone only.
 3 | These are visible in the drive website.
   | File authorization is revoked when the user deauthorizes the app.
   \ "drive.file"
   / Allows read and write access to the Application Data folder.
 4 | This is not visible in the drive website.
   \ "drive.appfolder"
   / Allows read-only access to file metadata but
 5 | does not allow any access to read or download file content.
   \ "drive.metadata.readonly"
scope> 1

далі уважно, двічі ентер, два рази n. Якщо все правильно — якраз тут має видати повний лінк авторизації гугл драйва. Виділяєте так як на скріні внизу, мишкою Сopy

і вставляєте рядок в браузері, має бути так:

вибираєте акаунт, на який потрібні бекапи.

І отримуємо вікно з кодом, копіюємо

І вставляємо його у вікно терміналу. Далі, якщо не потрібно командна робота, вибираємо n і підтверджуємо, що всі налаштування правильні y. Все, можна тиснути вихід q.

тепер безпосередньо перевіряємо на створення папок і файлів.

Пишемо rclone mkdir gdrive:Backup

І дивимось, що папка з назвою Backup створена в нашому Google Drive:

Тепер файли. Копіюємо для прикладу всі копії баз даних, які вже знаходяться в папці /opt/mysql_backup, разом з файлами: rclone copy /opt/mysql_backup gdrive:Backup

Перевіряємо — спрацювало!

також, якщо ви скористались порадою з п.1 і створили свого користувача, перевірте чи вищенаведені команди спрацьовують з рутового користувача. Для цього змініть юзера так: su root. Якщо команди не спрацювали — скопіюйте файл rclone.conf з вашого юзера /home/user/.config/rclone в рут /root/.config/rclone

для повної картини перевіряємо, чи можна буде видалити конкретний бекап, якщо ми заплануємо їх обмежену кількість. Для цього є дві команди: спочатку видаляємо всі файли rclone delete gdrive:Backup/backup-2020-02-13

а пізніше порожню папку так: rclone rmdir gdrive:Backup/backup-2020-02-13

як бачимо на скріні внизу — непотрібний бекап повністю видалено і він не займатиме лишнього місця:

Залишається налаштувати автоматичне копіювання новостворених бекапів. В нашому випадку вже передбачено виконавчий файл backup.sh, який виглядає так:

додав дві команди:

rclone mkdir gdrive:Backup/backup-${THE_DATE}
rclone copy ${BDIR}/backup-${THE_DATE} gdrive:Backup/backup-${THE_DATE}

а сам файл запускається кроном о 02:40 щоночі кроном:

Все, бекапи тепер будуть створюватись щоночі і копіюватись у ваш Google Drive. Беремо до уваги, що автоматичне видалення старих бекапів не налаштована, то ж прийдеться раз в декілька місяців підчищати вручну. Або налаштувати п. 13))

Кохаймося, бо ми того варті!

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

так добре, що написав інструкцію — тепер швидко налаштував для нового клієнта, завтра зроблю ще для одного. Виявляється — такі бекапи досить актуальні, бо вже знаю трьох клієнтів, які забули заплатити за сервер і вся інфа автоматично витерлась(

питання — як вирішується питання автоматичного сповіщення про те, що бекап НЕ ВІДБУВСЯ ?

Нижче наводили приклад з шедулером, але я писав, що нашим замовникам не критично, якщо скажімо 1 зі ста бекапів не спрацює. Хоча, можливо, так буде до першого випадку (

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

Я б шукав/писав плагін до гуглдрайв з щоденною перевіркою на створення папки по шаблону

Backup/backup-${THE_DATE}

плюс наявність в папці файлів.

Колись думав використовувати щось подібне. Нажаль, це працює, коли бекап 37Мб.

Коли розмір буде 37Gb, буде проблема. Коли 370Gb буде дорого і на грані можливого. А коли 3.7Tb, майже не реально.... до 37Tb я ще не дійшов ))

Якщо знаєте як, буде цікаво почути )

Прайси на гуглдрайв: one.google.com/about#upgrade
10 Tb, наприклад, всього 100$/міс

1Tb на 100Mbit-ному каналі буде закачуватися десь 23години, якщо дуже пощастить. Так щоденний бекап можна робити нонстоп.
І місця вистачить на 10 бекапів.

Я описав бекапи лише бази даних, без файлів. Зараз в клієнта файл більше 300 мб і збільшується на мегабайт в день. То ж поки нормально. При збільшенні можна перейти на той же S3. А от якщо буде справді терабайти даних — думаю спочатку пошукаю можливість бекапити на інший сервак в тому ж датацентрі, щоб не переливати по нету. Або змінювати технологію з реляційних БД на нереляційні, серверлес чи спеціальні мікросервіси, але то буде не моє завдання)

сейчас cron’ом не пользуюсь, в systemd есть свой шедулер с persistent таймерами, которые умеют запускать пропущенные джобы, например в 02.39 пропало питание, а в 02.41 оно восстановилось и −1 бэкап

[Unit]
Description=Update pacman repo

[Timer]
OnBootSec=5min
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target
RequiredBy=network-online.target

цікаво, я аж так глибоко не влажу, щоб була потреба налаштувати окремий шедул.
Сервер в німців і виключення електрики поки що не зустрічав. та й клієнтам −1 бекап не принципово при ймовірності 95-99%.

Підписатись на коментарі