SSH Üzerinden SQL Dosyası Yükleme Rehberi (2026)

Son Güncelleme: Eylül 2026

SSH üzerinden SQL dosyası yüklemek, özellikle büyük veritabanı yedeklerini geri yüklerken tarayıcı tabanlı araçlara güçlü bir alternatiftir. Bu rehberde cPanel kullanılan bir sunucuda MySQL veya MariaDB veritabanına SQL içe aktarma işlemini, güvenli parola kullanımını, sık karşılaşılan hataları ve aktarım sonrası kontrolleri adım adım ele alıyoruz.

İçindekiler

• Neden SSH ile SQL yüklenir?
• Başlamadan önce hazırlık
• SQL dosyasını yükleme
• Parolayı güvenli kullanma
• Büyük ve sıkıştırılmış dosyalar
• Yöntemlerin karşılaştırılması
• Hatalar ve çözüm yolları
• Doğrulama ve güvenlik
• Sıkça Sorulan Sorular
• Sonuç

Neden SSH ile SQL yüklenir?

Eski makaledeki temel yaklaşım hâlâ geçerlidir: SQL dökümünü (veritabanı yedeğini) sunucuya aktarıp komut satırı istemcisine yönlendirmek, çoğu durumda phpMyAdmin üzerinden yüklemekten daha elverişlidir. Ancak eski örnekte parolanın doğrudan komuta yazılması güvenli değildir. Bu rehber, aynı işlemi parola istemiyle ve gerekli kontrollerle gerçekleştirir.

phpMyAdmin kullanışlı bir grafik arayüzdür; küçük dosyalar ve tablo incelemeleri için iyi bir seçim olabilir. Büyük dosyalarda ise PHP yükleme boyutu, istek boyutu, bellek ve çalışma süresi ayarları sınır oluşturabilir. SSH yöntemi tarayıcıya dosya yükleme aşamasını ortadan kaldırır; buna karşılık sunucu disk alanı, veritabanı izinleri ve MySQL kaynak sınırları yine geçerlidir. Dolayısıyla SSH, her hatayı kendiliğinden çözen bir hızlandırma aracı değildir. phpMyAdmin'in ilgili sınırlar hakkındaki açıklamasına resmî SSS sayfasından ulaşabilirsiniz. (docs.phpmyadmin.net)

Bir WordPress taşımasında, e-ticaret sitesinin yedeğini geri yüklerken veya test ortamına üretim verisinin izin verilen bir kopyasını aktarırken bu yöntem işe yarar. Özellikle aktarımın çıktısını kaydetmek, bağlantı sorunlarını ayırt etmek ve dosyayı sıkıştırılmış biçimde işlemek isteyen sistem yöneticileri için komut satırı daha fazla denetim sunar. Üretim verisi kişisel bilgi içeriyorsa test kopyasını oluşturmadan önce maskeleme ve erişim yetkilerini ayrıca planlayın.

Başlamadan önce hazırlık

SSH ve veritabanı erişimini doğrulayın

Sunucuya kabuk (shell) erişiminiz, okunabilir bir SQL dosyanız ve hedef veritabanına yeterli yetkisi olan bir veritabanı kullanıcınız bulunmalıdır. cPanel'deki tarayıcı içi Terminal yalnızca hesabın kabuk erişimi varsa ve sağlayıcı ilgili özelliği etkinleştirmişse görünür; her hosting paketinde otomatik olarak sunulmaz. Bu koşulları cPanel Terminal belgelerinden kontrol edebilirsiniz. SSH izniniz yoksa sağlayıcınızdan erişim koşullarını öğrenin veya mevcut panel araçlarını kullanın. (docs.cpanel.net)

cPanel üzerinden veritabanını ve kullanıcıyı oluşturun; kullanıcıyı hedef veritabanına ekleyip içe aktarılacak nesnelerin gerektirdiği yetkileri verin. cPanel ortamlarında görünen veritabanı ve kullanıcı adları hesap öneki içerebilir. Bu nedenle yalnızca uygulama yapılandırmasında gördüğünüz kısa ada güvenmeyin; panelde yazan tam veritabanı adını ve tam kullanıcı adını kullanın. cPanel veritabanı belgeleri kullanıcı oluşturma ve önek davranışını açıklar. (docs.cpanel.net)

Yedek, dosya konumu ve uyumluluk

Mevcut verilerin üzerine yazabilecek bir aktarım yapmadan önce bağımsız, geri yüklenebilir bir yedek alın ve mümkünse ayrı bir test veritabanında deneme yapın. Dosyanın gerçekten SQL komutları içerdiğini, güvenilir bir kaynaktan geldiğini ve hedef motorla uyumlu olduğunu doğrulayın. Başka bir MySQL veya MariaDB sürümünden alınmış dökümlerde karakter kümesi, sıralama düzeni, saklı yordamlar ya da desteklenmeyen SQL ifadeleri sorun yaratabilir. Bir veritabanından diğerine geçerken salt dosya uzantısının .sql olması uyumluluk garantisi değildir.

Yedeği mümkünse web kök dizininin dışında, yalnızca hesabınızın erişebildiği bir konuma koyun. Örneğin aşağıdaki komutlar dosyanın mevcut dizinde bulunup bulunmadığını ve boş olup olmadığını anlamaya yardımcı olur. Örnek dosya yolunu kendi hesabınıza göre değiştirin:

pwd
ls -lh /home/hesap/yedekler/site.sql
file /home/hesap/yedekler/site.sql
df -h /home/hesap

Dosya henüz sunucuda değilse sağlayıcının izin verdiği güvenli aktarım yöntemleriyle, örneğin SFTP (SSH Dosya Aktarım Protokolü) kullanarak yükleyin. Dosyayı herkese açık public_html altında tutmayın: SQL dökümleri kullanıcı bilgileri, uygulama ayarları veya başka hassas kayıtlar içerebilir. Aktarım öncesinde hem yüklenen dosya hem de işlem sırasında oluşabilecek günlükler için yeterli alan bulunduğunu kontrol edin.

SQL dosyasını SSH üzerinden yükleme

Örneklerde hesap_db hedef veritabanı, hesap_user ise o veritabanında yetkili kullanıcıdır. Kendi cPanel hesabınızdaki tam adlarla değiştirin. Önce sunucuda istemcinin kurulu olduğunu ve sürümünü görüntüleyin:

mysql --version

MySQL istemcisi mevcutsa standart içe aktarma komutu şöyledir:

mysql --user=hesap_user --password hesap_db < /home/hesap/yedekler/site.sql

--password seçeneğine değer eklenmediği için istemci parolayı etkileşimli olarak ister. Kabuktaki < işareti SQL dosyasının içeriğini istemcinin standart girdisine yönlendirir. Burada hesap_db varsayılan hedef veritabanıdır; dökümün içindeki USE gibi ifadeler farklı bir veritabanı seçiyorsa dosyanın gerçek hedefi değişebilir. Çalıştırmadan önce dökümün kapsamını inceleyin. MySQL'in yedek geri yükleme belgeleri hem bu yöntemi hem de istemci içinden source kullanımını açıklar. (dev.mysql.com)

Sunucunuz MariaDB kullanıyorsa uygun istemci çoğunlukla mariadb adını taşır. Yüklü istemciye göre aşağıdaki alternatifi seçebilirsiniz:

mariadb --user=hesap_user --password hesap_db < /home/hesap/yedekler/site.sql

MariaDB belgeleri SQL betiklerinin standart girdiyle işlenmesini destekler. mysql adının MariaDB istemcisine işaret ettiği sistemler de olabilir; yalnızca komut adına bakarak sunucu motorunun MySQL olduğunu varsaymayın. Hangi istemcinin ve sunucunun kullanıldığını doğrulayarak ilerleyin. (mariadb.com)

Dosya belirli bir veritabanını oluşturup seçen tam bir dökümse, hedef adı argümanına ihtiyaç duyulmayabilir. Buna karşılık paylaşımlı hosting hesabında CREATE DATABASE yetkisi bulunmayabilir veya dökümdeki ad cPanel'in oluşturduğu adla uyuşmayabilir. Böyle bir durumda komutu körlemesine tekrarlamak yerine dosyayı inceleyin, hedef veritabanını panelde oluşturun ve dökümü güvenli bir test kopyasında hedefe uyarlayın.

Parolayı komutta göstermeden çalışın

Eski örnekteki gibi parolayı -p seçeneğinin hemen arkasına yazmak, kabuk geçmişinde veya işlem bilgilerinde sırrın açığa çıkmasına yol açabilir. Araya boşluk koyarak parola yazmak da çözüm değildir: bu durumda istemci parola sorar ve sonraki kelimeyi veritabanı adı olarak yorumlayabilir. İnteraktif kullanımda --password veya tek başına -p tercih edin. MySQL'in parola güvenliği rehberi, istemden parola girilmesini ve uygun izinlere sahip seçenek dosyalarını önerir. (dev.mysql.com)

Otomasyonda parola istemi kullanılamıyorsa erişimi kısıtlanmış bir istemci yapılandırma dosyası veya altyapınıza uygun bir gizli bilgi yönetimi çözümü değerlendirin. Böyle bir dosyanın düz metin parola içerdiğini unutmayın; dosyayı yedeklerde ve paylaşım süreçlerinde de koruyun. Komuta parola eklemek kadar, parolayı ortam değişkenlerine gelişigüzel yerleştirmek de risklidir. Örnekleri gerçek parolalarla birlikte destek taleplerine veya sohbet kayıtlarına yapıştırmayın.

Büyük ve sıkıştırılmış SQL dosyaları

Bir .sql.gz dosyası elinizdeyse önce diskte açmak yerine akış hâlinde istemciye verebilirsiniz. Bu işlem sıkıştırılmış dosyayı ikinci bir büyük SQL dosyası olarak diske yazma gereksinimini azaltır:

gzip -dc /home/hesap/yedekler/site.sql.gz | mysql --user=hesap_user --password hesap_db

Bu örnekte parola istemi bulunduğundan komutu etkileşimli terminalde çalıştırın. Daha sağlam bir işlem akışı için sıkıştırılmış dosyanın bütünlüğünü önce denetleyin; böylece bozuk bir arşiv nedeniyle yarıda kalan aktarım riskini azaltırsınız:

gzip -t /home/hesap/yedekler/site.sql.gz

Akış hattında yalnızca son komutun çıkış koduna bakmak, sıkıştırma aracındaki bir hatayı gözden kaçırabilir. Bash kabuğunda işlemi izliyorsanız aşağıdaki ayar, hattın herhangi bir bileşeni hata verdiğinde hattın hata kodu döndürmesine yardımcı olur:

set -o pipefail
gzip -dc /home/hesap/yedekler/site.sql.gz | mysql --user=hesap_user --password hesap_db

Aktarımın süresi sadece sıkıştırılmış dosyanın büyüklüğüne bağlı değildir; SQL ifadelerinin sayısı, indeksler, depolama hızı ve sunucu yükü de önemlidir. Çok büyük veri kümeleri için MySQL Shell'in paralel döküm ve yükleme araçları ayrı bir seçenektir; ancak bunlar sıradan bir .sql dosyasına uygulanan temel komutun doğrudan eşdeğeri değildir. Kullanacağınız döküm ve yükleme araçlarının aynı iş akışını desteklediğini önceden kontrol edin. MySQL yedekleme belgeleri bu alternatife de işaret eder. (dev.mysql.com)

2026 için içe aktarma yöntemleri karşılaştırması

Bu tabloda belirli bir dosya boyutu veya süre garantisi verilmemiştir; pratik sınırlar hosting paketine ve sunucu yapılandırmasına göre değişir. Paylaşımlı hosting hesabında kabuk erişimi yoksa phpMyAdmin hâlâ uygulanabilir seçenek olabilir. Daha fazla kaynak ve yönetim esnekliği gerektiren düzenli taşıma işlemlerinde sunucu türünü de iş yüküne göre seçmek gerekir.

Yaygın hatalar ve çözüm yolları

Erişim reddedildi veya veritabanı bulunamadı

Access denied hatasında parolayı, tam kullanıcı adını, kullanıcıya veritabanı yetkisi verilip verilmediğini ve bağlantının yapıldığı ana makineyi kontrol edin. Unknown database görürseniz hedefin panelde oluşturulduğundan ve cPanel önekiyle birlikte doğru yazıldığından emin olun. İşlemi yönetici hesabıyla denemek yerine gerekli yetkilere sahip uygulama veya taşıma kullanıcısını kullanın.

Dosya bulunamadı veya istemci çalışmıyor

No such file or directory mesajı, dosya yolunun hatalı veya dosyanın oturum açtığınız hesap tarafından okunamaz olduğunu gösterebilir. Command not found ise ilgili istemcinin kurulu olmadığını veya çalıştırılabilir dosyanın arama yolunda bulunmadığını düşündürür. mysql --version ve mariadb --version ile seçenekleri kontrol edin; yönetilmeyen bir sunucu değilse yazılım kurulumu için sağlayıcınızın prosedürlerini izleyin.

Paket sınırı, karakter ve SQL uyumsuzluğu

Packet too large hatası çoğunlukla tek bir büyük SQL ifadesi veya veri paketiyle ilişkilidir; döküm dosyasının toplam boyutuyla aynı şey değildir. MySQL belgelerine göre hem istemci hem sunucu tarafındaki max_allowed_packet sınırları önemlidir. Değişiklik yapmadan önce hatayı doğrulayın; paylaşımlı hizmette sunucu ayarlarını değiştirme yetkiniz olmayabilir. MySQL paket sınırı açıklamasını inceleyin. (dev.mysql.com)

Türkçe karakterler bozuluyorsa kaynak dosyanın kodlamasını, dökümdeki karakter kümesi ifadelerini, bağlantı karakter kümesini ve hedef tablo tanımlarını birlikte inceleyin. Her durumda karakter kümesini zorla değiştirmek doğru değildir; önce kaynak ve hedefin ne kullandığını saptayın. Unknown collation, sözdizimi veya nesne oluşturma hatalarında ise kaynak ve hedef veritabanı motorları ile sürümleri arasındaki farkları araştırın. Tekrarlanan bir içe aktarmada table already exists hatası alırsanız aynı verileri ikinci kez uygulamanın sonuçlarını değerlendirip temiz bir test veritabanında yeniden başlayın.

Aktarım sonucunu doğrulama ve veriyi koruma

Komutun sessizce tamamlanması tek başına uygulamanın doğru çalıştığını kanıtlamaz. Hemen ardından çıkış kodunu kontrol edin; araya başka komut girmeden çalıştırılması gerekir:

echo $?

0 başarıyla tamamlanan komutu gösterir; ancak bu, veri kümesinin iş açısından eksiksiz ve doğru olduğu anlamına gelmez. Sonrasında hedef veritabanına bağlanıp tabloları listeleyin ve önemli tablolar için uygulamanızın beklediği kayıtları kontrol edin:

mysql --user=hesap_user --password hesap_db

Bağlandıktan sonra istemci içinde aşağıdaki sorguyu çalıştırabilirsiniz. Bu bir SQL komutu olduğu için terminal komutundan ayrı olarak gösterilmiştir:

SHOW TABLES;

İstemci oturumundan ayrıldıktan sonra uygulamanın bağlantı ayarlarını ve gerçek işlevlerini de sınayın: bir WordPress sitesinde yönetim paneli ve örnek içerik; e-ticarette ise ürün ve sipariş kayıtları buna örnektir. Taşıma sırasında uygulamaya yazma işlemleri sürmüşse, aktarım anındaki yedeğin güncel kayıtları içerip içermediğini ayrıca değerlendirin. Kritik sistemlerde bakım penceresi ve geri dönüş planı hazırlamak, yalnızca komutun çalışmasına güvenmekten daha güvenlidir.

SQL dosyası, geçici kimlik bilgileri ve olası hata günlüklerini işlem sonunda gözden geçirin. Gerekmeyen sunucu kopyalarını güvenli saklama politikanıza göre kaldırın; tek yedek kopyasını doğrulamadan silmeyin. Uzaktan bir veritabanına bağlanıyorsanız bağlantı şifrelemesini ayrıca yapılandırıp doğrulayın: SSH ile sunucuya güvenli giriş yapmak, sunucu ile başka bir makinedeki veritabanı arasındaki bağlantının otomatik olarak şifrelendiği anlamına gelmez. Düzenli geri yükleme testleri için Corelux Yedekleme Hizmeti seçeneklerini değerlendirebilirsiniz.

Sıkça Sorulan Sorular

Sonuç

SSH ile SQL dosyası yükleme işleminin özü basittir: güvenilir dökümü doğru hedef veritabanına, uygun istemci ve yetkili kullanıcıyla yönlendirmek. Güvenli bir uygulama için bundan fazlası gerekir: parolayı komutta göstermeyin, yedeği web erişimine kapalı tutun, içe aktarma hatalarını izleyin ve sonucu uygulama düzeyinde doğrulayın. Böylece eski makaledeki tek komutluk yaklaşımı, 2026'nın güvenlik ve operasyon beklentilerine uygun bir iş akışına dönüştürebilirsiniz.

İhtiyacınız mevcut sitenizin veritabanını taşımaksa Corelux Linux Hosting seçeneklerini; daha fazla sunucu yönetimi gerektiren projeler için Sanal Sunucu ve Kiralık Sunucu hizmetlerini inceleyebilirsiniz. Hangi ortamı seçerseniz seçin, düzenli yedekleme ve geri yükleme testi taşıma planınızın parçası olsun.