htop and how I did it

Undeva intre “Arata-mi IP-ul!” si “E vineri 13?” gasim incepand de azi un nou link: htop.

Voiam sa fac de mai mult chestia asta (am vazut-o acum cativa ani pe undeva si mi-a placut), dar ori nu am avut timp si cand am avut timp nu am reusit(voiam alta abordare), ori nu mi s-a mai parut interesanta ideea, dar azi am facut-o.

Ce este? Htop “in timp real” (in urma cu cateva secunde, dar heh, who cares). Comanda htop rulata pe server si pusa “imaginea” intr-un html, apoi servit via Apache.

Sursa:

#!/bin/bash
export TERM=xterm-256color
export COLUMNS=200
export LINES=42
echo q | htop | aha --title htop --black --line-fix > /var/www/html/linux365.ro/htop.html

Daca va uitati la cod, vedeti ca e un simplu export intr-un fisier. Un “snapshot” al htop-ului asa cum e cand a fost rulat. Acum vine intrebarea de 1000 de puncte: cum am facut sa se actualizeze in timp real? Raspunsul este: systemd.

cat /etc/systemd/system/htop.service

[Unit]
Description=htop service
After=network.target
StartLimitIntervalSec=0

[Service]
Restart=always
RestartSec=1
ExecStart=/root/bin/htop.sh

[Install]
WantedBy=multi-user.target

Evident, serviciul a trebuit activat la restart si repornit. That’s it.

TODO (si won’t do in acelasi timp): ar trebui sa centrez output-ul.

BTRFS. (sau cum am stocat 3TB in 120GB)

Titlu de senzatie si semi-clickbait.

Trecand peste titlul de tabloid, am stocat 3TB in 120GB cu btrfs, snapshots si compresie.

Ce vedeti mai sus este serverul meu de backup. Un VM care trage in fiecare seara schimbarile de pe serverele la care fac backup. Am backup-uri zilnice de la inceputul anului pana in ziua de azi. De pe 29.12.2019 pana pe 3.10.2020. 10 luni de backup in 120GB (~90GB, dar 120GB este dimensiunea HDD-ului pe care se fac backup-urile).

Scriptul de backup il gasiti aici.

Cum e posibila chestia asta? Snapshots si compresie. Compsize arata practic cat spatiu ar trebui sa am pe un sistem de fisiere “normal” daca as avea aceeasi politica de backup.

Compresia banuiesc ca stiti cum functioneaza. Pe filesystem este transparenta si e exact ca si cum ai arhiva cu 7zip un fisier, doar ca asta se intampla automat pe btrfs cand un fisier se creeaza pe disk. (e de discutat si pe tema asta, dar just go with it. Pe scurt: unele fisiere se comprima mai bine decat altele)

Snapshot-urile sunt insa ceva mai interesant. Sa zicem ca ai fisierul A de 1MB si vrei sa-i faci snapshot din 10 in 10 minute, timp de o ora. La finalul orei o sa ai 6 snapshot-uri ale fisierului A. Teoretic, ai fisierul A de 6 ori, practic ai 5 referinte catre fisierul A original, de 1MB. Compsize calculeaza chestia asta insa ca avand fisierul A de 6 ori (in coloana Referenced), adica un total de 6MB, nu de 1MB. Fake? Nu chiar. Clickbait worthy? Poate. Daca tu la minutul 35 modifici fisierul A si ii cresti dimensiunea la 2MB, o sa ai primele snapshots de 1MB, apoi urmatoarele de 2MB, in total insumand 3MB. Compsize calculeaza asta in coloana de referenced ca 1MB+1MB+1MB+2MB+2MB+2MB = 9MB.

That’s it. Asta e marea smecherie. Asa bagi 3TB in 120GB.

PS: cele mai mari snapshot-uri sunt cele ale bazelor de date. Am ales optiunea sa fac compresie la nivel de filesystem si nu in timpul backup-ului. Scriptul de backup pentru mysql este o combinatie intre ce am avut eu nevoie si alte exemple gasite pe stackoverflow/github, dar pe scurt asta e linia care face tot: $MYSQLDUMP -h $MyHOST -u $MyUSER -p$MyPASS $db > $FILE

Nu recomand daca vreti ceva mai serios. Scriptul de backup mysql este locking. La baze de date mai mari (sunt multumit de cat de repede se face backup un DB de 2GB) e naspa ca iti pune productia pe jos. Se poate tuna si se mai pot adauga optiuni la backup, dar pentru ce am eu nevoie e destul.