Operasional

Pemantauan, log, dan otomatisasi cadangan sehari-hari.

Daftar isi

Topik penutup proyek ini menetapkan rutinitas setelah server hidup, yaitu memantau sumber daya, membaca log layanan, dan menjaga cadangan berjalan otomatis. Ketiganya adalah pekerjaan berulang yang kekuatannya ada pada pola, bukan pada perintah baru, sehingga topik ini menyusun perintah-perintah yang sudah dikenal menjadi satu rangkaian operasional yang utuh. Bagian pemantauan dan pembacaan log dieksekusi nyata di lingkungan latihan, sedangkan otomatisasi cadangannya dibangun lengkap dengan rsync dan dipasang sebagai pasangan layanan dan timer systemd.

Rutin pemantauan#

Lingkungan latihan dipersiapkan dahulu dengan menyalin dua skrip dari bundle topik deploy, yaitu aplikasi catatan dan layanan pencatat statusnya, ke folder kerja topik ini:

bash

# folder kerja topik operasional
rm -rf /tmp/kerja-operasional
mkdir -p /tmp/kerja-operasional
# salin skrip aplikasi dan layanan dari bundle topik deploy-layanan
cp ../deploy-layanan/catatan.sh ../deploy-layanan/pencatat-status.sh /tmp/kerja-operasional/
chmod +x /tmp/kerja-operasional/*.sh
ls -1 /tmp/kerja-operasional

text Keluaran

catatan.sh
pencatat-status.sh

Pemantauan ruang dimulai dari df, yang melaporkan sisa ruang per sistem berkas. Argumen /dev membatasi laporannya ke sistem berkas yang menampung /dev, yaitu tmpfs berbasis memori pada container latihan ini:

bash

# sisa ruang pada sistem berkas /dev
df -h /dev

text Keluaran

Filesystem      Size  Used Avail Use% Mounted on
tmpfs            64M     0   64M   0% /dev

Angka Use% nol pada sistem berkas kecil ini memang belum informatif, tetapi bentuk laporannya itulah yang dibaca setiap hari pada server. Baris yang diawasi biasanya baris / dengan Use% yang merambat naik. Rutin berikutnya memakai uptime, yang melaporkan jam saat ini, lama mesin menyala, jumlah pengguna aktif, dan tiga angka rata-rata beban. Seluruh angkanya berubah dari waktu ke waktu, sehingga keluarannya dibaca langsung di terminal, sementara blok berikut membuktikan perintahnya berjalan:

bash

# keluaran uptime berubah setiap detik sehingga dibaca langsung di mesin latihan
uptime > /dev/null
echo "uptime dijalankan; bacakan keluarannya langsung di terminal"

text Keluaran

uptime dijalankan; bacakan keluarannya langsung di terminal

Rutin pemantauan ditutup oleh ps. Header kolom ps aux bersifat tetap, sedangkan baris prosesnya berganti setiap saat, sehingga blok berikut menampilkan headernya saja dan membuktikan kehadiran layanan pencatat status melalui penghitung baris:

bash

# layanan contoh dijalankan di latar belakang dengan pustaka terpisah
PUSTAKA=/tmp/kerja-operasional/uji-ps JEDA=60 /tmp/kerja-operasional/pencatat-status.sh --layanan &
PID=$!
sleep 0.3
# header kolom ps aux, lalu jumlah proses layanan yang hidup
ps aux | head -n 1
ps aux | grep -c '[p]encatat-status'
# dua langkah penghentian: SIGTERM, lalu SIGKILL bila masih hidup
kill "$PID" 2>/dev/null
sleep 0.2
kill -9 "$PID" 2>/dev/null
wait "$PID" 2>/dev/null
echo "layanan contoh dihentikan"

text Keluaran

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
1
layanan contoh dihentikan

Pola [p]encatat-status memakai kelas karakter satu huruf agar baris milik proses grep sendiri tidak ikut terhitung, dan hasil penghitungan sebesar satu berarti tepat satu proses layanan yang hidup. Pada server, rutin ini diperluas sesuai kebutuhan, misalnya du -sh pada direktori yang dicurigai tumbuh atau top -bn1 untuk potret beban sesaat.

Membaca log layanan#

Layanan pencatat status mencantumkan jumlah catatan pada setiap baris lognya, sehingga pustaka diisi dahulu dengan dua catatan contoh:

bash

# dua catatan contoh untuk pustaka
PUSTAKA=/tmp/kerja-operasional/pustaka /tmp/kerja-operasional/catatan.sh tambah "beli kopi"
PUSTAKA=/tmp/kerja-operasional/pustaka /tmp/kerja-operasional/catatan.sh tambah "rapat pukul sepuluh"
PUSTAKA=/tmp/kerja-operasional/pustaka /tmp/kerja-operasional/catatan.sh daftar

text Keluaran

catatan #1 tersimpan
catatan #2 tersimpan
1) beli kopi
2) rapat pukul sepuluh

Layanannya kemudian dijalankan untuk mengisi log dengan empat pembacaan:

bash

# empat pembacaan status dari layanan
PUSTAKA=/tmp/kerja-operasional/pustaka BATAS=4 JEDA=1 /tmp/kerja-operasional/pencatat-status.sh --layanan

text Keluaran

pencatat-status selesai setelah 4 pembacaan

Pada server, log yang sama tidak dibaca dari berkasnya, melainkan dari jurnal melalui journalctl -u catatan-layanan.service, karena systemd menampung keluaran layanan. Di lingkungan latihan, berkas lognya langsung dikueri dengan grep dan wc:

bash

# log milik layanan pencatat status
LOG=/tmp/kerja-operasional/pustaka/log/status.log
# jumlah baris berstatus OK di seluruh log
grep -c 'status=OK' "$LOG"
# total baris log
wc -l < "$LOG"
# isi log tanpa kolom waktu
cut -d' ' -f3- "$LOG"

text Keluaran

4
4
status=OK catatan=2
status=OK catatan=2
status=OK catatan=2
status=OK catatan=2

Nilai catatan=2 pada setiap baris menyatakan jumlah catatan yang ada ketika baris itu ditulis, sehingga perubahan aplikasi dapat dilacak dari lognya tanpa membuka pustakanya. Kueri semacam ini disesuaikan dengan isi log yang dicari, misalnya menghitung baris yang tidak berstatus OK dengan grep -vc, atau menelusuri baris pada rentang jam tertentu setelah kolom waktunya disaring. Kedua sumber log juga saling melengkapi, karena umur jurnal pada server dibatasi oleh konfigurasi journald, sedangkan berkas log milik layanan bertahan sepanjang pustakanya tidak dibersihkan.

Snapshot cadangan dengan rsync#

Bagian cadangan memakai rsync dengan opsi --link-dest untuk membangun snapshot hemat ruang. Berkas yang berubah disalin ke snapshot baru, sedangkan berkas yang tetap dibuat sebagai hard link menuju salinannya pada snapshot sebelumnya, sehingga serangkaian snapshot harian tidak jauh lebih besar daripada satu salinan penuh. Skrip cadangan berikut membungkus pola itu, dan tanggal snapshotnya dapat ditimpa lewat variabel CADANGAN_TANGGAL agar ujinya dapat diulang:

bash cadangan-harian.sh

#!/usr/bin/env bash
# cadangan-harian.sh: snapshot rsync --link-dest harian atas satu direktori
# Pemakaian: cadangan-harian.sh <sumber> <induk-cadangan>
# Tanggal snapshot dapat ditimpa lewat variabel CADANGAN_TANGGAL untuk uji lokal.
set -euo pipefail

utama() {
    SUMBER="$1"
    INDUK="$2"
    HARI="${CADANGAN_TANGGAL:-$(date +%F)}"
    TUJUAN="$INDUK/$HARI"
    TERAKHIR="$INDUK/terakhir"

    if [ ! -d "$SUMBER" ]; then
        echo "Error: direktori sumber $SUMBER tidak ditemukan." >&2
        exit 1
    fi

    mkdir -p "$TUJUAN"
    if [ -d "$TERAKHIR" ]; then
        rsync -a --delete --link-dest="$TERAKHIR" "$SUMBER/" "$TUJUAN/"
    else
        rsync -a --delete "$SUMBER/" "$TUJUAN/"
    fi
    ln -sfn "$TUJUAN" "$TERAKHIR"
    echo "snapshot $HARI tersimpan di $TUJUAN"
}

if [ $# -eq 2 ]; then
    utama "$1" "$2"
else
    echo "Pemakaian: cadangan-harian.sh <sumber> <induk-cadangan>"
fi

text Keluaran

Pemakaian: cadangan-harian.sh <sumber> <induk-cadangan>

Tanpa argumen, skrip hanya menampilkan cara pemakaiannya, dan kedua argumennya wajib karena sumber dan induk cadangan berbeda pada setiap server.

Skrip ini dijalankan dua kali, yaitu untuk snapshot hari pertama, lalu setelah satu catatan baru ditambahkan, untuk snapshot hari kedua:

bash

# snapshot hari pertama dari pustaka
CADANGAN_TANGGAL=2026-11-02 ./cadangan-harian.sh /tmp/kerja-operasional/pustaka /tmp/kerja-operasional/cadangan

text Keluaran

snapshot 2026-11-02 tersimpan di /tmp/kerja-operasional/cadangan/2026-11-02

bash

# catatan baru, lalu snapshot hari kedua
PUSTAKA=/tmp/kerja-operasional/pustaka /tmp/kerja-operasional/catatan.sh tambah "tinjau laporan"
CADANGAN_TANGGAL=2026-11-03 ./cadangan-harian.sh /tmp/kerja-operasional/pustaka /tmp/kerja-operasional/cadangan

text Keluaran

catatan #3 tersimpan
snapshot 2026-11-03 tersimpan di /tmp/kerja-operasional/cadangan/2026-11-03

Penghematannya terbaca dari penghitung hard link pada stat. Angka pertama pada setiap baris keluarannya menyatakan jumlah link menuju inode berkas tersebut. Berkas catatan.txt berubah di antara kedua snapshot, sehingga snapshot kedua memegang salinan barunya sendiri. Sebaliknya, log/status.log tidak berubah, sehingga snapshot kedua memuat hard link menuju salinannya pada snapshot pertama:

bash

# jumlah link menuju inode setiap berkas pada snapshot
stat -c '%h %n' /tmp/kerja-operasional/cadangan/2026-11-02/catatan.txt /tmp/kerja-operasional/cadangan/2026-11-03/catatan.txt /tmp/kerja-operasional/cadangan/2026-11-03/log/status.log

text Keluaran

1 /tmp/kerja-operasional/cadangan/2026-11-02/catatan.txt
1 /tmp/kerja-operasional/cadangan/2026-11-03/catatan.txt
2 /tmp/kerja-operasional/cadangan/2026-11-03/log/status.log

Ukuran kedua snapshot mengonfirmasi keadaan tersebut. Snapshot kedua lebih kecil karena berkas yang berbagi hard link tidak dihitung dua kali oleh du:

bash

# ukuran setiap snapshot
du -sh /tmp/kerja-operasional/cadangan/2026-11-* | awk '{print $1, $2}'

text Keluaran

16K /tmp/kerja-operasional/cadangan/2026-11-02
12K /tmp/kerja-operasional/cadangan/2026-11-03

Di dalam induk cadangan juga tercipta symlink bernama terakhir yang selalu menunjuk snapshot termuda, sehingga pemulihan satu direktori cukup memakai symlink itu. Serangkaian snapshot seperti ini memenuhi lapisan lokal aturan 3-2-1, dan salinan di tempat lain tetap menjadi tanggung jawab terpisah.

Otomatisasi dengan timer systemd#

Snapshot manual di atas menjadi otomatis ketika skripnya dibungkus unit layanan sekali jalan dan dipicu timer harian. Kedua berkas unitnya adalah berikut:

ini cadangan-harian.service

[Unit]
Description=Cadangan harian pustaka catatan

[Service]
Type=oneshot
ExecStart=/usr/local/bin/cadangan-harian.sh /var/lib/catatan /var/backups/catatan

ini cadangan-harian.timer

[Unit]
Description=Pemicu cadangan harian pukul 02.00

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

Layanan cadangan memakai Type=oneshot karena tugasnya sekali jalan, sedangkan ExecStart= memanggil skrip dengan dua argumen, yaitu sumber dan induk cadangan pada server. Tanpa direktif Unit= pada bagian [Timer], sasaran timer bernama cadangan-harian.timer adalah layanan dengan nama yang sama. Ekspresi OnCalendar=*-*-* 02:00:00 memicu setiap hari pukul 02.00, dan Persistent=true mengejar picu yang terlewat apabila mesin mati pada saat jadwalnya. Pemasangannya mengikuti pola yang sama dengan layanan lain, ditambah pemeriksaan daftar timer untuk memastikan jadwalnya terbaca:

bash

# tidak-dijalankan
# pemasangan menuntut hak root dan systemd yang berjalan
sudo cp cadangan-harian.sh /usr/local/bin/
sudo chmod +x /usr/local/bin/cadangan-harian.sh
sudo cp cadangan-harian.service cadangan-harian.timer /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now cadangan-harian.timer
# jadwal dan picu berikutnya
systemctl list-timers cadangan-harian.timer

Sejak titik ini, snapshot baru muncul setiap malam tanpa campur tangan, dan keberhasilannya diperiksa lewat daftar snapshot beserta lognya di jurnal. Apabila jadwalnya perlu digeser, nilai OnCalendar disunting pada berkas unit timer, diikuti daemon-reload dan restart pada timernya. Picu yang baru langsung terbaca pada list-timers. Rutinitas operasionalnya pun membentuk satu siklus tertutup, yaitu pemantauan menemukan gejala, log menjelaskan penyebabnya, dan cadangan menjamin keadaan terburuk tetap dapat dipulihkan.

Kesalahan umum#

Menyangka ada berkas hilang karena angka du dua snapshot tidak sama. du menghitung setiap inode sekali per pemanggilan, sehingga berkas yang berbagi hard link hanya tercatat pada snapshot pertama yang ditemuinya.
Menyalin perintah rsync dengan sumber dan tujuan terbalik. rsync mengalirkan sumber menuju tujuan, dan dengan --delete, arah yang terbalik berarti isi pustaka disamakan dengan snapshot lama sehingga data terbaru hilang.
Menulis OnCalendar yang lebih sering daripada maksudnya, misalnya *-*-* *:00:00 yang memicu setiap jam, bukan sekali sehari. Ekspresi baru selalu dihitung dahulu dengan systemd-analyze calendar sebelum dipasang.
Menganggap snapshot pada disk yang sama memadai. Snapshot --link-dest melindungi dari kesalahan berkas dan penghapusan yang tidak disengaja, tetapi tidak dari kerusakan disk, sehingga aturan 3-2-1 tetap menuntut salinan di tempat lain.

Ringkasan#

Rutin pemantauan berputar pada df untuk sisa ruang, uptime untuk lama menyala dan rata-rata beban, serta ps untuk proses layanan yang hidup.
Log layanan dikueri dengan grep dan wc, dan kolom waktunya yang selalu bergerak dipotong dengan cut agar kuerinya dapat direproduksi.
rsync dengan --link-dest menghasilkan snapshot harian yang hemat karena berkas yang tetap berbagi hard link antar snapshot.
Pasangan unit Type=oneshot dan timer harian dengan Persistent=true mengotomatiskan cadangan sekaligus mengejar jadwal yang terlewat.

Referensi#

rsync(1) — Ubuntu Manpages — Opsi -a, --delete, dan perilaku --link-dest.
systemd.timer(5) — freedesktop.org — Direktif OnCalendar= dan Persistent= pada berkas timer.
uptime(1) — Ubuntu Manpages — Bentuk keluaran uptime dan arti tiga angka rata-rata bebannya.