Миграция на сървъри

Или как си прехвърлям една кофа сайтове от един сървър на друг по бърз и лесен начин и без почти никакви грижи.

Копиране на файловете

Разбира се, тук е полезен добрият ни стар приятел rsync:

rsync -avz /var/www/ root@hans.isld.nl:/var/www
rsync -avz /etc/nginx/sites-available/ root@hans.isld.nl:/etc/nginx/sites-available

Или на по-човешки език – изпращаме съдържанието на web root директорията до тази на новия сървър, компресирайки всичко, показвайки до кой файл сме стигнали и с “комбото” –archive, което запазва файловите атрибути. Същото правим и с виртуалните хостове на nginx.

В зависимост от използваната конфигурация, може да се наложи да се копират и други файлове, като например php.ini.

Копиране на базите данни

След като сме метнали файловете, трябва да преместим и базите данни. До сега го правех с mysqldump и премятане на файлове нагоре-надолу, но този път изрових перфектния начин това да се случи. Първо в ~/.my.cnf на “стария” сървър пишем:

[mysqldump]
user=root
password=secret

На “новия” сървър правим същото, но с [mysql] на първия ред.

И тук следва “магията”:

mysqldump --all-databases | ssh root@hans.isld.nl mysql
mysqldump mysql | ssh root@hans.isld.nl mysql mysql

Създадените (или редактираните) .my.cnf файлове ни позволяват да пускаме mysql/mysqldump без -u и -p параметри, което ни спестява писането на plain text пароли в терминала. Dump-ваме всички бази и директно ги засилваме по SSH до отсрещния MySQL. Втората команда пък копира всички потребители барабар с паролите и правата им.

След като всичко е копирано, остава единствено symlink-ването на готовите виртуални хостове в /etc/nginx/sites-enabled и всичко трябва да работи.

DNS записи за десерт

Последната стъпка в миграцията е прехвърлянето на DNS записите на всеки домейн към новия сървър. Предварително може всичко да се изтества с помощта на /etc/hosts (под Linux) или C:\Windows\system32\drivers\etc\hosts (под Windows). Ако не омажем нищо, по този начин мигрираме цял уеб сървър с практически нулев downtime.

ПП: Важно уточнение е че в моя случай всички прехвърляни сайтове са “собственост” на www-data, ако има добавени потребители, ще трябва да се създадат наново на новия сървър. Също така, ако сред мигрираните сайтове има такива с динамично съдържание, важно е да не се генерира такова след прехвърлянето на базата и преди промяната на DNS записите, за да не зависне некопирана информация на стария сървър.

Gitlab. Ами сега?

Понеже ползвам и Gitlab, ще опиша как протича и процедурата по неговото мигриране. На новия сървър инсталираме Gitlab CE Omnibus, както е описано в документацията им. След това, на стария сървър се възползваме от една благинка, идваща с пакета:

gitlab-rake gitlab:backup:create

Тази прекрасна команда ще архивира всичкото съдържание на Gitlab (без конфигурацията!!!) във /var/opt/gitlab/backups/<име>.tar. Тъй като всичката конфигурация е в /etc/gitlab, и нейното копиране не е ракетна наука:

scp /etc/gitlab/* root@hans.isld.nl:/etc/gitlab

Покатерваме генерирания .tar бекъп на правилното място на новия сървър:

rsync -avz <timestamp>_gitlab_backup.tar root@hans.isld.nl:/var/opt/gitlab/backups/

След като сме изкопирали конфигурацията, трябва да преконфигурираме Gitlab:

gitlab-ctl reconfigure

Това ще натамъни (почти) всичко, след което ще е нужно единствено възстановяването на бекъпа:

gitlab-rake gitlab:backup:restore BACKUP=<timestamp>

Обновяване на Gitlab

В моя случай се оказа, обаче, че версията на стария сървър е 7.х, пък на новия е 8.х и не приема бекъпа. Решението е елементарно:

apt-get update
apt-get install gitlab-ce

…на стария сървър, след което се повтаря процедурата с правенето и възстановяването на бекъпа.

Ако бъдете попитани дали наистина искате да изтриете всички таблици в базата на Gitlab на новия сървър – трийте, не се чудете, инсталацията е нова и празна и няма какво да се счупи 🙂

Използване на правилния nginx

Тъй като Omnibus пакета на Gitlab CE идва с негов си nginx, а новият ми сървър е комбиниран за уеб + Gitlab, ми се налага да го “откача” от единия и да го “закача” на другия уеб сървър.

Няма да описвам процедурата, само ще туря един полезен линк – тук се намира всичката полезна документация по въпроса. Само не забравяйте да добавите www-data към web_server[‘external_users’] в /etc/gitlab/gitlab.rb 🙂

Ти му говориш, оно рупа ли, рупа…

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

В момента всичките ми цифрови снимки от 2003-та до днес са на 1TB refurbished сървърен диск, който е бил ~5 години в production. Няма ги никъде другаде – освен тези от телефона ми, които се sync-ват с Google. Този блог, този с пътеписите ми, портфолиото на сестра ми, един Gitlab и още куп уеб-неща бяха на Xen виртуалка на bob.initlab.org – сървър с “нормален” хардуер и…. един диск. Който (сървър) също реши да умре в един прекрасен момент и сред безвъзвратно загубените неща са MySQL базите данни, хостнати на въпростната виртуалка. Статията, която споменах в началото, бе възстановена от Google cache-а, имам тепърва да възстановявам и от web.archive.org.

Явно има и “трети вид” хора – такива, на които им е горял твърдия диск, ама си питат ушите да правят бекъпи. Затова тоя път попсувах на ум, погледнах с мъка месечния си бюджет и си поръчах HP Microserver Gen8, който вече е “up and running” в Костинброд – с UPS, два Интернет доставчика, (скоро) два 3TB диска в RAID1 и всичко от навсякъде ще се бекъпва постоянно на него.

#сичкишеомрем, но въпреки това – правете бекъпи. Ама сериозно.