Restic + Backblaze B2 ile Şifreli Sunucu Yedekleme Rehberi

Restic + Backblaze B2 ile Şifreli Sunucu Yedekleme Rehberi

Restic, uçtan uca şifrelenmiş, deduplicated ve incremental backup yapan, modern (Go ile yazılmış) açık kaynak bir backup aracıdır. Tek binary ile dağıtılır, çok platform destekli ve 30+ storage backend'e (S3-uyumlu nesne depolama, Backblaze B2, Wasabi, MinIO, REST server, SFTP, lokal disk) yazabilir.

Büyükweb Türkiye VDS ve dedicated sunucularda Restic + Backblaze B2 kombinasyonu maliyet-etkin ve güvenli bir disaster recovery stratejisidir. Bu rehberde sıfırdan kurulumu, şifreli backup rutinini, otomatik schedule, prune & rotation ve restore süreçlerini adım adım anlatıyoruz.

Restic Avantajları

Özellik	Açıklama
Uçtan uca şifreleme	AES-256 client-side; cloud sağlayıcı bile veriyi göremez
Deduplication	Aynı block'lar tek seferlik depolanır — yer tasarruf
Incremental	İlk full backup; sonrası sadece değişiklik
Cross-platform	Linux, macOS, Windows, BSD
Tek binary	Dependency yok, kolay deploy
30+ backend	S3, B2, Azure, GCS, SFTP, REST, vs.
Snapshot bazlı	Her backup ayrı "snapshot" — geçmişe erişim
Repository check	Bütünlük doğrulama yerleşik

Restic Mimarisi: Chunking ve Deduplication Nasıl Çalışır?

Restic'in deduplication performansının arkasında content-defined chunking (CDC) algoritması var. Klasik yedekleme araçları dosyayı sabit boyutlu bloklara böler (örn. 4 MB); bir dosyanın başına tek byte eklendiğinde tüm sonraki bloklar kayar ve deduplication kırılır. Restic bunun yerine rolling hash (Buzhash) kullanarak dosya içeriğine göre değişken boyutlu (ortalama ~1 MB) chunk sınırları belirler — dosyanın ortasına ekleme veya silme yapılsa bile önceki ve sonraki chunk'lar aynı kalır, sadece değişen kısım yeniden yüklenir.

Repository içinde üç temel obje tipi var:

• Blob: Chunk'lanmış ham veri; SHA-256 hash'i ile adreslenir
• Tree: Dizin yapısını ve dosya metadata'sını (izin, sahiplik, timestamp) tutan JSON obje
• Pack file: Birden fazla blob'un birleştirilip sıkıştırıldığı (zstd) ve şifrelendiği (AES-256-CTR + Poly1305 MAC) dosya; B2'ye asıl yüklenen budur

Bu tasarım sayesinde aynı sunucudan alınan onlarca snapshot, aynı dosyanın değişmeyen kısımlarını tek kopya olarak saklar — 30 günlük bir WordPress sitesinde disk kullanımı ilk backup'tan sadece %10-20 daha fazla olabilir, oysa geleneksel tam kopya (full copy) yöntemiyle 30 kat büyürdü.

Backblaze B2 Neden?

Sağlayıcı	$/TB/ay (2026)	Outbound Trafik
Backblaze B2	$6	$10/TB
S3-uyumlu nesne depolama	$23	$90/TB
Wasabi	$7	Ücretsiz (180 GB/ay sınır)

Backblaze B2 fiyat-performans olarak disaster recovery için en uygun seçenek; S3 API uyumlu, restic ile tam destekli.

Örnek maliyet hesabı: 200 GB veri ve aylık ortalama %5-10 değişim oranıyla (deduplication sonrası depolanan ek veri) çalışan bir VDS için B2 depolama maliyeti yaklaşık 200 GB × $6/TB ≈ $1,2/ay + değişen veri için birkaç kuruşluk ek ücrettir. Outbound trafik yalnızca restore sırasında oluşur — günlük backup'larda veri sadece yukarı (upload) akar ve B2'de upload ücretsizdir. Bu da restic + B2 kombinasyonunu küçük ve orta ölçekli sunucular için ayda birkaç dolar seviyesinde tutar.

Restic vs Geleneksel Yedekleme Yöntemleri

Sunucu yöneticileri genelde restic'e geçmeden önce rsync + tar, cron ile mysqldump script'leri veya panel (cPanel/Plesk) yerleşik backup'larını kullanır. Bu yöntemler çalışır ama bazı önemli farklar var:

Kriter	Restic	rsync + tar	Panel Yerleşik Backup
Şifreleme	Client-side AES-256, varsayılan	Manuel (gpg ile ek adım)	Sağlayıcıya bağlı, genelde yok
Deduplication	Var (block seviyesi)	Yok	Yok / sınırlı
Incremental	Otomatik, blok bazlı	rsync delta var, tar'da yok	Genelde full veya dosya bazlı incremental
Off-site (bulut)	Yerleşik (30+ backend)	Ek script gerekir	Panel'e göre değişir
Snapshot/versioning	Yerleşik (restic snapshots)	Manuel klasörleme	Sınırlı sayıda kopya
Bütünlük doğrulama	restic check yerleşik	Yok	Yok
Restore hızı	Tek komut, dosya bazlı	tar extract, tüm arşiv	Panel arayüzünden

Bu tablo panel yedeklerinin gereksiz olduğu anlamına gelmez — Büyükweb hosting, reseller ve VDS paketlerinde standart olarak sunulan günlük otomatik yedek ilk savunma hattınızdır ve genellikle en hızlı geri dönüş noktasıdır. Restic + B2 ise 3-2-1 yedekleme kuralının off-site/farklı ortam ayağını tamamlayan ikinci, bağımsız bir kopyadır: en az üç kopya (orijinal + panel yedeği + restic/B2), en az iki farklı ortam (sunucu diski + bulut nesne depolama) ve en az bir off-site (coğrafi olarak ayrı) kopya sağlar. Sunucunun tamamen erişilemez hale geldiği (donanım arızası, yanlışlıkla silme, ransomware) senaryolarda bağımsız off-site kopya kritik önem taşır.

Adım 1: Restic Kurulum

Ubuntu / Debian

sudo apt update
sudo apt install restic
restic version

apt paketi bazen eski olur; en son sürüm için resmi binary:

# Latest release (örn 0.17.0)
wget https://github.com/restic/restic/releases/download/v0.17.0/restic_0.17.0_linux_amd64.bz2
bunzip2 restic_0.17.0_linux_amd64.bz2
sudo mv restic_0.17.0_linux_amd64 /usr/local/bin/restic
sudo chmod +x /usr/local/bin/restic
restic version

CentOS / Rocky / Alma

sudo dnf install restic

macOS

brew install restic

Adım 2: Backblaze B2 Hesabı Hazırlık

1. https://www.backblaze.com/b2/cloud-storage.html adresine git → ücretsiz hesap (10 GB free)
2. Buckets → Create Bucket:
   • Bucket Name: my-server-backups-2026 (global unique)
   • Files in bucket are: Private
   • Object Lock: Disable (veya enable — ransomware koruması)
   • Default Encryption: SSE-B2
3. Application Keys → Add a New Application Key:
   • Key Name: restic-backup
   • Allow access to: bucket'inizi seç
   • Type of access: Read and Write
4. Application Key ID ve Application Key'i kopyalayın (key 1 kez gösterilir)

Adım 3: Environment Variables

# ~/.restic-env
export B2_ACCOUNT_ID=YOUR_KEY_ID
export B2_ACCOUNT_KEY=YOUR_APP_KEY
export RESTIC_REPOSITORY=b2:my-server-backups-2026:restic
export RESTIC_PASSWORD_FILE=~/.restic-password

chmod 600 ~/.restic-env

Şifreleme Anahtarı

# Güçlü repository şifresi oluştur (kayıp = backup'a erişim yok!)
openssl rand -base64 64 > ~/.restic-password
chmod 400 ~/.restic-password

# YEDEK AL — bu dosya kaybolursa backup'lar erişilmez!
cp ~/.restic-password /backup/restic-password.bak
gpg --encrypt -r your@email.com /backup/restic-password.bak

Adım 4: Repository Init

source ~/.restic-env
restic init

Output:

created restic repository abc123 at b2:my-server-backups-2026:restic

Please note that knowledge of your password is required to access the repository.
Losing your password means that your data is irrecoverably lost.

Adım 5: İlk Backup

source ~/.restic-env

# /home/user dizinini yedekle
restic backup /home/user --tag user-home --tag full

# Birden fazla dizin
restic backup /etc /var/www /home/user --exclude-file=/root/.restic-exclude

Exclude Dosyası

# ~/.restic-exclude
*.tmp
*.log
**/cache/
**/logs/
node_modules/
.git/objects/
/proc
/sys
/dev
/tmp
/run
/mnt
/media
/var/cache
/var/log

İlk backup full (saatler sürebilir). Sonraki backup'lar incremental + deduplicated → çok hızlı.

Adım 6: Snapshot Yönetimi

# Tüm snapshot'ları listele
restic snapshots

# Sadece belirli tag'i
restic snapshots --tag full

# Snapshot detay
restic ls SNAPSHOT_ID

# Snapshot'tan dosya bul
restic find "wp-config.php"

# Snapshot'tan diff
restic diff PREV_ID CURR_ID

Adım 7: Restore

Tam Snapshot Restore

restic restore SNAPSHOT_ID --target /restore/

Belirli Dosya Restore

restic restore SNAPSHOT_ID --target /restore/ --include /home/user/important-file.txt

Snapshot Mount (FUSE)

mkdir /mnt/restic
restic mount /mnt/restic

# Snapshot'lar /mnt/restic/snapshots/ içinde
ls /mnt/restic/snapshots/

# Specific snapshot
ls /mnt/restic/snapshots/2026-05-07T03:00:00Z/

# Unmount
umount /mnt/restic

Adım 8: Otomatik Backup (Cron)

backup.sh

#!/bin/bash
# /usr/local/bin/restic-backup.sh

set -e
source ~/.restic-env

# Pre-backup: MySQL dump
mysqldump --all-databases --single-transaction --routines --triggers > /backup/mysql-dump.sql

# Pre-backup: PostgreSQL dump
sudo -u postgres pg_dumpall > /backup/postgres-dump.sql

# Restic backup
restic backup /etc /var/www /home /backup --tag daily --exclude-file=/root/.restic-exclude

# Prune (eski snapshot'ları temizle)
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --keep-yearly 2 --prune

# Health check
restic check --read-data-subset=1G

echo "Backup completed at $(date)"

sudo chmod +x /usr/local/bin/restic-backup.sh

Cron

sudo crontab -e

# Her gün 03:00
0 3 * * * /usr/local/bin/restic-backup.sh >> /var/log/restic-backup.log 2>&1

Systemd Timer (Modern Alternatif)

/etc/systemd/system/restic-backup.service:

[Unit]
Description=Restic Backup
After=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/root/.restic-env
ExecStart=/usr/local/bin/restic-backup.sh

/etc/systemd/system/restic-backup.timer:

[Unit]
Description=Daily Restic Backup

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

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl list-timers | grep restic

Adım 9: Retention Policy

# 7 günlük + 4 haftalık + 6 aylık + 2 yıllık
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --keep-yearly 2 --prune

Politika	Tutulan
--keep-last 5	Son 5 snapshot
--keep-hourly 24	Son 24 saatten her saatten 1
--keep-daily 7	Son 7 günden her gün 1
--keep-weekly 4	Son 4 haftadan her hafta 1
--keep-monthly 6	Son 6 aydan her ay 1
--keep-yearly 2	Son 2 yıldan her yıl 1

--prune referansı kalmayan blok'ları storage'dan siler. Cost saving için önemli.

Adım 10: Repository Health

Hızlı Check

restic check

Tam Check (Aylık)

restic check --read-data

Tüm blok'ları indirir + checksum doğrular. Bandwidth tüketir ama disaster recovery güvenirliği için ayda bir.

Adım 11: Multi-Server Backup

Tek Repository, Birden Fazla Sunucu

Aynı bucket'a farklı sunucular yedekleyebilir. Her sunucuya farklı hostname + tag:

# Sunucu A
restic backup /home --hostname server-a --tag prod

# Sunucu B
restic backup /home --hostname server-b --tag prod

# Liste
restic snapshots --host server-a

Filtre + Restore

# Sadece server-a snapshots'ları
restic snapshots --host server-a

# Belirli sunucudan restore
restic restore latest --host server-a --target /restore/

Adım 12: Çoklu Repository

Production critical data ve test data'yı ayrı bucket'larda tutmak güvenli:

# Critical
export RESTIC_REPOSITORY=b2:critical-bucket:restic
restic backup /etc /home

# Bulky media (ayrı bucket)
export RESTIC_REPOSITORY=b2:media-bucket:restic
restic backup /var/www/media

Adım 13: Encryption Key Yönetimi

Restic her repository tek master key ile şifrelenir. Birden fazla erişim password'ü ekleyebilirsiniz:

# Şu anki password ile bağlan
restic key list

# Yeni password ekle (ek admin için)
restic key add

# Eski password'ü kaldır
restic key remove ID

Adım 14: Bandwidth Limit

# 5 MB/s yukarı, 10 MB/s aşağı
restic backup /home --limit-upload 5120 --limit-download 10240

Yoğun saat dışı yedekleme için cron job'da limit yok; gündüz manuel için limit kullan.

Adım 15: Monitoring + Alerting

Healthchecks.io

Cron job'da başarısız olursa Slack/email/SMS:

# backup.sh sonu
curl -fsS --retry 3 https://hc-ping.com/UUID-FROM-HEALTHCHECKS

# Hata durumunda:
trap 'curl -fsS --retry 3 https://hc-ping.com/UUID-FROM-HEALTHCHECKS/fail' ERR

Email Alert

# backup.sh
{
  /usr/local/bin/restic-backup.sh
} 2>&1 | mail -s "Backup Result $(date)" admin@example.com

Adım 16: WordPress / cPanel için Strateji

WordPress

# /usr/local/bin/wp-backup.sh
#!/bin/bash
source ~/.restic-env

# DB dump
mysqldump --single-transaction wordpress > /backup/wp-db.sql

# Restic backup
restic backup /var/www/html /backup --tag wordpress --tag daily

restic forget --keep-daily 7 --keep-monthly 3 --prune

cPanel

cPanel kendi backup'ları + offsite restic kombinasyonu:

# /usr/local/bin/cpanel-offsite.sh
restic backup /backup/cpanel-backups /home --tag cpanel --tag daily

cPanel WHM panel'inden Backup Configuration ile günlük backup → restic offsite copy.

Adım 17: Disaster Recovery Test

Backup'ın işe yaramayacağı tek senaryo: hiç test etmemek.

Aylık Test

# Test makinasında / VM'de
mkdir /tmp/restore-test
restic restore latest --target /tmp/restore-test
diff -r /tmp/restore-test/etc /etc | head

Mock Database Restore

# DB dump'ı yeni MySQL'e import edip uygulama çalıştır
mysql -u root -p test_db < /tmp/restore-test/backup/mysql-dump.sql
mysql -u root -p test_db -e "SHOW TABLES;"

Örnek Senaryo: E-ticaret Sitesinde Restic + B2 Kurulumu (Uçtan Uca)

Aşağıda orta ölçekli bir WooCommerce mağazasının (günlük ortalama birkaç yüz sipariş, ürün görselleri dahil ~80 GB disk kullanımı) Büyükweb VDS üzerinde restic + B2 ile nasıl korunduğuna dair gerçekçi bir örnek var.

Ortam:

• 4 vCPU / 8 GB RAM Büyükweb VDS, Ubuntu 24.04
• WordPress + WooCommerce, MySQL veritabanı (~3 GB), medya klasörü (~75 GB)
• Panelde günlük otomatik yedek zaten aktif (VDS paketi standardı) — restic bunun off-site tamamlayıcısı

Kurulum adımları (özet):

1. restic binary kurulur (Adım 1), B2'de store-woocommerce-backups adında private bucket + Object Lock (7 gün) açılır (Adım 2)
2. ~/.restic-env ve ~/.restic-password oluşturulur, şifre password manager'a + kasadaki kağıda yedeklenir (Adım 3)
3. restic init ile repository başlatılır (Adım 4)
4. İlk full backup gece 03:00'te manuel tetiklenir: /var/www/html + /backup/mysql-dump.sql — 75 GB veri, yüksek hızlı bağlantıda yaklaşık 25-35 dakika sürer
5. wp-backup.sh script'i (Adım 16) cron'a bağlanır: her gece 03:30 (panel yedeğinden 30 dk sonra, disk I/O çakışmasını önlemek için) çalışır
6. Retention: --keep-daily 7 --keep-weekly 4 --keep-monthly 6 — 3 aylık test döneminde toplam depolama 75 GB'lık ilk kopya + günlük değişim overhead'i ile yaklaşık 95-100 GB'a stabilize olur
7. Healthchecks.io entegrasyonu ile backup başarısız olursa 15 dakika içinde e-posta uyarısı
8. Ayda bir, ayrı bir test VDS'inde restic restore latest çalıştırılıp WooCommerce sitesi ayağa kaldırılarak restore süresi ölçülür (Adım 17)

Sonuç (3 aylık ölçüm):

Metrik	Değer
Aylık B2 depolama maliyeti	~$0,60-0,70 (100 GB × $6/TB)
İlk full backup süresi	~30 dk
Günlük incremental backup süresi	2-4 dk
Tam restore süresi (test ortamında)	~40-55 dk (75 GB indirme + extract)
RPO (Recovery Point Objective)	24 saat (günlük backup)
RTO (Recovery Time Objective, ölçülen)	~1 saat

Bu senaryoda mağaza sahibinin toplam ek maliyeti ayda 1 doların altında kalırken, sunucunun tamamen kaybedilmesi (disk arızası, yanlış rm -rf, ransomware) durumunda bağımsız, coğrafi olarak ayrı bir kopyadan 1 saat içinde tam geri dönüş mümkün olmuştur.

Güvenlik En İyi Uygulamaları

Restic + B2 kurulumunu üretim ortamında çalıştırmadan önce kontrol edilmesi gereken noktalar:

• Application Key kapsamını daraltın: B2 tarafında "Allow access to" alanında sadece backup bucket'ını seçin; hesabınızın tüm bucket'larına erişebilen bir key asla kullanmayın.
• Repository şifresini asla sunucuda tek kopya bırakmayın: ~/.restic-password dosyası kaybolursa (disk arızası, yanlışlıkla silme) backup'lara erişim de kalıcı olarak biter. En az bir kopyayı sunucu dışında (şifreli USB, password manager, kağıt çıktı kasada) saklayın.
• .restic-env ve .restic-password dosya izinlerini sıkılaştırın: chmod 600/chmod 400 tek başına yeterli değildir, dosyaların root dışında okunabilir olmadığından ls -la ile emin olun.
• Object Lock'ı değerlendirin: B2 bucket oluştururken Object Lock etkinleştirilirse, belirlenen süre boyunca dosyalar silinemez veya değiştirilemez — bu, ransomware saldırganının backup'ları da şifrelemesini ya da silmesini engeller.
• restic key add ile ikinci bir erişim anahtarı tanımlayın: Tek şifreye bağımlı kalmayın; ikinci bir admin veya acil durum erişimi için ayrı key ekleyip orijinal şifreyi paylaşmayın.
• Cron/systemd loglarını izleyin: Sessizce başarısız olan bir backup job'u haftalar sonra fark edilirse restore anında veri kaybı riski oluşur — Healthchecks.io gibi bir dead-man's-switch servisiyle "backup çalışmadı" durumunu anında öğrenin.
• restic check çıktısını otomatik parse edin: Cron script'i sadece "çalıştı mı" değil "hatasız bitti mi" kontrolü yapmalı; exit code'u log dosyasına kaydedin.

Yaygın Sorunlar

Sorun	Çözüm
"unable to open repository"	RESTIC_PASSWORD doğru mu? Network var mı?
"backup verifies fail"	Disk corruption olabilir; check --read-data
B2 rate limit	--limit-upload ile düşür
Out of memory	İndex tut RAM'de — VDS RAM artır
Çok yavaş ilk backup	Bandwidth + concurrency --option b2.connections=20
Hangi snapshot 1 hafta önceyi içerir?	restic snapshots + tarih
Restore yetersiz disk	--target başka mount'a
"wrong password or no key found"	Şifre dosyası/env değişkeni yanlış; birden fazla key varsa restic key list ile kontrol edin
Lock dosyası kilitli kaldı	Kesintiye uğrayan backup sonrası restic unlock ile stale lock'ı temizleyin
forget sonrası storage boşalmıyor	--prune parametresini unutmayın; forget tek başına sadece referansı kaldırır, veriyi silmez
B2 bucket "unauthorized" hatası	Application Key'in bucket kapsamı ve Read/Write izni doğru mu kontrol edin

Çoğu sorun ya kimlik bilgisi (şifre/anahtar) ya da network/bandwidth kaynaklıdır. restic unlock komutu, kesintiye uğrayan bir backup'ın arkada bıraktığı stale lock dosyasını temizler ve genelde ilk denenmesi gereken adımdır. restic forget komutunun tek başına veri silmediğini, sadece snapshot referansını kaldırdığını unutmayın — gerçek storage temizliği için --prune flag'i (veya ayrı restic prune komutu) şarttır.

Sıkça Sorulan Sorular

Backblaze B2 Türkiye'den ne kadar hızlı?

B2 EU/US lokasyonlarında DC'leri var; Türkiye'den 50-150 ms latency. 1 Gbps VDS bağlantısında 50-80 MB/s upload tipik.

S3 yerine neden B2?

Maliyet 4x daha az. Büyük bulut ekosistemine bağlı değilseniz B2 daha verimli.

Linux dışında çalışıyor mu?

Evet — Windows, macOS, FreeBSD. Aynı binary, aynı repository.

Şifre kaybedersem?

Veriler kalıcı olarak erişilemez. Mutlaka şifreyi 2-3 yere yedekleyin (password manager + paper print + GPG-encrypted USB).

Restic ile dosya bazında geri yükleme yapabilir miyim?

Evet — restic mount ile snapshot'ları FUSE filesystem olarak browse, cp ile kopyala.

Backup süresi nasıl ölçülür?

time restic backup ... komutu süre verir. Tipik 50 GB site ilk backup: 30-60 dk. Sonraki incremental: 1-5 dk.

Birden fazla VDS'i aynı repo'ya yedekleyebilir miyim?

Evet — --hostname ile ayır. Deduplication tüm sunucularda ortak block'ları tek seferlik tutar = daha az depolama maliyeti.

Restic açık kaynak mı, kim geliştiriyor?

Evet, restic tamamen açık kaynak (BSD-2-Clause lisans) ve GitHub üzerinde aktif bir topluluk tarafından geliştiriliyor. Ticari bir şirkete bağımlı olmadığından vendor lock-in riski yoktur; repository formatı dokümante edilmiştir.

Object Lock açtıktan sonra retention politikasını değiştirebilir miyim?

Object Lock ile kilitlenen dosyalar belirlenen süre dolmadan silinemez — bu, restic forget --prune komutunun da o dosyaları temizleyemeyeceği anlamına gelir. Retention süresini kısaltmak isterseniz yeni bucket'a geçmeniz gerekebilir; bu yüzden Object Lock süresini işletmenizin gerçek ihtiyacına göre (örn. ransomware koruması için 7-14 gün) dikkatli seçin.

Restic ile Büyükweb VDS'in panel yedeğini karşılaştırınca hangisini önce kurmalıyım?

Panel yedeği (VDS paketlerinde standart günlük otomatik yedek) zaten aktiftir ve ek kurulum gerektirmez — bu ilk savunma hattınızdır. Restic + B2 kurulumu, aynı veri için ikinci, off-site ve şifreli bir kopya eklemek isteyenler için önerilir; ikisi birbirinin yerine değil, tamamlayıcısı olarak düşünülmelidir.

İlgili Rehberler

• VDS Sunucu Yedekleme Stratejileri
• Veritabanı Yedekleme Stratejileri Full Incremental
• WordPress Otomatik Yedekleme UpdraftPlus
• Linux Disk Dosya Sistemi Yönetimi
• Türkiye VDS Sunucu

İlgili Büyükweb Hizmetleri

Sunucu yedekleme ve disaster recovery için Türkiye lokasyonlu Büyükweb hizmetleri:

• Türkiye VDS Sunucu
• Dedicated Sunucu
• Sunucu Barındırma (Colocation)
• cPanel Web Hosting
• Linux Reseller Hosting

Sorularınız için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz.