InfluxDB Backup ve Restore Stratejileri

Tarafındankomut
0 Comments

Zaman serisi veritabanlarıyla çalışırken en çok ihmal edilen konuların başında yedekleme stratejileri gelir. InfluxDB’yi production ortamına kurdunuz, metrikleriniz akıyor, dashboard’larınız çalışıyor. Peki ya bir gün disk bozulursa? Yanlışlıkla kritik bir measurement silinirse? İşte o an için hazırlıklı olmak, iyi bir sysadmin’in temel görevidir. Bu yazıda InfluxDB için kapsamlı bir backup ve restore stratejisi nasıl kurulur, adım adım inceleyeceğiz.

InfluxDB Backup Mekanizmasını Anlamak

InfluxDB, verilerini kendi özel TSM (Time-Structured Merge Tree) formatında saklar. Bu nedenle dosya sistemi seviyesinde ham kopyalama yapmak, çoğu zaman tutarsız verilere yol açar. InfluxDB’nin kendi influx backup komutunu kullanmak çok daha güvenlidir.

InfluxDB 2.x ile birlikte backup mekanizması köklü bir değişime uğradı. Artık hem influx CLI aracılığıyla hem de HTTP API üzerinden yedek alabiliyorsunuz. Backup işlemi sırasında veritabanı çalışmaya devam eder, yani sıfır kesinti ile yedek alabilirsiniz.

Backup dosyaları şu bileşenleri içerir:

  • Metadata: Organizasyon, bucket, dashboard ve görev tanımları
  • TSM dosyaları: Asıl zaman serisi verileri
  • WAL dosyaları: Henüz TSM’e yazılmamış son veriler

InfluxDB 1.x kullanıyorsanız komut seti biraz farklıdır. Bu yazıda her iki versiyona da değineceğiz ama ağırlıklı olarak 2.x üzerinden ilerleyeceğiz.

Ortam Hazırlığı ve Ön Kontroller

Backup almaya başlamadan önce birkaç şeyi kontrol etmek iyi alışkanlıktır.

# InfluxDB servis durumunu kontrol et
systemctl status influxdb

# Versiyon bilgisini öğren
influx version

# Mevcut organizasyonları listele
influx org list --token $INFLUX_TOKEN

# Mevcut bucket'ları listele
influx bucket list --token $INFLUX_TOKEN

Token bilginizi bir environment variable olarak saklamanızı öneririm. Her komuta --token parametresi geçmek hem zahmetlidir hem de komut geçmişinde token’ın görünmesi güvenlik açığı yaratır.

# .bashrc veya .bash_profile dosyasına ekleyin
export INFLUX_TOKEN="sizin-operator-token-buraya"
export INFLUX_HOST="http://localhost:8086"
export INFLUX_ORG="myorg"

Temel Backup Alma İşlemleri

Tam Yedek Alma

Tüm organizasyonu ve verilerini tek seferde yedeklemek için:

# Belirli bir dizine tam backup al
influx backup /opt/influxdb-backups/$(date +%Y%m%d_%H%M%S) 
  --host $INFLUX_HOST 
  --token $INFLUX_TOKEN

# Belirli bir organizasyonu yedekle
influx backup /opt/influxdb-backups/full_$(date +%Y%m%d) 
  --host $INFLUX_HOST 
  --token $INFLUX_TOKEN 
  --org myorg

Backup komutu çıktısında hangi dosyaların oluşturulduğunu göreceksiniz. Tipik bir çıktı şöyle görünür:

2024/01/15 10:23:45 INFO: Backing up to /opt/influxdb-backups/20240115_102345
2024/01/15 10:23:45 INFO: Fetching TSM files...
2024/01/15 10:23:47 INFO: Backed up 142 TSM files
2024/01/15 10:23:47 INFO: Backing up metadata...
2024/01/15 10:23:47 INFO: Backup complete

Belirli Bir Bucket’ı Yedekleme

Tüm veriyi değil de sadece belirli bir bucket’ı yedeklemek istediğinizde:

# Bucket ID'sini öğren
BUCKET_ID=$(influx bucket list --name "telegraf" --json | jq -r '.[0].id')

# Sadece o bucket'ı yedekle
influx backup /opt/influxdb-backups/telegraf_$(date +%Y%m%d) 
  --host $INFLUX_HOST 
  --token $INFLUX_TOKEN 
  --bucket-id $BUCKET_ID

Bu yöntem özellikle büyük InfluxDB kurulumlarında işe yarar. Tüm veriyi değil, sadece kritik olan bucket’ı yedeklemek hem disk alanı kazandırır hem de yedekleme süresini kısaltır.

Otomatik Yedekleme Scripti

Gerçek dünyada yedekleme işlemini otomatize etmek şarttır. Sabah kalktığınızda yedek almayı düşünmüyorsunuzdur. Cron’a bırakın bu işi.

#!/bin/bash
# /opt/scripts/influxdb-backup.sh

set -euo pipefail

# Konfigürasyon
INFLUX_HOST="http://localhost:8086"
INFLUX_TOKEN="sizin-token-buraya"
INFLUX_ORG="myorg"
BACKUP_DIR="/opt/influxdb-backups"
RETENTION_DAYS=30
LOG_FILE="/var/log/influxdb-backup.log"

# Tarih damgası
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_PATH="${BACKUP_DIR}/${TIMESTAMP}"

# Log fonksiyonu
log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}

# Backup dizinini oluştur
mkdir -p "$BACKUP_PATH"

log "InfluxDB backup basliyor: $BACKUP_PATH"

# Backup al
if influx backup "$BACKUP_PATH" 
    --host "$INFLUX_HOST" 
    --token "$INFLUX_TOKEN" 
    --org "$INFLUX_ORG" >> "$LOG_FILE" 2>&1; then
    
    log "Backup basariyla tamamlandi"
    
    # Backup'ı sıkıştır
    tar -czf "${BACKUP_PATH}.tar.gz" -C "$BACKUP_DIR" "$(basename $BACKUP_PATH)"
    rm -rf "$BACKUP_PATH"
    
    BACKUP_SIZE=$(du -sh "${BACKUP_PATH}.tar.gz" | cut -f1)
    log "Backup boyutu: $BACKUP_SIZE"
    
else
    log "HATA: Backup basarisiz oldu!"
    # Slack veya email bildirimi burada gönderilebilir
    exit 1
fi

# Eski yedekleri temizle
log "Eski yedekler temizleniyor (${RETENTION_DAYS} gunden eski)..."
find "$BACKUP_DIR" -name "*.tar.gz" -mtime +$RETENTION_DAYS -delete
log "Temizlik tamamlandi"

# Kalan yedek sayısını logla
BACKUP_COUNT=$(ls -1 "${BACKUP_DIR}"/*.tar.gz 2>/dev/null | wc -l)
log "Toplam yedek sayisi: $BACKUP_COUNT"

Bu scripti çalıştırılabilir yapıp cron’a ekleyin:

chmod +x /opt/scripts/influxdb-backup.sh

# Crontab'ı düzenle
crontab -e
# Her gece saat 02:00'de backup al
0 2 * * * /opt/scripts/influxdb-backup.sh

# Haftada bir tam backup (Pazar 03:00)
0 3 * * 0 /opt/scripts/influxdb-backup.sh

Uzak Depolamaya Backup Gönderme

Yerel disk yedekleri yeterli değildir. Sunucu tamamen çökerse yerel yedek de gider. Yedeklerinizi uzak bir yere göndermek kritik öneme sahiptir.

#!/bin/bash
# Backup'ı S3'e veya başka bir remote'a gönder

BACKUP_FILE="/opt/influxdb-backups/$(date +%Y%m%d)*.tar.gz"
S3_BUCKET="s3://sirket-backuplar/influxdb"
REMOTE_HOST="backup-server.internal"
REMOTE_PATH="/backups/influxdb"

# S3'e gönder (aws-cli kurulu olmalı)
aws s3 cp $BACKUP_FILE $S3_BUCKET/ 
    --storage-class STANDARD_IA

# Alternatif: rsync ile uzak sunucuya gönder
rsync -avz --progress 
    /opt/influxdb-backups/ 
    backup-user@${REMOTE_HOST}:${REMOTE_PATH}/ 
    --delete 
    --include="*.tar.gz" 
    --exclude="*"

Bazı ekipler rclone kullanmayı tercih eder çünkü hem S3, hem Google Cloud Storage hem de Backblaze B2 gibi onlarca provider’ı destekler:

# rclone ile backup gönder
rclone copy /opt/influxdb-backups/ 
    remote:influxdb-backups/ 
    --include="*.tar.gz" 
    --log-level INFO

# Sadece son 7 günün backuplarını koru
rclone delete remote:influxdb-backups/ 
    --min-age 7d

Restore İşlemleri

Yedek almak hikayenin yarısıdır. Asıl kritik olan restore işleminin sorunsuz çalışmasıdır. Bir felaket anında restore yapmaya çalışmak, o ana kadar hiç test etmemişseniz kâbus olabilir.

Temel Restore İşlemi

# Sıkıştırılmış yedeği aç
cd /tmp
tar -xzf /opt/influxdb-backups/20240115_020000.tar.gz

# Restore işlemini başlat
influx restore /tmp/20240115_020000 
    --host $INFLUX_HOST 
    --token $INFLUX_TOKEN

# Belirli bir organizasyona restore
influx restore /tmp/20240115_020000 
    --host $INFLUX_HOST 
    --token $INFLUX_TOKEN 
    --org myorg

# Yeni bir organizasyon adıyla restore (izolasyon için faydalı)
influx restore /tmp/20240115_020000 
    --host $INFLUX_HOST 
    --token $INFLUX_TOKEN 
    --org-id "yeni-org-id" 
    --new-org "recovered-org"

Belirli Bir Bucket’ı Restore Etme

Tüm veriyi değil, sadece belirli bir bucket’ı geri yüklemek istediğinizde --bucket parametresini kullanın:

# Önce yeni bir bucket oluştur (mevcut veriyi ezmemek için)
influx bucket create 
    --name "telegraf-recovered" 
    --org myorg 
    --retention 30d

# Bucket ID'sini al
NEW_BUCKET_ID=$(influx bucket list --name "telegraf-recovered" --json | jq -r '.[0].id')

# Belirli bucket'ı restore et
influx restore /tmp/20240115_020000 
    --host $INFLUX_HOST 
    --token $INFLUX_TOKEN 
    --bucket telegraf 
    --new-bucket $NEW_BUCKET_ID

Bu yaklaşım özellikle veri doğrulama senaryolarında çok işe yarar. Mevcut canlı veriyi bozmadan, geri yüklenen veriyi ayrı bir bucket’ta kontrol edebilirsiniz.

InfluxDB 1.x için Backup ve Restore

Eski kurulumlar hala InfluxDB 1.x kullanıyor olabilir. Sözdizimi biraz farklıdır:

# InfluxDB 1.x - Tüm veriyi yedekle
influxd backup -portable /opt/influxdb-backups/$(date +%Y%m%d)

# Belirli bir database'i yedekle
influxd backup -portable 
    -database telegraf 
    /opt/influxdb-backups/telegraf_$(date +%Y%m%d)

# 1.x Restore - Tüm veriyi geri yükle
influxd restore -portable /opt/influxdb-backups/20240115

# Belirli bir database'i restore et
influxd restore -portable 
    -db telegraf 
    /opt/influxdb-backups/20240115

# Farklı bir isimle restore et
influxd restore -portable 
    -db telegraf 
    -newdb telegraf_recovered 
    /opt/influxdb-backups/20240115

Dikkat: 1.x backup’larını 2.x’e restore etmek doğrudan mümkün değildir. Bunun için önce influxd upgrade komutunu veya Flux’u kullanarak veri migration yapmanız gerekir.

Backup Doğrulama: Test Etmezseniz Yedek Almamışsınız Demektir

Bu başlık abartılı değil. Yıllarca backup aldığını sanan ve restore gününde gelen dosyanın bozuk çıktığını gören ekipler vardır. Backup doğrulama scripti yazın ve bunu da cron’a ekleyin.

#!/bin/bash
# /opt/scripts/verify-influxdb-backup.sh

set -euo pipefail

BACKUP_DIR="/opt/influxdb-backups"
TEST_HOST="http://localhost:8087"  # Test için farklı port
LOG_FILE="/var/log/influxdb-backup-verify.log"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}

# En son backup dosyasını bul
LATEST_BACKUP=$(ls -t "${BACKUP_DIR}"/*.tar.gz 2>/dev/null | head -1)

if [ -z "$LATEST_BACKUP" ]; then
    log "HATA: Hic backup dosyasi bulunamadi!"
    exit 1
fi

log "Dogrulanacak backup: $LATEST_BACKUP"

# Backup dosyasının bütünlüğünü kontrol et
if tar -tzf "$LATEST_BACKUP" > /dev/null 2>&1; then
    log "Dosya butunlugu OK"
else
    log "HATA: Backup dosyasi bozuk!"
    exit 1
fi

# Dosya boyutunu kontrol et (1MB'dan küçükse şüphe et)
FILE_SIZE=$(stat -f%z "$LATEST_BACKUP" 2>/dev/null || stat -c%s "$LATEST_BACKUP")
if [ "$FILE_SIZE" -lt 1048576 ]; then
    log "UYARI: Backup dosyasi beklenenden kucuk: $FILE_SIZE bytes"
fi

log "Dogrulama tamamlandi: $LATEST_BACKUP"

Disaster Recovery Senaryosu: Adım Adım

Gerçek hayatta bir felaket anında panikle ne yapılacağını bilmemek durumu daha da kötüleştirir. Senaryo: Disk arızası nedeniyle InfluxDB veri dizini tamamen silindi.

# 1. InfluxDB servisini durdur
systemctl stop influxdb

# 2. Mevcut veri dizinini temizle (ya da yeniden başlat)
# Dikkatli olun, bu işlem geri alınamaz
rm -rf /var/lib/influxdb/engine
rm -rf /var/lib/influxdb/influxd.bolt

# 3. InfluxDB'yi başlat ve ilk kurulum yap
systemctl start influxdb

# İlk kurulum için setup komutunu çalıştır
influx setup 
    --username admin 
    --password "guclu-sifre" 
    --org myorg 
    --bucket default 
    --retention 0 
    --force

# 4. Yeni token'ı al ve kaydet
NEW_TOKEN=$(influx auth list --json | jq -r '.[0].token')
export INFLUX_TOKEN=$NEW_TOKEN

# 5. Son backup'ı bul
LATEST_BACKUP=$(ls -t /opt/influxdb-backups/*.tar.gz | head -1)
echo "Restore edilecek backup: $LATEST_BACKUP"

# 6. Backup'ı aç
cd /tmp
tar -xzf "$LATEST_BACKUP"
BACKUP_DIR=$(ls -d /tmp/20* | tail -1)

# 7. Restore işlemini başlat
influx restore "$BACKUP_DIR" 
    --host http://localhost:8086 
    --token $INFLUX_TOKEN 
    --full

# 8. Servisi kontrol et
systemctl status influxdb

# 9. Veri bütünlüğünü doğrula
influx query 'from(bucket: "telegraf") |> range(start: -1h) |> count()' 
    --org myorg

Bu adımları bir runbook’a yazıp ekibinizle paylaşın. Felaket anında bu belgeye bakarak sakin kafayla ilerleyebilirsiniz.

Zamanlama ve Saklama Politikası

Yedekleme sıklığı ve saklama süresi, verinin kritikliğine ve değişim hızına göre belirlenir.

Production ortamı için önerilen politika:

  • Saatlik snapshot: Son 24 saat için (disk-in-disk, hızlı erişim için)
  • Günlük backup: Son 30 gün için (yerel + uzak depolama)
  • Haftalık backup: Son 12 hafta için (uzak depolama)
  • Aylık backup: Son 12 ay için (arşiv depolama, düşük maliyet için S3 Glacier gibi)

Bu politikayı tek bir script içinde yönetebilirsiniz:

#!/bin/bash
# Saatlik çalışan akıllı yedekleme scripti

HOUR=$(date +%H)
DOW=$(date +%u)    # 1=Pazartesi, 7=Pazar
DOM=$(date +%d)    # Ayın günü

BACKUP_BASE="/opt/influxdb-backups"

# Hangi tip yedek alınacak?
if [ "$DOM" = "01" ]; then
    BACKUP_TYPE="monthly"
    RETENTION=365
elif [ "$DOW" = "7" ] && [ "$HOUR" = "03" ]; then
    BACKUP_TYPE="weekly"
    RETENTION=84
elif [ "$HOUR" = "02" ]; then
    BACKUP_TYPE="daily"
    RETENTION=30
else
    BACKUP_TYPE="hourly"
    RETENTION=1
fi

BACKUP_PATH="${BACKUP_BASE}/${BACKUP_TYPE}/$(date +%Y%m%d_%H%M%S)"
mkdir -p "$BACKUP_PATH"

echo "Backup tipi: $BACKUP_TYPE, Hedef: $BACKUP_PATH"

influx backup "$BACKUP_PATH" 
    --host $INFLUX_HOST 
    --token $INFLUX_TOKEN

# Eski yedekleri temizle
find "${BACKUP_BASE}/${BACKUP_TYPE}" -name "*.tar.gz" 
    -mtime +${RETENTION} -delete

Monitoring: Yedeklerinizi İzleyin

Yedeklemenin çalışıp çalışmadığını da monitörlemek gerekir. Telegraf kullanıyorsanız, backup başarısını da bir metric olarak InfluxDB’ye yazabilirsiniz:

#!/bin/bash
# Backup sonucunu InfluxDB'ye metric olarak yaz

BACKUP_SUCCESS=1
BACKUP_SIZE=0

if /opt/scripts/influxdb-backup.sh; then
    BACKUP_SUCCESS=1
    BACKUP_SIZE=$(du -sb /opt/influxdb-backups/*.tar.gz | tail -1 | cut -f1)
else
    BACKUP_SUCCESS=0
fi

# Line protocol ile metric yaz
curl -s -X POST "${INFLUX_HOST}/api/v2/write?org=${INFLUX_ORG}&bucket=monitoring&precision=s" 
    -H "Authorization: Token ${INFLUX_TOKEN}" 
    -H "Content-Type: text/plain" 
    --data-binary "influxdb_backup,host=$(hostname) success=${BACKUP_SUCCESS},size_bytes=${BACKUP_SIZE} $(date +%s)"

Grafana’da bu metriği izleyerek backup’larınızın düzenli alındığını dashboard üzerinden görebilirsiniz. Alert eklerseniz, backup başarısız olduğunda anında bildirim alırsınız.

Performans İpuçları ve Dikkat Edilmesi Gerekenler

Backup alırken sisteminizi zorlamak istemezsiniz. Birkaç pratik ipucu:

  • Yoğun saatlerde backup almayın: Sorgu trafiğinin düşük olduğu gece saatlerini tercih edin
  • CPU ve IO limitlemesi kullanın: nice ve ionice komutları ile backup prosesinin sistem kaynaklarını ele geçirmesini önleyin
  • Backup boyutunu izleyin: Anormal büyüme veya küçülme veri sorununa işaret edebilir
  • Şifreleme: Backup dosyalarınızı uzak depolamaya göndermeden önce şifreleyin
# CPU ve IO önceliğini düşürülmüş olarak çalıştır
nice -n 15 ionice -c 3 influx backup /opt/influxdb-backups/$(date +%Y%m%d) 
    --host $INFLUX_HOST 
    --token $INFLUX_TOKEN

# GPG ile backup şifrele
gpg --symmetric --cipher-algo AES256 
    /opt/influxdb-backups/20240115.tar.gz

Sonuç

InfluxDB backup stratejisi, sadece bir yedek alma işlemi değil, eksiksiz bir süreçtir. Yedek almak, yedekleri doğrulamak, uzak depolamaya göndermek, saklama politikasını uygulamak ve en kritik adım olan restore işlemini düzenli olarak test etmek bu sürecin vazgeçilmez parçalarıdır.

Şunu asla unutmayın: Restore etmediğiniz bir yedek, olmayan bir yedektir. Ayda en az bir kez backup restore testi yapın. Test ortamınızda bu işlemi gerçekleştirip veri bütünlüğünü doğrulayana kadar kendinizi güvende saymayın.

Bu yazıda anlattığımız scriptleri kendi ortamınıza uyarlayın, token’ları ve path’leri güncelleyin, cron job’larını kurun. Sonra bir akşam kendinize “ya bu yedekler gerçekten çalışıyor mu?” diye sorun ve test edin. O testin sorunsuz geçtiğini gördüğünüzde kendinize gerçek anlamda bir sysadmin diyebilirsiniz.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir