Veritabanı Yedekleme ve Geri Yükleme: mysqldump ve pg_dump Rehberi

Veritabanı yedekleme nedir ve mysqldump ile nasıl yapılır?

Veritabanı yedekleme, tabloların ve içindeki verilerin başka bir dosyaya kopyalanmasıdır. mysqldump bu işi MySQL ve MariaDB için SQL komutlarından oluşan bir metin dosyasına dönüştürür. PostgreSQL'de karşılığı pg_dump aracıdır. Bu dosyayı sonradan çalıştırırsanız veritabanını yeniden kurarsınız.

Bu veritabanı yedekleme rehberi, kendi VPS ya da cPanel hesabını yöneten web sitesi sahipleri ve yazılımcılar için hazırlandı. Komutları adım adım uygulayabilirsiniz. Ancak sitenizin tamamını nasıl koruyacağınız ayrı bir konudur. Dosya yedeği, saklama süresi ve 3-2-1 mantığı için web sitesi yedekleme stratejisi yazımıza bakın. Burada yalnızca veritabanı yedekleme kısmını anlatıyoruz.

Biz dijital pazarlama ve web ekibiyiz, hosting firması değiliz. Bu yüzden anlatım resmi dokümanlara dayanır. Komutların ayrıntısını MySQL ve PostgreSQL dokümanlarında doğruladık. Sürüm numarası vermiyoruz, çünkü seçenekler zamanla değişir. Kendi sürümünüzün dokümanını açıp kontrol etmeniz gerekir.

Mantıksal yedek ile fiziksel yedek arasındaki fark nedir?

Mantıksal yedek, veriyi SQL ifadeleri olarak yazar. Fiziksel yedek ise veritabanı motorunun disk üzerindeki dosyalarını kopyalar. mysqldump ve pg_dump mantıksal yedek üretir. Bu yöntem okunabilir, taşınabilir ve küçük ile orta ölçekli siteler için yeterlidir.

Fiziksel yedek genellikle çok büyük veritabanlarında daha hızlı geri döner. Buna karşılık motor sürümüne ve yapılandırmaya sıkı bağlıdır. Dolayısıyla çoğu web sitesi için mantıksal yedek ilk adım olarak mantıklıdır. Aşağıdaki tablo farkı özetler.

Yedeğe başlamadan önce neleri kontrol etmelisiniz?

Önce ne yedekleyeceğinizi netleştirin. Hangi veritabanı, hangi motor ve hangi kullanıcı sorularının cevabı komutu belirler. Ayrıca yedek dosyasını nereye yazacağınızı ve diskte yeterli yer olup olmadığını bilmeniz gerekir.

• Motoru öğrenin: MySQL, MariaDB ya da PostgreSQL.
• Tabloların motorunu kontrol edin: InnoDB mi, MyISAM mı.
• Yalnızca yedek için gereken en düşük yetkilere sahip ayrı bir kullanıcı oluşturun.
• Yedek dizininde boş alan olduğundan emin olun.
• Yedeği geri yükleyeceğiniz bir test ortamı hazırlayın.

Yedek kullanıcısı için güçlü bir parola gerekir. Şifre oluşturucu aracımızı kullanabilirsiniz. Parolayı bir parola yöneticisine kaydedin, komutlara yazmayın.

MariaDB kullanıyorsanız araç artık mariadb-dump adıyla da gelir. MariaDB dokümanına göre eski mysqldump adı bir sembolik bağ olarak durur, ancak 11.0 sürümünden itibaren kullanımdan kaldırılmaktadır. Bu yüzden sunucunuzda hangi adın bulunduğuna bakın.

Yedek kullanıcısına hangi yetkileri vermelisiniz?

MySQL dokümanı gereken yetkileri açıkça sıralar. Yedeklenen tablolar için SELECT, görünümler için SHOW VIEW, tetikleyiciler için TRIGGER yetkisi şarttır. Ayrıca --single-transaction kullanmıyorsanız LOCK TABLES gerekir. Böylece yönetici hesabı yerine dar yetkili bir hesapla çalışabilirsiniz.

İki ayrıntıya dikkat edin. Doküman, --no-tablespaces seçeneğini kullanmıyorsanız PROCESS yetkisini de ister. GTID kullanılan sunucularda --single-transaction ile birlikte RELOAD ya da FLUSH_TABLES yetkisi gerekebilir. Saklı yordam ve olay yedeği için ek yetki istenebilir; kendi sürümünüzün dokümanına bakın.

GRANT SELECT, SHOW VIEW, TRIGGER ON ornek_db.* TO 'yedek_kullanici'@'localhost';

Bu komutu yetkili bir hesapla çalıştırırsınız. Örnekteki kullanıcı ve veritabanı adları kurgudur. Yönetici parolasını yedek betiğine koymamak, olası bir sızıntının etkisini küçültür. Ayrıca yetkiyi yalnızca gerekli veritabanıyla sınırlamak da iyi bir alışkanlıktır.

mysqldump ile tek bir veritabanının yedeği nasıl alınır?

En basit biçim, veritabanı adını verip çıktıyı bir dosyaya yönlendirmektir. Aşağıdaki örnek ornek_db adlı veritabanını yedekler. Parola için bir sonraki bölümde anlatacağımız seçenek dosyasını kullanıyoruz.

mysqldump --defaults-extra-file=/home/kullanici/.yedek.cnf \
  --single-transaction --routines --triggers --events \
  ornek_db > ornek_db.sql

Dikkat edin: komutta --databases seçeneğini bilerek kullanmadık. MySQL dokümanına göre bu seçenek çıktıya CREATE DATABASE ifadeleri ekler. Böyle bir dosyayı test için yüklerseniz, aynı adlı canlı veritabanının üzerine yazabilirsiniz. Veritabanı adını komutta yazmak, geri yüklerken hedefi sizin seçmenizi sağlar.

Tüm veritabanlarını tek dosyaya almak için --all-databases seçeneği vardır. Ancak sitelerinizi ayrı dosyalara yedeklemek, tek bir siteyi geri yüklemeyi kolaylaştırır. Bu nedenle her veritabanı için ayrı komut çalıştırmanızı öneririz.

--single-transaction ne işe yarar ve ne zaman yetmez?

MySQL dokümanına göre --single-transaction, veriyi dökmeden önce bir BEGIN ifadesi gönderir. Böylece InnoDB tablolarında, siteyi kilitlemeden tutarlı bir görüntü alırsınız. Yani yedek sürerken siparişler ya da yorumlar yazılmaya devam edebilir, ama dosya tek bir andaki durumu yansıtır.

Bu seçeneğin sınırları var. Doküman iki uyarı yapar. Birincisi, yedek sürerken tablo yapısını değiştiren ifadeler tutarlılığı bozabilir. Örneğin ALTER TABLE ya da TRUNCATE TABLE çalıştırmayın. İkincisi, MyISAM gibi işlem desteklemeyen tablolarda bu seçenek tutarlılık sağlamaz.

Karışık motorlu bir veritabanınız varsa doküman --lock-tables seçeneğini önerir. Bu durumda yedek sırasında yazmalar beklemeye girer. Dolayısıyla yoğun saatlerden kaçının ve mümkünse tabloları InnoDB'ye taşımayı bir uzmanla konuşun.

Yalnızca belirli tabloları ya da tablo yapısını nasıl yedeklersiniz?

Bazen tüm veritabanına ihtiyacınız olmaz. mysqldump, veritabanı adından sonra tablo adlarını yazmanıza izin verir. Böylece yalnızca o tabloları dökersiniz. Örneğin bir geliştirme kopyası için yalnızca ürün ve kategori tablolarını almak isteyebilirsiniz.

mysqldump --defaults-extra-file=/home/kullanici/.yedek.cnf   --single-transaction ornek_db urunler kategoriler > urunler.sql

Bunun tersi için --ignore-table seçeneği vardır. Büyük ve gereksiz tabloları, örneğin günlük kayıtlarını, dışarıda bırakırsınız. Ayrıca --no-data seçeneği yalnızca tablo yapısını yazar. Bu seçenek, boş bir test ortamı kurarken işe yarar.

Ancak parçalı yedeği tek başına güvenli bir yedek saymayın. Tablolar arasındaki ilişkiler yarım kalabilir. Bu nedenle düzenli yedeğiniz her zaman tam veritabanı olsun, parçalı dökümleri yalnızca özel işler için kullanın.

Saklı yordamlar, tetikleyiciler ve olaylar yedeğe girer mi?

Hepsini açıkça istemek en güvenli yoldur. MySQL dokümanına göre saklı yordamlar için --routines, olaylar için --events seçeneği gerekir; varsayılan olarak yedeğe girmezler. Tetikleyiciler için --triggers seçeneği vardır. Biz örneklerde üçünü de yazıyoruz, çünkü varsayılana güvenmek geri yükleme günü sürpriz çıkarabilir.

Bu nesneleri kullanmıyorsanız komuta eklemek zarar vermez. Kullanıyorsanız, eksik bir yordam yüzünden sitenin bir bölümü çalışmaz. WordPress gibi hazır sistemlerde genellikle bu nesneler az olur, ama özel yazılımlarda sık görülür.

Özel yazılımda veritabanı nesnelerini kod deposunda da tutmak iyi bir alışkanlıktır. Böylece yedek bozulsa bile yapıyı yeniden kurabilirsiniz. Bu konuda ekibinizle çalışmak istiyorsanız özel yazılım geliştirme hizmetimize göz atabilirsiniz.

Parolayı komut satırına yazmadan yedek almak mümkün mü?

Mümkündür ve gereklidir. MySQL dokümanı, parolayı komut satırında yazmanın güvenli olmadığını açıkça söyler; seçenek dosyası kullanmayı önerir. Komut satırındaki parola, süreç listesinde ve kabuk geçmişinde başkalarının gözüne çarpabilir.

Önce bir seçenek dosyası oluşturun. Dosya biçimi basittir: köşeli parantezle bir grup adı yazarsınız, altına user ve password satırlarını eklersiniz. Aşağıdaki değerler tamamen örnektir.

[client]
user=yedek_kullanici
password=BURAYA_PAROLA_YAZIN

Ardından dosyayı yalnızca sizin okuyabileceğiniz hale getirin. Doküman bu konuda açık: dosyaya yalnızca sahibi erişmeli. Komut şu şekilde olur:

chmod 600 /home/kullanici/.yedek.cnf

Son olarak --defaults-extra-file seçeneğini kullanın. Doküman, bu seçeneğin komut satırındaki ilk seçenek olması gerektiğini belirtir. Bu yüzden örneklerimizde hep en başa yazdık.

pg_dump ile PostgreSQL yedeği nasıl alınır?

PostgreSQL dokümanına göre pg_dump, veritabanı kullanılırken bile tutarlı bir dışa aktarma yapar ve diğer kullanıcıların okuma ya da yazmasını engellemez. Bu nedenle ayrı bir kilit seçeneği aramanıza gerek yok. En yaygın biçim, özel (custom) arşiv biçimidir.

pg_dump --format=custom --file=ornek_db.dump \
  --host=localhost --username=yedek_kullanici ornek_db

Parola için PGPASSWORD ortam değişkeni ya da .pgpass dosyası kullanılabilir. Dokümana göre iki yol da desteklenir. Biz dosyayı tercih ederiz, çünkü ortam değişkeni de süreç bilgisinde görünebilir. Dosya satırı şu biçimdedir: sunucu:port:veritabanı:kullanıcı:parola. Dosyanın izinlerini yine yalnızca sahibine açın.

Bir noktayı atlamayın: pg_dump rolleri ve kullanıcıları yedeğe katmaz. Doküman bunun için pg_dumpall komutunu --globals-only seçeneğiyle kullanmanızı söyler. Sunucuyu sıfırdan kuracaksanız bu dosyayı da saklayın.

pg_dump biçimlerinden hangisini seçmelisiniz?

Seçim, geri yükleme biçiminizi belirler. Düz metin biçimi psql ile, diğerleri pg_restore ile yüklenir. Ayrıca yalnızca dizin biçimi paralel yedeği destekler. Aşağıdaki tablo PostgreSQL dokümanındaki bilgileri toplar.

Çoğu site için özel arşiv biçimi yeterlidir. Çok büyük veritabanında dizin biçimi ve --jobs seçeneği süreyi kısaltabilir. Ancak paralel çalışma sunucuya ek bağlantı açar; dokümana göre iş sayısından bir fazla bağlantı kullanılır. Paylaşımlı ortamda bunu sağlayıcınıza sorun.

Yedek dosyasını sıkıştırmak nasıl yapılır?

mysqldump çıktısını metin olarak yazar. Metin dosyaları iyi sıkışır, bu yüzden çıktıyı gzip'e borulamak disk alanından tasarruf ettirir. Böylece dosyayı sunucu dışına taşırken de daha az veri gönderirsiniz.

mysqldump --defaults-extra-file=/home/kullanici/.yedek.cnf \
  --single-transaction --routines --triggers --events ornek_db \
  | gzip > ornek_db.sql.gz

Boru kullanırken küçük bir tuzak var. mysqldump hata verirse bile gzip başarıyla biter ve boş görünen ama geçerli bir sıkıştırılmış dosya oluşur. Bu nedenle betiklerde bash'in pipefail seçeneğini açın. Böylece borudaki herhangi bir komut başarısız olursa betik hata koduyla çıkar.

PostgreSQL'de özel ve dizin biçimleri zaten sıkıştırır. Doküman -Z seçeneğiyle yöntem olarak gzip, lz4 ya da zstd seçebileceğinizi belirtir. Düz metin biçiminde ise MySQL'deki gibi gzip'e borulayabilirsiniz.

Veritabanı yedekleme sunucuyu yavaşlatır mı, yükü nasıl azaltırsınız?

Yedek sırasında veritabanı tabloları baştan sona okunur. Bu okuma işlemci ve disk kullanır, dolayısıyla yoğun saatte alınan yedek siteyi yavaşlatabilir. İlk önlem, yedeği ziyaretçinin az olduğu saate koymaktır. Trafik grafiğinize bakarak en sakin saati seçin.

MySQL dokümanına göre --opt varsayılan olarak açıktır ve --quick seçeneğini de açar. Bu seçenek tabloyu satır satır okur, böylece büyük tabloyu belleğe doldurmaz. Yani mysqldump zaten bellek dostu çalışır. Yine de işlemin önceliğini düşürmek için nice ve ionice komutlarını kullanabilirsiniz.

nice -n 19 ionice -c3 /home/kullanici/yedek-db.sh

Bu satır, betiği en düşük işlemci önceliği ve boşta disk sınıfıyla çalıştırır. Paylaşımlı hostingde bu komutlar çalışmayabilir ya da kota sizi yine sınırlayabilir. Yedek süresi sürekli uzuyorsa bu bir uyarıdır. O zaman veritabanı boyutunu inceleyin ve sağlayıcınızla bir kopya üzerinden yedek alma seçeneğini konuşun.

Türkçe karakterler yedekte bozulur mu?

Doğru ayarlarla bozulmaz. Sorun genellikle yedeği alan ve yükleyen istemcinin farklı karakter kümesi kullanmasından çıkar. Sonuçta ğ, ş, ı gibi harfler soru işaretine ya da anlamsız simgelere dönüşebilir. Bu yüzden önce veritabanınızın karakter kümesini öğrenin.

Bunun için SHOW CREATE DATABASE komutunu kullanabilirsiniz. Çıktıda veritabanının karakter kümesi görünür. mysqldump için --default-character-set seçeneği vardır; veritabanınız utf8mb4 ise yedek ve yükleme komutlarında aynı değeri açıkça yazmak güvenlidir. Ardından test yüklemesinde Türkçe karakter içeren birkaç satırı gözle kontrol edin.

PostgreSQL'de benzer bir risk daha azdır, çünkü arşiv veritabanının kodlamasını taşır. Yine de farklı kodlamalı bir veritabanına yüklüyorsanız dikkatli olun. Özellikle eski sitelerde, yıllar içinde karışmış kodlamalar yedeği taşırken ortaya çıkar.

Cron ile veritabanı yedekleme nasıl otomatikleşir?

Elle alınan yedek unutulur, bu yüzden veritabanı yedekleme işini zamanlayın. Komutu önce bir betiğe koyun, sonra cron ile çalıştırın. Aşağıdaki betik örnektir; dizin yollarını ve veritabanı adını kendi ortamınıza göre değiştirin.

#!/bin/bash
set -euo pipefail
DIZIN=/home/kullanici/yedekler/db
TARIH=$(date +%Y%m%d-%H%M)
mkdir -p "$DIZIN"
mysqldump --defaults-extra-file=/home/kullanici/.yedek.cnf \
  --single-transaction --routines --triggers --events ornek_db \
  | gzip > "$DIZIN/ornek_db-$TARIH.sql.gz"
find "$DIZIN" -name 'ornek_db-*.sql.gz' -mtime +14 -delete

Betiği çalıştırılabilir yapın ve crontab -e ile şu satırı ekleyin. Satır her gece 03:30'da çalışır ve çıktıyı bir günlüğe yazar.

30 3 * * * /home/kullanici/yedek-db.sh >> /home/kullanici/yedekler/yedek.log 2>&1

Tarih biçimindeki yüzde işaretini betiğin içinde tuttuk. Crontab satırlarında yüzde işareti özel anlam taşır ve kaçış gerektirir. Bu yüzden komutu ayrı bir dosyaya almak daha sağlıklıdır.

Eski yedekleri silmek ve saklama süresini belirlemek nasıl yapılır?

Sınırsız yedek tutarsanız disk dolar ve yedekleme betiği bir gün başarısız olur. Betikteki find satırı bunu önler: 14 günden eski dosyaları siler. Ancak sayıyı kendi ihtiyacınıza göre seçmelisiniz.

Saklama süresini üç soru belirler. Bir hatayı ne kadar geç fark edersiniz? Sipariş ya da kullanıcı verisi için yasal saklama yükümlülüğünüz var mı? Diskte ne kadar yeriniz var? Örneğin bir hata üç hafta sonra fark ediliyorsa, iki haftalık saklama yetmez.

• Günlük yedekleri kısa süre, haftalık yedekleri daha uzun saklayın.
• Silme komutunu önce -delete olmadan çalıştırıp listeyi kontrol edin.
• Silmeden önce yeni yedeğin başarıyla oluştuğunu doğrulayın.

Bu başlıkta sayısal bir kural vermiyoruz. Kural, işinizin veri değişim hızına ve hukuki yükümlülüklerinize bağlıdır. Genel kademeli saklama mantığı için strateji yazımıza bakabilirsiniz.

MySQL yedeği nasıl geri yüklenir?

MySQL dokümanına göre bir dökümü geri yüklemek için dosyayı mysql istemcisine yönlendirirsiniz. Hedef veritabanı önceden var olmalıdır. Önce veritabanını oluşturun, ardından dosyayı yükleyin.

mysql --defaults-extra-file=/home/kullanici/.yedek.cnf \
  -e "CREATE DATABASE test_geri_yukle"
gunzip < ornek_db.sql.gz | mysql \
  --defaults-extra-file=/home/kullanici/.yedek.cnf test_geri_yukle

Yedek kullanıcınız yalnızca okuma için tasarlandıysa, yükleme için yazma yetkisi olan başka bir hesap kullanın. Canlı veritabanının üzerine yüklemeden önce mutlaka güncel bir yedek alın. Çünkü yanlış hedefe yapılan bir geri yükleme veriyi geri dönüşsüz biçimde değiştirebilir.

Büyük dosyalarda işlem uzun sürer. Bu süre boyunca site yarım veriyle çalışabilir. Bu nedenle canlı geri yüklemeyi bakım penceresinde yapın ve ziyaretçilere bakım sayfası gösterin.

PostgreSQL yedeği nasıl geri yüklenir?

Biçime göre araç değişir. Düz metin dosyalarını psql, özel ve dizin arşivlerini pg_restore yükler. Örnekte önce boş bir veritabanı açıyor, sonra arşivi bu veritabanına yüklüyoruz.

createdb test_geri_yukle
pg_restore --dbname=test_geri_yukle --no-owner --exit-on-error ornek_db.dump

PostgreSQL dokümanına göre --exit-on-error ilk hatada durur, --no-owner ise nesne sahipliğini geri yüklemez. Ayrıca --list seçeneği arşivin içindekileri listeler; yüklemeden önce dosyanın okunabildiğini görmek için işe yarar.

Düz metin dosyası için şu biçimi kullanın. ON_ERROR_STOP değişkeni, ilk hatada psql'in durmasını sağlar.

gunzip -c ornek_db.sql.gz | psql --set ON_ERROR_STOP=on \
  --dbname=test_geri_yukle

Dokümana göre --single-transaction seçeneği --jobs ile birlikte kullanılamaz. Bu yüzden hız mı, tek işlemde bütünlük mü istediğinize karar verin.

Yedeğin gerçekten çalıştığını nasıl doğrularsınız?

Geri yüklenmemiş yedek, çalıştığı kanıtlanmamış bir dosyadır. Doğrulama üç basamaktan oluşur. Önce dosyanın bozuk olmadığını kontrol edersiniz. Ardından bir test ortamına yüklersiniz. Son olarak verinin beklenen kadar olduğunu sayarsınız.

1. Sıkıştırılmış dosyayı gzip -t ile sınayın.
2. mysqldump çıktısının son satırlarında "Dump completed" ifadesini arayın.
3. PostgreSQL arşivinde pg_restore --list komutunu çalıştırın.
4. Test veritabanına yükleyin ve önemli tablolarda satır sayısını karşılaştırın.
5. Siteyi test kopyasına bağlayıp gerçek bir sipariş ya da yazı sayfasını açın.

Bu doğrulamayı ayda bir tekrarlamanızı öneririz. Çünkü yedek betiği sessizce bozulabilir: parola değişir, disk dolar, yetki kaldırılır. Cron çalışsa bile dosya boş olabilir.

Test için canlı sunucudan ayrı bir ortam kullanmak en güvenlisidir. Yerelde Docker ile geçici bir veritabanı açmak iyi bir yöntemdir. Docker konusunda Docker nedir rehberimize bakabilirsiniz.

Yedeği yeni bir hosting ya da sunucuya taşımak için nasıl kullanırsınız?

Mantıksal yedeğin en büyük avantajı taşınabilirliktir. Yeni sunucuda boş bir veritabanı ve kullanıcı oluşturun, ardından dosyayı yükleyin. Dosya SQL metni olduğu için motor sürümleri arasında genellikle sorunsuz geçer. Yine de büyük sürüm atlamalarında dokümandaki uyumluluk notlarını okuyun.

Taşıma sırasında sıra önemlidir. Önce yeni ortamı hazırlayın ve test yüklemesi yapın. Sonra bakım penceresinde eski sitede yazmaları durdurun, güncel bir yedek alın ve yeni ortama yükleyin. Son olarak DNS kaydını yeni sunucuya çevirin. DNS değişikliğini DNS sorgulama aracımızla izleyebilirsiniz.

Eski sunucuyu hemen kapatmayın. DNS yayılımı sürerken bazı ziyaretçiler hâlâ eski adrese gider. Yeni sitenin sağlıklı çalıştığını birkaç gün gözlemleyin. Bu süreçte eski veritabanını salt okunur tutmak, iki yerde farklı veri oluşmasını önler.

Yedeği sunucu dışına nasıl alırsınız?

Yedek, veritabanıyla aynı diskte duruyorsa disk bozulduğunda ikisi birlikte gider. Bu yüzden dosyayı başka bir konuma kopyalayın. SSH erişiminiz varsa rsync basit ve güvenilir bir yoldur.

rsync -av -e ssh /home/kullanici/yedekler/db/ \
  yedek@yedek.example.com:/yedekler/ornek-site/

Kopyalama bittikten sonra dosyaların aynı olduğunu sağlama toplamıyla doğrulayın. sha256sum komutunu iki tarafta da çalıştırıp çıktıları karşılaştırın. Ayrıca yedek dosyasında müşteri verisi bulunur. Bu yüzden aktarımı şifreli kanaldan yapın ve hedefte erişimi kısıtlayın.

Daha hassas veri için dosyayı gönderilmeden önce şifreleyebilirsiniz. Örneğin gpg ile simetrik şifreleme kullanılabilir. Anahtarı ya da parolayı yedeğin yanında saklamayın. Şifreleme ve veri güvenliği çerçevesi için kurumsal web sitesinde veri güvenliği yazımıza göz atın.

Veritabanı yedekleme sırasında en sık yapılan hatalar nelerdir?

Hataların çoğu komutun kendisinden değil, çevresinden gelir. Aşağıdaki liste, yedek alırken en sık görülen tuzakları dokümanlara dayanarak özetler.

• Parolayı komut satırına yazmak. Seçenek dosyası ve izin kısıtı bunu çözer.
• --databases seçeneğini fark etmeden kullanıp test yüklemesinde canlı veriyi ezmek.
• Boru kullanırken pipefail'i açmamak ve boş yedek üretmek.
• Rolleri ve kullanıcıları yedeğe katmamak. PostgreSQL için pg_dumpall gerekir.
• Yedeği hiç geri yüklememek ve ilk denemeyi felaket anında yapmak.
• Yedeği yalnızca aynı sunucuda tutmak.

Bunların hepsi önlenebilir. Yedek betiğinizi bir kez kurup, aylık doğrulamayı takvime yazmanız yeterlidir. Ayrıca güvenlik açıkları da veri kaybı yaratır; bu risk için OWASP Top 10 yazımızı okuyun.

Hangi durumda kendiniz yapmamalı, hosting sağlayıcınıza bırakmalısınız?

Her işi kendiniz yapmak zorunda değilsiniz. Kabuk erişiminiz yoksa ya da paylaşımlı hostingde komut çalıştıramıyorsanız, panelin yedek araçlarını ve sağlayıcının destek ekibini kullanın. Yanlış bir geri yükleme veriyi bozabilir.

• Veritabanı çok büyükse ve yedek süresi siteyi yavaşlatıyorsa.
• Belirli bir ana kadar geri dönmek (anlık kurtarma) gerekiyorsa. Bu iş genellikle ikili günlükler ve uzman yönetimi ister.
• Çoğaltma (replikasyon) ya da küme kullanıyorsanız.
• Yasal saklama ve denetim yükümlülüğünüz varsa.
• Komutların ne yaptığından emin değilseniz.

Sağlayıcı seçerken yedek politikasını sorun. Hangi sıklıkta yedek alındığını, kaç gün saklandığını ve geri yükleme isteğinin ne kadar sürdüğünü yazılı öğrenin. Bu konuda hosting seçimi rehberimiz işinize yarar.

Veritabanı yedekleme için kısa kontrol listesi nasıl olmalı?

Aşağıdaki liste, bu yazıdaki adımları tek bakışta toplar. Yazdırıp sunucu notlarınıza ekleyebilirsiniz. Her maddeyi bir kez kurduktan sonra yalnızca doğrulamayı tekrarlarsınız.

1. Yalnızca gerekli yetkileri olan bir yedek kullanıcısı oluşturun.
2. Parolayı seçenek dosyasına koyun ve izinleri 600 yapın.
3. InnoDB için --single-transaction, ayrıca --routines, --triggers ve --events kullanın.
4. Çıktıyı sıkıştırın ve betikte pipefail'i açın.
5. Cron ile her gün çalıştırın, eski dosyaları temizleyin.
6. Yedeği sunucu dışına kopyalayın ve sağlama toplamını doğrulayın.
7. Ayda bir test veritabanına geri yükleyin.

Veritabanı yedekleme işini bir kez doğru kurarsanız, geri kalanı küçük bir bakım alışkanlığına dönüşür. SQL bilginizi geliştirmek isterseniz SQL öğrenme rehberimiz ve SQL sorgu senaryoları yazımız iyi bir sonraki adımdır.

Ekibimiz web sitesi ve e-ticaret projelerinde altyapı kararlarını hosting sağlayıcınızla birlikte planlamanıza yardımcı olabilir. Ayrıntı için web tasarım hizmetimize bakın. Yedek ve geri yükleme planınızı yazıya dökmek, bir kriz anında en büyük zaman kazancıdır.

Komut seçenekleri sürümle değişebilir. Bu yüzden her zaman kendi sürümünüzün dokümanına bakın. Bu yazıda dayandığımız resmi sayfalar şunlardır:

• MySQL mysqldump dokümanı.
• MySQL seçenek dosyaları dokümanı.
• PostgreSQL pg_dump dokümanı.
• PostgreSQL pg_restore dokümanı.
• MariaDB mariadb-dump dokümanı.

Doküman bağlantılarındaki sürüm yolu zamanla değişir. Güncel kararlı sürümün sayfasına gidip aynı başlığı arayın. Sonuç olarak, komutu çalıştırmadan önce seçeneğin sizin sürümünüzde var olduğunu kontrol edin.