[koi] Да се подкара бекъп на важните неща

[mitio]

Трябва да измислим и подкараме културна и лесна схема за архивиране на важните неща - например бази данни от контейнери (поне). Не съм сигурен как и къде. Приемам предложения.

/cc @krokodilerian

[krokodilerian]

Трябват ми няколко неща и сравнително лесно мога да я направя, как ви звучи следното:

Във всеки контейнер някъде има два файла, единия съдържа директории за архивиране, другия имена на бази данни. Понеже всички са debian-и, аз знам как да стигна до базата, и просто всеки ден в 4 сутринта ще обикалям всички контейнери, ще правя един dump, ще го криптирам и ще го преливам някъде, дето имам място. Ще измислим как да пазим ключа (вероятно с passphrase, с backup-ите и самата passphrase ще я дам на няколко човека).

Това ок ли звучи?

[mitio]

Звучи добре.

Примерно, в контейнера, /root/backup/{paths,postgresql_databases,mysql_databases}? Имаме и MongoDB инстанции на места, мисля. Приемам предложения за конвенциите.

• За /root/backup/paths мисля, че освен папки, трябва да може и индивидуални файлове да се посочват. Не знам дали има смисъл от rsync-style --exclude неща да се поддържат. Може би по едно правило/път на ред.
• За базите данни, със сигурност е добра идея да имаме и PostgreSQL, и MySQL. Цели бази данни. Но може да се наложи в някои места да се архивира база без отделна таблица. Ако не е лесно отсега да предвидим такава конвенция, засега можем да го направим само с цели бази. По едно име на база на ред си представям аз.

Като начало, пароли за ключовете можем да дадем на @antitoxic, @tochev, ти, аз, тъй като основно това сме, които ръчкаме по сървъра. Може би не е лоша идея всеки maintainer на проект да има достъп до архива си някак, но не е задължително, поне не и на този етап.

[tochev]

@mitio, аз предполагам че @krokodilerian има нещо готово - аз предлагам да пробваме да го setup-нем тия дни, пък ще видим дали ни трябва нещо по-специфично (според мен нямаме толкова големи бази или логове че да трябва да се exclude-ват неща, т.е. формат за tar -T e напълно адекватен на дадения момент).

Единствения ми въпрос е дали ще е pull или push? (като pull значи да дадем на автоматичната система достъп до машините, а при push трябва да внимаваме да не може да си променят/четат взаимно backup-ите)

Хубаво е и да се помисли дали ще се прави и за aws server-a (за който, доколкото знам, планът е да се мигрира), т.е. при него проблем ли ще е голям backup трафик?

[mitio]

Ако наистина има нещо готово, ще се съобразим с наличното.

За защита от четене на различните бекъпи в момента не мислим, тъй като който има root достъп до някой container, доколкото разбирам, не е много трудно да получи и root достъп до хоста, а от там – целият свят е в краката му :)

И аз мисля, че нещата от aws трябва да се мигрират и не виждам голям смисъл да ги бекъпваме в момента.

[krokodilerian]

@mitio, Точно готово нямам, но мога да сглобя от полу-готовите ми работи в рамките на час-два.

@tochev, ще е на pull, т.е. един cron на един друг сървър ще минава в ранната сутрин, ще пуска един ssh който на output-а си ще му даде криптираните файлове, които да пази някъде.

[tochev]

@mitio backup-a е подкаран.

В https://github.com/obshtestvo/backup-sys/ са скриптовете. Нека съответните project maintainer-и си променят каквото е забравено (или да махнат неща които не са нужни).

Добавени са backup ключове на container-ите и, създадох id_rsa на root@koi.

В момента backup-a отива на marla, като аз и maniax-a имаме ключа (ила го и на koi, но е с парола - като се видим трябва да я дам).

При нов container има default script, но е хубаво да се добавя нов и да се вика make (което просто копва нещата).