Site Yedeğini Google Drive'a Otomatik Gönderme Nasıl Yapılır?

Yedekleri Google Drive'a gönderme fikri neredeyse her zaman aynı anda doğar: sunucuda düzenli yedek almaya başlarsınız, birkaç hafta sonra df -h çıktısına bakıp yedeklerin diskin yarısını yediğini fark edersiniz ve aklınıza gelen ilk soru şu olur — "bunları zaten kullandığım Drive hesabına atsam olmaz mı?" Olur, hatta olmalı. Çünkü sunucunun kendi diskinde duran bir yedek, o sunucu çöktüğünde yedek olmaktan çıkar; sadece aynı gemide batan ikinci bir kopyadır. Yedeğin işe yaraması için farklı bir makinede, farklı bir sağlayıcıda, ideal olarak farklı bir hesabın altında durması gerekir.

Bu yazıda, sunucudaki yedek klasörünün her gece kimsenin müdahalesi olmadan Google Drive'a (ya da Dropbox, OneDrive, S3 uyumlu bir depoya) yüklenmesini baştan sona kuruyoruz. Masaüstü uygulaması yok, tarayıcıdan sürükle-bırak yok; sunucuda çalışan, terminali olmayan bir makinede bile yetkilendirilebilen bir kurulum var. Bunun yanında Türkçe kaynaklarda neredeyse hiç konuşulmayan üç konuyu da açıkça ele alacağız: yetkilendirme dosyasının sunucuda nerede ve hangi izinlerle duracağı, Drive hesabı ele geçirilirse yedeklerin de gitmesi riskine karşı ne yapılacağı ve depolama kotası dolduğunda yedeğin nasıl sessizce başarısız olup aylarca fark edilmediği.

Sunucudan Buluta Yedek Yüklemek Ne Demek#

Sunucudan bulut yedekleme, yerelde oluşturulmuş arşiv dosyalarının komut satırından çalışan bir istemciyle uzak depolama alanına kopyalanmasıdır. Google Drive'ın masaüstü uygulaması bu iş için kullanılamaz — o uygulama grafik arayüzü olan bir Windows/macOS makinesi bekler, sunucunuzda ise ne masaüstü ne tarayıcı vardır.

Doğru araç rclone. Tek bir çalıştırılabilir dosyadan ibarettir, kırktan fazla depolama sağlayıcısıyla aynı komut setini kullanır ve bir sağlayıcıdan diğerine geçmek için sadece hedef adını değiştirmeniz yeterlidir. Bugün Drive'a yazıp yarın S3 uyumlu bir kovaya geçmek isterseniz betiğinizde tek kelime değişir.

Akış şu şekilde kurulur:

1. Yedek üretilir (dosyalar + veritabanı dökümü tek bir arşive girer).
2. Arşiv şifrelenir veya doğrudan yüklenir.
3. rclone arşivi uzak depoya kopyalar.
4. Uzak depodaki eski kopyalar saklama süresine göre silinir.
5. İşin sonucu kaydedilir ve başarısızlıkta haber verilir.

Beşinci adım olmadan bu zincir er ya da geç sessizce kopar. Bu yazının en önemli bölümü de orası.

rclone Kurulumu ve Sunucuda Yetkilendirme#

rclone kurulumu tek satırdır; asıl mesele tarayıcısı olmayan bir makinede Google hesabına yetki vermektir.

curl https://rclone.org/install.sh | sudo bash
rclone version

Kurulum sonrası yapılandırmaya girin:

rclone config

Sırasıyla n (new remote), ada gdrive yazın, sağlayıcı listesinden Google Drive'ı seçin. client_id ve client_secret sorulduğunda boş bırakabilirsiniz ama bırakmayın — boş bırakırsanız rclone'un paylaşılan varsayılan istemci kimliği kullanılır ve bu kimlik binlerce kullanıcı tarafından paylaşıldığı için hız limitine takılmanız çok olasıdır. Google Cloud Console'da kendi projenizi açıp bir OAuth istemcisi oluşturmak on dakika sürer ve yükleme hızınızı belirgin biçimde değiştirir.

scope sorusunda drive yerine drive.file seçin. Bu ayarın anlamı büyüktür: drive.file kapsamı, rclone'un yalnızca kendi oluşturduğu dosyaları görmesine ve yönetmesine izin verir. Yani sunucuya sızan biri o yetkilendirmeyle Drive'ınızdaki fotoğraflarınıza, sözleşmelerinize, hiçbir şeyinize erişemez — sadece yedek klasörünü görür.

Sıra tarayıcı adımında. Sunucuda tarayıcı olmadığı için Use auto config? sorusuna n deyin. rclone size uzun bir komut verir; onu kendi bilgisayarınızın terminalinde çalıştırırsınız:

rclone authorize "drive" "eyJzY29wZSI6ImRyaXZlLmZpbGUifQ"

Bilgisayarınızda tarayıcı açılır, hesabı seçersiniz, terminal size bir token bloğu basar. O bloğu kopyalayıp sunucudaki bekleyen soruya yapıştırırsınız. Bağlantıyı doğrulayın:

rclone lsd gdrive:
rclone mkdir gdrive:sunucu-yedek

İkinci komut hata vermeden dönüyorsa yetkilendirme çalışıyor demektir.

Yetkilendirme Dosyası Nerede Durur ve Nasıl Korunur#

rclone yapılandırması /root/.config/rclone/rclone.conf dosyasında saklanır ve bu dosya, Drive hesabınıza erişim sağlayan yenileme jetonunu düz metin olarak içerir. Bu, bu kurulumun en kritik ve Türkçe kaynaklarda en çok atlanan noktasıdır.

Dosyayı sunucuya sızan bir saldırgan okursa, sizin adınıza Drive'a bağlanabilir. drive.file kapsamını seçtiyseniz zararı yedek klasörüyle sınırlıdır ama yine de sıkılaştırın:

chmod 600 /root/.config/rclone/rclone.conf
chown root:root /root/.config/rclone/rclone.conf
ls -l /root/.config/rclone/rclone.conf

Çıktıda -rw------- görmelisiniz. Bir adım öteye gitmek isterseniz yapılandırmayı parolayla şifreleyin:

rclone config
# s) Set configuration password

Ancak dikkat: şifrelenmiş yapılandırma, cron'dan çalışan bir betikte parola sormaya kalkar ve iş orada donar. Otomasyonda kullanacaksanız parolayı RCLONE_CONFIG_PASS ortam değişkeniyle geçirmeniz gerekir — bu da parolayı başka bir dosyaya taşımak demektir, yani sorunu çözmez, yerini değiştirir. Pratik ve gerçekten koruyucu yaklaşım şudur: drive.file kapsamı + 600 izin + yedeklerin şifreli yüklenmesi. Sunucu güvenliğinin genel resmi için sunucu sertleştirme kontrol listesi yazısındaki adımları da uygulayın.

Yüklenecek Yedeği Hazırlama#

Yükleme adımından önce ortada düzgün bir arşiv olmalı. Yaygın hata, sadece dosyaları yükleyip veritabanını unutmaktır — geri dönmeye çalıştığınızda elinizde çalışmayan bir tema klasörü kalır. Site yedeği nasıl alınır yazısı bu tarafı ayrıntılı anlatıyor; burada özet komut şu:

#!/bin/bash
set -euo pipefail

TARIH=$(date +%F)
YEDEK_DIZIN=/var/yedek
SITE_DIZIN=/var/www/site.com
mkdir -p "$YEDEK_DIZIN"

# Veritabanı dökümü
mysqldump --single-transaction --quick --routines \
  -u yedekci -p'PAROLA' site_db > "$YEDEK_DIZIN/db-$TARIH.sql"

# Dosyalar + döküm tek arşivde
tar -czf "$YEDEK_DIZIN/site-$TARIH.tar.gz" \
  -C /var/www site.com \
  -C "$YEDEK_DIZIN" "db-$TARIH.sql"

rm -f "$YEDEK_DIZIN/db-$TARIH.sql"

--single-transaction bayrağı InnoDB tablolarında tabloları kilitlemeden tutarlı bir döküm alır; canlı sitede yedek alırken bu bayrağı atlamak ziyaretçilere yansıyan kısa donmalara yol açar. Veritabanı tarafının incelikleri için mysqldump ile veritabanı yedekleme yazısına bakın.

Yedeği Google Drive'a Yükleme ve Otomatikleştirme#

Yükleme tek komuttur:

rclone copy /var/yedek/site-2026-08-11.tar.gz gdrive:sunucu-yedek/ \
  --transfers 4 --checkers 8 --drive-chunk-size 64M \
  --log-file /var/log/rclone-yedek.log --log-level INFO

Bayrakları açalım. --drive-chunk-size varsayılan olarak 8 MB'dır; büyük arşivlerde 64M'ye çıkarmak yükleme süresini gözle görülür şekilde kısaltır, karşılığında o kadar RAM harcar. --transfers 4 aynı anda dört dosya gönderir. --log-file olmadan cron'dan çalışan bir yüklemenin neden başarısız olduğunu asla öğrenemezsiniz.

copy ile sync arasındaki farkı karıştırmayın — bu fark veri kaybettirir. copy kaynakta olanı hedefe ekler, hedefteki fazlalıklara dokunmaz. sync hedefi kaynağın aynısı yapar; kaynakta olmayan her şeyi hedeften siler. Yerel yedek klasörünüzü temizleyip ardından sync çalıştırırsanız Drive'daki tüm geçmişiniz silinir. Yedek yüklemesinde daima copy kullanın.

Tümünü tek betiğe alalım:

#!/bin/bash
# /usr/local/bin/bulut-yedek.sh
set -euo pipefail

TARIH=$(date +%F)
YEDEK_DIZIN=/var/yedek
HEDEF="gdrive:sunucu-yedek"
LOG=/var/log/bulut-yedek.log

exec >> "$LOG" 2>&1
echo "=== $(date '+%F %T') yedek başladı ==="

mysqldump --single-transaction --quick -u yedekci -p"$DB_PAROLA" site_db \
  > "$YEDEK_DIZIN/db-$TARIH.sql"
tar -czf "$YEDEK_DIZIN/site-$TARIH.tar.gz" \
  -C /var/www site.com -C "$YEDEK_DIZIN" "db-$TARIH.sql"
rm -f "$YEDEK_DIZIN/db-$TARIH.sql"

rclone copy "$YEDEK_DIZIN/site-$TARIH.tar.gz" "$HEDEF/" \
  --drive-chunk-size 64M --log-level INFO

# Uzak depoda 30 günden eskileri sil
rclone delete "$HEDEF/" --min-age 30d
rclone cleanup gdrive:

# Yerelde 3 günden eskileri sil
find "$YEDEK_DIZIN" -name 'site-*.tar.gz' -mtime +3 -delete

echo "=== $(date '+%F %T') yedek bitti ==="

Çalıştırma izni verip cron'a bağlayın:

chmod 700 /usr/local/bin/bulut-yedek.sh
crontab -e

15 3 * * * DB_PAROLA='parola' /usr/local/bin/bulut-yedek.sh

Saat seçimi önemsiz değildir: yedek işlemi disk ve CPU yer, gündüz çalıştırırsanız ziyaretçi bunu hisseder. Zamanlama söz dizimi konusunda cron görevleri yazısı ayrıntılı bir referans sunuyor. Yedek sıklığına nasıl karar verileceği ise ne sıklıkta yedek alınmalı yazısının konusu.

rclone cleanup Adımını Neden Atlayamazsınız#

rclone delete komutu Google Drive'da dosyayı çöp kutusuna taşır, kalıcı olarak silmez. Çöp kutusundaki dosyalar depolama kotanızdan saymaya devam eder. Yani sadece delete çalıştıran bir betik, aylar boyunca "eskileri temizliyorum" sanır ama Drive alanınız hiç boşalmaz. rclone cleanup gdrive: komutu çöp kutusunu boşaltarak alanı gerçekten geri verir.

Bu davranış Dropbox ve OneDrive'da da benzerdir; her sağlayıcının sürüm geçmişi ve çöp kutusu politikası vardır. Kurulumdan bir ay sonra hesabınızın kullanılan alanına bakıp beklediğiniz rakamı görüp görmediğinizi mutlaka doğrulayın.

Kota Dolduğunda Yedek Neden Sessizce Ölür#

Bu, kurulumun en sinsi arızasıdır: Drive alanınız dolduğunda rclone hata döndürür, cron o hatayı bir yere yazmaz, siz de aylarca yedek aldığınızı sanırsınız. Gerçek yedeğe ihtiyaç duyduğunuz gün en son kopyanın altı ay öncesine ait olduğunu keşfedersiniz.

Tipik hata çıktısı şudur:

ERROR : site-2026-08-11.tar.gz: Failed to copy: googleapi: Error 403:
The user's Drive storage quota has been exceeded., storageQuotaExceeded

Bir başkası, kendi OAuth istemcinizi kurmadığınızda karşınıza çıkar:

ERROR : Failed to copy: googleapi: Error 403: User rate limit exceeded.,
userRateLimitExceeded

Çözüm, betiğin sonucunu izlemektir. En basit hâli çıkış kodunu kontrol edip e-posta atmaktır:

if ! rclone copy "$YEDEK_DIZIN/site-$TARIH.tar.gz" "$HEDEF/" --log-level INFO; then
  echo "Yedek yüklenemedi: $TARIH" | mail -s "YEDEK HATASI - site.com" [email protected]
  exit 1
fi

Daha sağlamı "ölü adam anahtarı" mantığıdır: iş başarıyla bittiğinde bir izleme servisine sinyal gönderirsiniz; sinyal gelmediğinde uyarı üretilir. Böylece sunucu tamamen kapansa bile haberiniz olur. Uptime Kuma bu tür kontrolleri kendi sunucunuzda barındırarak yapmanızı sağlar.

Ayda bir de olsa yüklenen arşivi indirip gerçekten açılabildiğini kontrol edin:

rclone copy gdrive:sunucu-yedek/site-2026-08-11.tar.gz /tmp/test/
tar -tzf /tmp/test/site-2026-08-11.tar.gz | head -20

Test edilmemiş yedek, yedek değildir.

Hesap Ele Geçirilirse Yedekler de Gider mi#

Evet, gider — ve bu ihtimal yeterince ciddiye alınmaz. Google hesabınızın parolası ele geçirilirse saldırgan Drive'daki yedeklerinize erişir; hem indirebilir hem silebilir. Fidye yazılımı senaryosunda daha kötüsü olur: sunucuya sızan yazılım rclone yapılandırmasını bulur, uzak depodaki yedekleri de siler ve geri dönecek hiçbir şey kalmaz.

Üç katmanlı savunma kurun:

Yedekleri şifreleyin. rclone'un crypt katmanı, dosyaları sunucudan çıkmadan önce şifreler; Drive'a giden dosya adları bile okunamaz hâle gelir. Yeni bir remote tanımlayın:

rclone config
# n) yeni remote → ad: gizli
# storage: crypt
# remote: gdrive:sunucu-yedek
# filename_encryption: standard
# İki parola belirleyin ve MUTLAKA parola yöneticinize kaydedin

Artık hedef gizli: olur. Parolayı kaybederseniz yedeklerinizi kimse açamaz, bu yüzden parolayı sunucu dışında saklayın.

Hesabı sertleştirin. Yedek için ayrı bir Google hesabı kullanın, o hesapta iki faktörlü doğrulama açık olsun ve günlük işlerinizde kullandığınız hesapla karıştırmayın.

Üçüncü kopyayı ayrı tutun. 3-2-1 kuralı hâlâ geçerlidir: üç kopya, iki farklı ortam, biri tesis dışında. Drive ikinci kopyadır. Haftalık bir kopyayı da farklı bir sağlayıcıya ya da yalnızca ekleme yapılabilen (append-only) bir depoya gönderin. Borg ile sunucu yedekleme ve restic ile yedekleme yazıları, artımlı ve şifreli depo mantığını kuran araçları anlatıyor; ikisi de rclone ile birlikte kullanılabilir.

Google Drive Yerine Başka Hedefler#

rclone'un en güçlü yanı hedef değiştirmenin tek satırlık iş olmasıdır. Aynı betik, remote adını değiştirerek başka sağlayıcılara yazar.

S3 uyumlu depolamanın belirgin bir üstünlüğü vardır: sürümleme ve nesne kilidi ile yedeği belirli bir süre boyunca hiç kimse (yönetici bile) silemeyecek şekilde ayarlayabilirsiniz. Fidye yazılımına karşı gerçek koruma budur. Paylaşımlı hosting kullanıyorsanız kendi cron'unuzu kurmadan önce paylaşımlı hostingde otomatik yedekleme yazısındaki kaynak sınırlarına bakın; WordPress tarafında eklentiyle yürütmek isterseniz UpdraftPlus nasıl kullanılır yazısı aynı işi panel üzerinden yapmayı anlatıyor.

Sıkça Sorulan Sorular#

Google Drive masaüstü uygulamasını sunucuya kurabilir miyim#

Hayır, kuramazsınız. Google Drive masaüstü istemcisi yalnızca Windows ve macOS için yayımlanır ve grafik arayüz gerektirir; sunucularda çalışan Linux dağıtımlarında ne resmi bir sürümü vardır ne de arayüzsüz çalışacak bir kipi. Sunucudan Drive'a yükleme yapmanın desteklenen yolu komut satırı istemcileridir; bunların içinde en yaygını ve en çok sağlayıcıyı destekleyeni rclone'dur. Kurulumu tek satır, yapılandırması bir defalıktır.

Yetkilendirme jetonu ne kadar süre geçerli kalır#

Yenileme jetonu normal şartlarda süresiz geçerlidir ve rclone erişim jetonunu arka planda kendisi tazeler. Ancak üç durumda geçersizleşir: Google hesabının parolasını değiştirirseniz, hesap güvenlik ayarlarından uygulamanın erişimini kaldırırsanız veya uygulamanız Google Cloud Console'da "test" aşamasında bırakılmışsa. Sonuncusu en çok tökezletendir; yayımlanmamış test uygulamalarının jetonları yedi gün sonra düşer ve yedek sessizce durur. Kendi OAuth istemcinizi oluşturduysanız uygulamayı "üretim" durumuna geçirmeyi unutmayın.

Yüklenen yedekler Drive'ın kotasından düşer mi#

Evet, düşer ve çöp kutusundakiler de düşer. Bu, otomatik yedeklemede en sık karşılaşılan sürprizdir: eski dosyaları silen bir betik yazarsınız ama rclone delete dosyaları çöp kutusuna taşıdığı için kullanılan alan hiç azalmaz, birkaç ay sonra kota dolar ve yüklemeler storageQuotaExceeded hatasıyla durur. Çözüm, silme adımından sonra rclone cleanup gdrive: komutunu çalıştırmaktır. Kurulumdan bir ay sonra hesabın kullanılan alan rakamını kontrol edip beklediğiniz seviyede olduğunu doğrulayın.

Yedeklerimi Drive'a yüklerken şifrelemeli miyim#

Şifrelemelisiniz, özellikle yedek içinde veritabanı dökümü varsa. Veritabanı dökümü müşteri e-postalarını, sipariş adreslerini ve karma hâlindeki parolaları içerir; bu dosyanın üçüncü taraf bir depolama hesabında düz hâlde durması hem güvenlik hem KVKK açısından risklidir. rclone'un crypt katmanı, dosyaları sunucudan çıkmadan önce şifreler ve dosya adlarını da okunamaz hâle getirir; hedef sağlayıcı içeriği göremez. Tek şart şifreleme parolasını sunucu dışında güvenli bir yerde saklamaktır, çünkü kaybedilen parola yedeği kurtarılamaz hâle getirir.

Yedeğin gerçekten yüklendiğini nasıl kontrol ederim#

En güvenilir yöntem, uzak depodaki dosyayı listeleyip boyutunu yereldeki ile karşılaştırmaktır: rclone ls gdrive:sunucu-yedek komutu dosya adlarını ve bayt cinsinden boyutlarını verir. Bunu betiğe ekleyip beklenen boyutun altındaki dosyaları uyarı olarak işaretleyebilirsiniz. Ayda bir kez de arşivi indirip tar -tzf ile içeriğini listeleyin; arşiv bozuksa bu komut hata verir. Bir de betiğin çıkış kodunu izleyin — sessiz başarısızlık, yedeklemede en sık görülen ve en pahalıya patlayan arızadır.

Paylaşımlı hosting hesabımdan da Drive'a yedek gönderebilir miyim#

Çoğu paylaşımlı hosting hesabında bu mümkündür ama kısıtlıdır. rclone tek bir çalıştırılabilir dosya olduğu için ana dizininize indirip cron ile çalıştırabilirsiniz; ancak paylaşımlı ortamlarda çalışma süresi, bellek ve eşzamanlı süreç sınırları vardır ve büyük bir arşivin yüklenmesi bu sınırlara takılıp yarıda kesilebilir. SSH erişiminiz yoksa bu yol tamamen kapalıdır; o durumda panelin kendi uzak yedek desteğini ya da WordPress kullanıyorsanız bir yedekleme eklentisinin bulut hedefini kullanmak daha pratiktir. Yedek boyutu birkaç gigabaytı aşıyorsa kendi kaynaklarınızın olduğu bir sanal sunucuya geçmeyi değerlendirin.

rclone sync yerine copy kullanmam neden önemli#

Çünkü sync hedefi kaynağın birebir aynısı yapar ve kaynakta bulunmayan her şeyi hedeften siler. Yedek betikleri genellikle yerel arşivleri birkaç gün sonra temizler; ardından sync çalıştırılırsa bulut tarafındaki tüm geçmiş kopyalar da silinir ve elinizde yalnızca son yedek kalır. Bu, tek bir komut farkıyla aylarca birikmiş yedek geçmişini kaybetmek demektir. Yükleme adımında daima copy kullanın, eski kopyaların temizliğini ise --min-age parametreli ayrı bir delete adımıyla, bilinçli olarak yapın.

Kapanış#

Sunucudaki yedeği buluta taşımak, yedeklemeyi "var" durumundan "işe yarar" durumuna geçiren adımdır. Kurulumun teknik kısmı aslında kısadır: rclone kur, drive.file kapsamıyla yetkilendir, bir betik yaz, cron'a bağla. Uzun ömürlü olmasını sağlayan şey ise çevresindeki disiplindir — yapılandırma dosyasını 600 izinle kilitlemek, copy ile sync farkını bilmek, silme sonrası cleanup çalıştırmak, arşivi şifrelemek ve en önemlisi işin sonucunu izlemek. Yedekleme sistemlerinin büyük çoğunluğu bir gün çökmez; sessizce durur ve aylar sonra fark edilir.

Bu zinciri kendiniz kurup bakımını üstlenmek istemiyorsanız işi devretmek de bir seçenek: yedekleme hizmeti sayfasındaki paketler yedeğin alınmasını, sunucu dışına taşınmasını ve saklama süresinin yönetilmesini üstlenir. Kendi cron'unuzu, kendi rclone kurulumunuzu ve şifreleme anahtarınızı yönetmek istiyorsanız kök erişimi olan bir sanal sunucu bunun doğru zeminidir; sunucunun güncellemeleri, izleme kurulumu ve yedek kontrolleri gibi işleri de bırakmak isterseniz sunucu yönetimi hizmeti bu bakımı düzenli olarak yürütür.