Planiranje migracije između Linux distribucije za server — zašto i šta očekivati

Migracija serverskih sistema između Linux distribucija za server (npr. Ubuntu → CentOS/AlmaLinux/Rocky) je čest zadatak u modernom sistem-administriranju: promena politike podrške, hardverske interoperabilnosti, ili želja za stabilnijim RHEL-kompatibilnim okruženjem. Pravilno planiranje smanjuje rizik prekida usluga, gubitka podataka i sigurnosnih rupa. Ovaj prvi deo vodiča fokusiran je na pripremu, inventar servisa i osnovne provere kompatibilnosti pre nego što započnete backup i same migracione korake.

Procena okruženja i zahtevi pre migracije

Pre bilo kakve izmene, potrebno je napraviti kompletan inventar serverskih komponenti i zahtevajućih usluga. Cilj je identifikovati kritične servise, zavisnosti i očekivane verzije softvera kako bi se plan migracije mogao detaljno napraviti.

• Napraviti mapu servisa: web serveri (Apache/Nginx), baze (MySQL/PostgreSQL), DNS, mail, cron jobovi.
• Proveriti verzije kernela, biblioteka i jezgra software stack-a.
• Procena SLA: prihvatljivo vreme zastoja i vreme rollback-a.

Korišćenje jednostavnih komandi pomaže pri skupljanju informacija. Slede primeri koji zahtevaju sudo/root privilegije:

Provera informacije o OS:

# Na Ubuntu/Debian:
sudo lsb_release -a

# Na CentOS/AlmaLinux/Rocky:
cat /etc/os-release

Ove komande čitaju podatke o distribuciji i verziji.

Automatsko izlistavanje instaliranih paketa i servisa

Lista instaliranih paketa i aktivnih servisa olakšava mapiranje ekvivalentnih paketa na ciljnoj distribuciji.

# Na Ubuntu/Debian (lista paketa):
sudo dpkg --get-selections > /root/installed-packages-debian.txt

# Na CentOS/AlmaLinux/Rocky (lista paketa):
sudo rpm -qa > /root/installed-packages-rpm.txt

# Lista aktivnih systemd servisa (sve distribucije koje koriste systemd):
sudo systemctl list-units --type=service --state=running

Objašnjenje: prvi komandi eksportuju listu paketa u fajl; drugi prikazuje pokrenute servise. Fajlove koristite za poređenje i plan instalacije na novoj distribuciji.

Provere kompatibilnosti: paket-menadžeri, biblioteke i konfiguracioni fajlovi

Razlike između apt/dpkg i yum/dnf/rpm su jedna od glavnih prepreka. Potrebno je identificirati pakete koji nemaju direktne ekvivalente i planirati alternative ili izgradnju iz izvora.

• Napraviti listu kritičnih paketa koji moraju postojati na ciljnoj distribuciji.
• Proveriti dostupnost verzija baza podataka, PHP/Python/Node runtime-a i specifičnih knjižnica.
• Mapirati konfig fajlove: /etc/nginx, /etc/httpd, /etc/mysql, /etc/postgresql itd.

Pre početka promena, osmisliti backup plan (fajl-sistem, baze, konfiguracije) i testnu (staging) okolinu koja preslika produkciju. Primer osnovnog fajla-backupa (bez brisanja):

# Kreira tar arhivu /etc konfiguracija:
sudo tar -czvf /root/etc-backup-$(date +%F).tar.gz /etc

Ova komanda pravi kompresovanu arhivu konfiguracionih fajlova. Uvek proveriti prostor na disku pre izvođenja.

U sledećem delu biće obrađeni detaljni backup i restore postupci (uključujući baze podataka i LVM snapshot-e), koraci migracije paketa i podešavanje novih konfiguracija na staging okruženju, kao i strategije testiranja i rollback-a.

Detaljni backup i restore — fajlovi, baze i LVM snapshot-i

Pre nego što bilo šta menjate, napravite potpuni, verifikovani backup i opis postupka restore-a koji ste testirali. Preporučene komponente backup plana:

– Fajl-sistem i konfiguracije: rsync ili tar iz snapshot-a
– Ako koristite LVM: napravite snapshot logičkog volumena pre kopiranja produkcije:

sudo lvcreate --size 5G --snapshot --name root_snap /dev/vg0/root
sudo mkdir /mnt/snap
sudo mount /dev/vg0/root_snap /mnt/snap
sudo rsync -aHAX --numeric-ids --exclude=/proc --exclude=/sys --exclude=/dev --exclude=/run /mnt/snap/ /backup/server-root/
sudo umount /mnt/snap
sudo lvremove /dev/vg0/root_snap

– Snapshot omogućava konzistentan filesystem backup bez stavljanja servera u downtime.

– Baze podataka:
– MySQL/MariaDB: za male db dovoljan je mysqldump; za velike baze koristite Percona XtraBackup ili mysqlpump:

sudo mysqldump --single-transaction --routines --events --all-databases > /backup/all-mysql-$(date +%F).sql
# ili xtrabackup za neblokirajući backup:
xtrabackup --backup --target-dir=/backup/xtrabackup-$(date +%F)

– PostgreSQL: za pravljenje konzistentnih kopija koristite pg_basebackup + WAL arhiviranje ili logical dumps:

sudo -u postgres pg_basebackup -D /backup/pg_base -Ft -z -P
# ili za point-in-time recovery (PITR) uključiti WAL archiving

– Dokumentujte verzije servera, encodiranje baza i karakter setove.

– Specijalne stavke: mail queue, TLS ključevi (/etc/letsencrypt), SSH authorized_keys, certifikati, /var/lib/docker ili kontejner-storage.
– Verifikacija: svaki backup testirajte restore-om na izolovanom hostu. Proverite checksum, vlasništvo, permisije i SELinux kontekste (restorecon).

Restore osnovni primer:
– Vratite fajl-sistem iz rsync tar/backup direktorijuma ili montiranog snapshot-a.
– Za DB, zaustavite servis, vratite fajl-sisteme baze i startujte uz eventualnu primenu binlog/WAL za sinhronizaciju.

Migracija paketa i podešavanje konfiguracija na stagingu

Na staging mašini reprodukujte paketni stack ciljne distribucije. Koraci:

– Repozitorijumi: omogućite EPEL, Remi, ili službene repo-e koje su potrebne. Dodajte GPG ključeve i proverite kompatibilnost verzija.
– Mapiranje paketa: koristite izlistu sa izvornog sistema i iterativno tražite ekvivalente:

# primer potrage za paketom na RHEL:
dnf provides '*bin/nginx'

– Instalacija i konfiguracija:
– Instalirajte osnovne servise (httpd umesto apache2, mariadb-server, php-fpm verziju koja odgovara).
– Prekopirajte konfiguracione fajlove iz backup-a u /etc, ali nemojte ih odmah zameniti; poravnajte razlike u putanjama i direktivama (npr. systemd unit imena, lokacije log fajlova).
– Prilagodite systemd servise: nakon promene jedinica pokrenite systemctl daemon-reload i testirajte start/stop.
– Korisnici i permisije:
– Sinhronizujte /etc/passwd, /etc/group i /etc/shadow ili koristite getent export/import. Zadržite iste UID/GID za servisne naloge da bi pristupi fajlovima ostali valjani:

sudo rsync -aH --numeric-ids /home/ /backup/home/

– SELinux i firewall:
– Ako prelazite na RHEL-derivat sa SELinux-om, pokrenite restorecon na konfiguracijama i testirajte kontekst:

sudo restorecon -Rv /etc/httpd /var/www
sudo firewall-cmd --add-service=http --permanent
sudo firewall-cmd --reload

Testiranje na stagingu, validacija servisa i rollback strategije

Testiranje mora biti sveobuhvatno i reproduktivno:

– Smoke testovi: proverite da li se servisi pokreću, povezivanje na DB, isporuka statičkog sadržaja i TLS rukovanje.
– Integracioni testovi: automatizujte API pozive, provukući ključne tokove (login, pisanje u bazu, slanje mejla).
– Performansno testiranje: izvršite load testove (wrk, JMeter) da proverite ponašanje pod opterećenjem i timeout-e.
– Canaries i phased rollouts: razmislite o postepenom preusmeravanju sa balancerom ili DNS-om (npr. 10% trafika) pre full-cutover.

Rollback strategije (pripremljene pre promene):
– Fizički rollback: vraćanje LVM snapshot-a ili ponovno rsync-ovanje sa backup servera; ima najviše šansi za brzi povratak.
– DB rollback: za MySQL koristite binlog replay da poništite transakcije izvršene posle tačke prelaska; za Postgres koristite PITR sa WAL-ovima.
– Paketni rollback: dnf history undo može vratiti transakcije paketa; dokumentujte tačnu komandnu liniju koju ste koristili za instalaciju da biste mogli reverzno postupiti.
– Plan komunikacije: unapred definišite SLA, kontakt listu, i tačne korake za switchback (network routing, LB weighting, DNS TTL smanjenje).

Svaki rollback korak mora biti testiran na stagingu kako biste znali vreme i rizike vraćanja pre nego što krenete u produkciju.

Provedba cutover-a i post-deployment provere

• Koordinacija vremena: zakažite cutover tokom prozora sa najmanjim opterećenjem i obavestite sve učesnike unapred.
• Smanjite DNS TTL pre promene da biste skratili propagaciju, pa ga vratite nakon stabilizacije.
• Stavite privremenu održavanje-stranicu ako su potrebni kratkotrajni prekidi, i jasno komunicirajte očekivano trajanje.
• Zamrznite promenljive podatke (read-only ili queue pause) neposredno pre poslednjeg backup-a; uzmite finalni dump/WAL binlog tačku za bazu.
• Izvršite switch-over po unapred dokumentovanom planu (LB weight, BGP/route change ili DNS update) i pratite health-checkove u realnom vremenu.
• Aktivirajte monitoring i log agregaciju odmah pri cutover-u; pratite ključne metrike (latencija, error rate, opterećenje I/O, broj konekcija).
• Nakon stabilizacije, povratite standardne procedure (TTL, automatizacija), ažurirajte runbook i zatvorite promenu u CMDB/ticket sistemu.

Završna zapažanja za uspešnu migraciju

Migracija distribucije je proces upravljanja promenom koji zahteva disciplinu, jasnu komunikaciju i ponovljivost. Testirajte sve korake u izolovanom okruženju, dokumentujte svaki postupak i automatski beležite rezultate. Plan za rollback ne sme biti improvizovan — treba ga vežbati i učiniti dostupnim timu dok traje promena.

Fokusirajte se na automatizaciju, verzionisanje konfiguracija i monitoring: to smanjuje ljudske greške, ubrzava oporavak i olakšava buduće migracije. Održavajte tim spremnim kroz simulacije i retrospektive; svaka migracija treba da bude prilika za unapređenje procesa i alata.