Bash Betik Yazma Temelleri

Bir sunucuyu yönetirken aynı komut dizisini gün içinde onlarca kez elle yazdığınızı fark ettiyseniz, aslında bir bash betiği yazmanın tam zamanı gelmiş demektir. Terminale tek tek girdiğiniz komutları bir metin dosyasına dizip tek bir isimle çağırabilmek; yani "yedek al", "logları temizle", "servisi yeniden başlat" gibi işleri bir tuşa indirgemek, sistem yöneticiliğinin en çok zaman kazandıran alışkanlığıdır. Bash betiği yazmak için ayrı bir program kurmanıza gerek yok: hemen her Linux dağıtımında hazır gelen bash kabuğu ve basit bir metin düzenleyici yeterli. Öğrenme eğrisi de sandığınızdan çok daha yumuşaktır, çünkü zaten bildiğiniz terminal komutlarını bir dosyaya taşımaktan ibarettir.

Bu rehberde sıfırdan başlayarak ilk çalışan betiğinizi yazacak, ardından her ciddi betikte karşınıza çıkacak temel yapı taşlarını tek tek ele alacağız: #!/bin/bash shebang satırı, chmod +x ile betiği çalıştırılabilir yapma, değişken tanımlama ve doğru alıntılama, $() ile bir komutun çıktısını yakalama, read ile kullanıcıdan girdi alma ve $1 gibi konumsal parametrelerle betiğe dışarıdan argüman geçme. Sonunda da öğrendiklerimizi birleştirip küçük ama gerçekten işe yarayan bir sistem bilgisi ve yedekleme betiği yazacağız. Örnekler Ubuntu ve Debian tabanlı sistemlerde denendi, fakat neredeyse tamamı AlmaLinux, Rocky Linux ve diğer dağıtımlarda da harfi harfine aynı çalışır.

Betik Yazmadan Önce: Neye İhtiyacınız Var#

Bir bash betiği, özünde satır satır çalıştırılan komutlar içeren düz bir metin dosyasıdır. Terminale elle girdiğiniz her komut, bir betiğin içine de aynen yazılabilir; betik çalıştığında bu komutlar tıpkı sizin yazdığınız gibi, yukarıdan aşağıya sırayla işletilir. Dolayısıyla temel Linux komutlarına aşinaysanız yolun yarısını çoktan geçmişsinizdir. Henüz cd, ls, cp, mkdir, rm gibi komutlarla aranız çok iyi değilse, önce temel Linux komutları yazımıza bir göz atmanızı öneririm; oradaki komutların hepsi birazdan yazacağınız betiklerin yapı taşları olacak.

İhtiyacınız olan tek araç bir metin düzenleyicidir. Sunucuda doğrudan çalışıyorsanız nano yeni başlayanlar için en rahatıdır; vim veya micro de tercih edilebilir. Betikleri koymak için genelde iki yer kullanılır: kişisel betiklerinizi ~/bin altında tutabilir, sistem geneli çalışacak betikleri ise /usr/local/bin içine koyabilirsiniz. Şimdilik ev dizininizde bir çalışma klasörü açalım ve orada ilerleyelim:

mkdir -p ~/betikler
cd ~/betikler
nano merhaba.sh

Uzantı olarak .sh kullanmak zorunlu değildir; Linux dosya uzantısına değil, dosyanın içeriğine ve iznine bakar. Yine de .sh uzantısı, dosyanın bir kabuk betiği olduğunu ilk bakışta anlamanızı sağladığı için yaygın bir alışkanlıktır.

Shebang Satırı: #!/bin/bash#

Her düzgün betiğin ilk satırı #! ile başlayan shebang (ya da hashbang) satırıdır. Bu iki karakter, işletim sistemine "bu dosyayı hangi yorumlayıcıyla çalıştırayım?" sorusunun cevabını verir. #!/bin/bash yazdığınızda, çekirdek dosyayı /bin/bash programına teslim eder ve içindeki komutlar bash söz dizimine göre yorumlanır. Bu satır olmadan da betiğiniz çoğu zaman çalışır, ama hangi kabuğun kullanılacağı ortama bağlı kalır; bu da farklı sunucularda farklı davranışlara yol açabilir. Bu yüzden shebang'i asla atlamayın.

İlk betiğimizi yazalım. merhaba.sh dosyasına şunları girin:

#!/bin/bash

# Bu benim ilk betiğim
echo "Merhaba, dunya!"
echo "Bu betik $(date) tarihinde calisti."

Buradaki # işaretiyle başlayan satır bir yorumdur; bash onu görmezden gelir, yalnızca sizin ve sizden sonra kodu okuyacak kişiler içindir. Shebang satırındaki #! ise özel bir istisnadır ve yorum sayılmaz. echo komutu ekrana metin yazdırır; ikinci echo satırında birazdan öğreneceğimiz komut çıktısı yakalamayı önden gördünüz.

Sık karşılaşılan bir soru, #!/bin/bash yerine #!/bin/sh yazmanın farkı olup olmadığıdır. Aşağıdaki tablo iki yaygın shebang seçeneğini karşılaştırıyor:

Başlangıç için #!/bin/bash en güvenli ve en yaygın seçimdir; bu rehber boyunca onu kullanacağız.

Betiği Çalıştırılabilir Yapmak: chmod +x#

Betiğinizi yazıp kaydettiniz, peki şimdi nasıl çalıştıracaksınız? İki yol var. Birincisi, betiği doğrudan bash'e argüman olarak vermektir:

bash merhaba.sh

Bu yöntem her zaman çalışır ve dosyanın çalıştırma izni olup olmadığına bakmaz. Ancak asıl istediğimiz, betiği ./merhaba.sh diye adıyla çağırabilmek. Bunun için dosyaya çalıştırma izni vermemiz gerekir; bunu chmod komutuyla yaparız:

chmod +x merhaba.sh
./merhaba.sh

chmod +x komutu, dosyanın izin bitlerine "çalıştırılabilir" (execute) bayrağını ekler. İzinleri ls -l ile kontrol ettiğinizde, dosya adının başındaki dizide x harflerinin belirdiğini görürsünüz:

$ ls -l merhaba.sh
-rwxr-xr-x 1 kullanici kullanici 118 Jul 10 14:22 merhaba.sh

Buradaki rwx sizin (dosya sahibinin) okuma, yazma ve çalıştırma iznine sahip olduğunuzu gösterir. Betiği ./ ön ekiyle çağırmamızın nedeni, Linux'un güvenlik gereği bulunduğunuz dizindeki programları varsayılan olarak PATH üzerinden aramamasıdır; ./ ile "betik tam burada, bu dizinde" demiş oluruz. Betiği her yerden adıyla çağırmak isterseniz, onu PATH içindeki bir dizine (örneğin /usr/local/bin) taşımanız veya kopyalamanız yeterlidir.

Değişkenler ve Doğru Alıntılama#

Değişkenler, betik içinde bir değeri saklayıp sonra tekrar tekrar kullanmanızı sağlar. Bash'te değişken tanımı son derece basittir, ama iki kural vardır ki yeni başlayanların en çok takıldığı yer burasıdır: eşittir işaretinin iki yanında boşluk olmaz.

#!/bin/bash

ad="Ahmet"
dizin="/var/www/site"
sayi=42

echo "Kullanici: $ad"
echo "Hedef dizin: $dizin"

Değişkeni tanımlarken başına $ koymazsınız (ad="Ahmet"), ama değeri kullanırken başına $ eklersiniz ($ad). ad = "Ahmet" gibi eşittirin yanına boşluk koyarsanız bash bunu bir komut çağrısı sanır ve hata verir; bu son derece yaygın bir acemi hatasıdır.

İşin en kritik kısmı alıntılama (quoting), yani değişkenleri tırnak içine alma biçimidir. Çift tırnak "..." içindeki değişkenler genişletilir, yani değerleriyle değiştirilir; tek tırnak '...' içindekiler ise olduğu gibi, harfi harfine bırakılır. Aşağıdaki tablo farkı net gösteriyor:

Pratik kural şudur: değişkenlerinizi neredeyse her zaman çift tırnak içinde kullanın. Özellikle dosya yolları söz konusuysa bu hayati önemdedir, çünkü tırnaksız bir değişken içindeki boşluk, bash tarafından iki ayrı argüman gibi yorumlanır. Örneğin dizin="/home/kullanici/Belgeler ve Notlar" gibi boşluklu bir yolu rm -r $dizin diye tırnaksız silmeye kalkarsanız, bash bunu iki ayrı hedef sanar ve tamamen yanlış dosyaları silebilir. rm -r "$dizin" yazarak bu felaketten kaçınırsınız.

Süslü parantezli ${degisken} biçimi, değişken adının nerede bittiğini belirsizleştiren durumlarda işinize yarar. Örneğin bir dosya adının sonuna sabit bir ek getirmek isterseniz ${ad}_backup.tar.gz yazmanız gerekir; $ad_backup yazarsanız bash ad_backup adında bambaşka bir değişken arar ve boş döner.

Komut Çıktısını Yakalama: $() Kullanımı#

Betiklerin en güçlü yanlarından biri, bir komutun ürettiği çıktıyı alıp bir değişkene koyabilmenizdir. Buna komut ikamesi (command substitution) denir ve $(komut) söz dizimiyle yapılır. İçindeki komut çalıştırılır, ürettiği metin de sanki oraya elle yazmışsınız gibi yerine geçer:

#!/bin/bash

tarih=$(date +%Y-%m-%d)
kullanici=$(whoami)
dosya_sayisi=$(ls -1 | wc -l)

echo "Bugun $tarih, kullanici $kullanici olarak giris yaptin."
echo "Bu dizinde $dosya_sayisi dosya var."

Burada date +%Y-%m-%d komutunun çıktısı (2026-07-10 gibi) tarih değişkenine yazıldı; whoami çıktısı kullaniciye, ls -1 | wc -l ile hesaplanan dosya sayısı da dosya_sayisina atandı. Bu tarih biçimlendirmesi özellikle yedekleme betiklerinde çok işe yarar, çünkü her yedeğe tarihli benzersiz bir isim vermenizi sağlar.

Eski betiklerde $() yerine ters tırnak (backtick) `komut` biçimini de görürsünüz. İkisi de aynı işi yapar, fakat $() biçimi hem daha okunaklıdır hem de iç içe kullanıma izin verir; örneğin $(dirname $(readlink -f "$0")) gibi. Bu yüzden yeni yazacağınız betiklerde ters tırnağı bırakıp $() kullanmanızı öneririm. Komut ikamesini bir koşulda da kullanabilirsiniz; örneğin bir dizinin var olup olmadığını kontrol edip yoksa oluşturmak, birazdaki örnek betikte tam olarak yapacağımız şeydir.

read ile Kullanıcıdan Girdi Almak#

Bazen betiğin çalışırken kullanıcıya bir soru sorması gerekir: "Hangi dizini yedekleyeyim?", "Devam etmek istiyor musunuz?" gibi. Bunun için read komutunu kullanırız. read, kullanıcının klavyeden girip Enter'a bastığı satırı okur ve belirttiğiniz değişkene atar:

#!/bin/bash

read -p "Adiniz nedir? " isim
echo "Merhaba $isim, hos geldin!"

read -p "Yedeklenecek dizini girin: " hedef
echo "Secilen dizin: $hedef"

-p seçeneği, girdi beklerken ekrana bir istem (prompt) yazdırır; böylece kullanıcı ne girmesi gerektiğini bilir. Parola gibi ekranda görünmemesi gereken bir şey okuyorsanız -s (sessiz) seçeneğini ekleyin:

read -s -p "Parolayi girin: " parola
echo
echo "Parola alindi."

Bir de kullanıcıya evet/hayır tarzı bir onay sorusu sormak yaygındır. Genellikle bunu bir koşulla birleştirir ve olumsuz cevapta betiği durdururuz:

read -p "Islem geri alinamaz. Devam edilsin mi? (e/h) " cevap
if [[ "$cevap" != "e" ]]; then
    echo "Iptal edildi."
    exit 1
fi
echo "Devam ediliyor..."

Buradaki [[ ... ]] bash'in koşul testidir; exit 1 ise betiği sıfırdan farklı bir çıkış koduyla, yani "başarısız/iptal" anlamında sonlandırır. read çoğunlukla insan etkileşimi gereken, elle çalıştırılan betikler için idealdir. Buna karşılık cron ile zamanlanmış görevlerde betik kimseyle konuşamayacağı için orada girdiyi read yerine konumsal parametrelerle veya sabit değerlerle vermeniz gerekir; şimdi tam da o konuya geliyoruz.

Konumsal Parametreler: Betiğe Argüman Geçmek#

Bir betiği çalıştırırken ona doğrudan komut satırından argüman geçebilirsiniz, tıpkı cp kaynak hedef derken cp'ye iki argüman geçtiğiniz gibi. Betik içinde bu argümanlara konumsal parametreler ile erişirsiniz: ilk argüman $1, ikincisi $2, üçüncüsü $3 şeklinde devam eder. Ayrıca birkaç özel değişken daha vardır:

Basit bir örnekle görelim. selamla.sh adında bir betik yazalım:

#!/bin/bash

echo "Betik adi: $0"
echo "Toplam arguman: $#"
echo "Merhaba $1!"

Şöyle çağırıldığında:

$ ./selamla.sh Mehmet
Betik adi: ./selamla.sh
Toplam arguman: 1
Merhaba Mehmet!

Konumsal parametreler, betiği esnek ve tekrar kullanılabilir kılar; her seferinde kodun içini değiştirmek yerine, farklı argümanlarla aynı betiği çağırırsınız. İyi bir betik, argümanın verilip verilmediğini de kontrol eder. Aşağıdaki kalıp, argüman eksikse kullanıcıya nasıl kullanılacağını gösterip çıkar:

#!/bin/bash

if [[ $# -lt 1 ]]; then
    echo "Kullanim: $0 <dizin_adi>"
    exit 1
fi

hedef="$1"
echo "$hedef dizini isleniyor..."

Burada $# -lt 1 "argüman sayısı 1'den az mı?" diye sorar; eğer öyleyse betik kullanım bilgisini yazdırıp exit 1 ile durur. Bu tür bir savunmacı kontrol, betiğinizi başka birinin de güvenle kullanabilmesini sağlar.

Uygulamalı Örnek: Sistem Bilgisi ve Yedek Betiği#

Şimdi öğrendiğimiz her şeyi birleştirelim: shebang, değişkenler, komut ikamesi, konumsal parametre ve alıntılama. Aşağıdaki betik, kendisine argüman olarak verilen bir dizini tarih damgalı bir arşive sıkıştırır ve işlem hakkında özet bilgi verir. Gerçek sunucularda birebir kullanabileceğiniz, sade ama işlevsel bir yedekleme betiğidir:

#!/bin/bash

# yedekle.sh - Verilen dizini tarih damgali bir arsive yedekler
# Kullanim: ./yedekle.sh /var/www/site

# 1) Arguman kontrolu
if [[ $# -lt 1 ]]; then
    echo "Kullanim: $0 <yedeklenecek_dizin>"
    exit 1
fi

kaynak="$1"

# 2) Kaynak dizin gercekten var mi?
if [[ ! -d "$kaynak" ]]; then
    echo "Hata: '$kaynak' adinda bir dizin bulunamadi."
    exit 1
fi

# 3) Degiskenler ve komut ikamesi
tarih=$(date +%Y-%m-%d_%H-%M)
yedek_dizini="$HOME/yedekler"
dosya_adi="yedek_$(basename "$kaynak")_${tarih}.tar.gz"
hedef_yol="${yedek_dizini}/${dosya_adi}"

# 4) Yedek dizini yoksa olustur
mkdir -p "$yedek_dizini"

# 5) Sikistir ve arsivle
echo "-> '$kaynak' yedekleniyor..."
tar -czf "$hedef_yol" "$kaynak" 2>/dev/null

# 6) Sonucu raporla
if [[ $? -eq 0 ]]; then
    boyut=$(du -h "$hedef_yol" | cut -f1)
    echo "Basarili! Yedek olusturuldu:"
    echo "  Dosya : $hedef_yol"
    echo "  Boyut : $boyut"
    echo "  Tarih : $tarih"
else
    echo "Hata: Yedekleme sirasinda bir sorun olustu."
    exit 1
fi

Bu betikte pek çok kavramın bir arada çalıştığını görüyorsunuz. $1 ile yedeklenecek dizini dışarıdan alıyoruz; [[ ! -d "$kaynak" ]] ile o dizinin gerçekten var olup olmadığını kontrol ediyoruz. $(date +%Y-%m-%d_%H-%M) ile her yedeğe benzersiz bir tarih damgası, $(basename "$kaynak") ile de kaynak dizinin sade adını ekliyoruz; böylece /var/www/site için yedek_site_2026-07-10_14-30.tar.gz gibi anlamlı bir dosya adı oluşuyor. $? özel değişkeni, bir önceki komutun (burada tar) başarılı olup olmadığını söyler: 0 başarı, sıfırdan farklı her değer hatadır. Dikkat ederseniz her dosya yolunu çift tırnak içine aldık; bu, boşluk içeren dizin adlarında bile betiğin doğru çalışmasını garanti eder.

Bu betiği çalıştırılabilir yapıp deneyelim:

chmod +x yedekle.sh
./yedekle.sh /var/www/site

Bu betiği bir adım öteye taşıyıp her gece otomatik çalıştırmak isterseniz, tek yapmanız gereken onu bir cron görevine bağlamaktır. Örneğin her gece 03.00'te çalıştırmak için crontab satırınız şöyle olur:

0 3 * * * /home/kullanici/betikler/yedekle.sh /var/www/site >> /home/kullanici/yedek.log 2>&1

Bu satırın her parçasının ne anlama geldiğini ve cron'un beş alanlı zaman söz dizimini cron ile zamanlanmış görevler rehberimizde ayrıntısıyla bulabilirsiniz. Yedeklerinizin sunucu dışında güvenli bir yerde de durması içinse, düzenli yedekleme hizmetimiz devreye girerek betiğinizin oluşturduğu arşivleri felaket kurtarma senaryolarına karşı ikinci bir kopyada saklamanıza yardımcı olur.

Betikleri Güvenli ve Bakımı Kolay Tutmak#

İlk betiklerinizi yazarken birkaç iyi alışkanlığı baştan edinmek, ileride başınızı ağrıtacak hataların önüne geçer. Bunların en önemlisi, betiğin başına set -euo pipefail satırını eklemektir. Bu satır bash'i "katı mod"a alır: -e bir komut hata verdiğinde betiği durdurur, -u tanımsız bir değişken kullanmaya çalıştığınızda uyarır, pipefail ise bir boru hattındaki (pipe) herhangi bir komutun hatasını yakalar. Özellikle dosya silen veya taşıyan betiklerde bu koruma paha biçilmezdir:

#!/bin/bash
set -euo pipefail

# Buradan itibaren herhangi bir hata betigi hemen durdurur

İkinci alışkanlık, değişkenleri her zaman çift tırnak içinde kullanmak; bunu yukarıda ısrarla vurguladık, çünkü tırnaksız bir değişken en sinsi hataların kaynağıdır. Üçüncüsü, betiklerinize bol bol yorum eklemek: altı ay sonra kendi betiğinize baktığınızda "burada ne yapmıştım?" dememek için her önemli bloğun başına bir açıklama satırı koyun. Dördüncüsü, silme gibi geri alınamaz işlemleri her zaman read ile bir onaya bağlamak veya en azından önce echo ile ne yapacağını yazdırıp "kuru çalıştırma" (dry run) yaptırmaktır.

Betikleriniz büyümeye başladığında, tekrar eden bloğu fonksiyonlara ayırmayı düşünün. Bir fonksiyon, adını verdiğiniz bir komut grubudur ve betiğin okunabilirliğini ciddi biçimde artırır:

#!/bin/bash

log() {
    echo "[$(date +%H:%M:%S)] $1"
}

log "Islem basladi"
# ... isler ...
log "Islem tamamlandi"

Betiklerinizi yazarken sözdizimi hatalarını yakalamak için bash -n betik.sh komutuyla betiği çalıştırmadan denetleyebilir, daha titiz bir kontrol için shellcheck aracını kurup kullanabilirsiniz; bu araç, tırnak eksiklerinden değişken hatalarına kadar pek çok tuzağı önceden gösterir. Otomasyon iştahınız arttıkça, bash betiklerinin ötesine geçip birden çok sunucuyu tek merkezden yönetmek isterseniz, işletim mantığını daha yapısal ele alan sunucu yönetimi hizmetlerimize ve kendi VDS sunucularımıza göz atabilirsiniz; betiklerinizi çalıştıracağınız kararlı bir ortam, otomasyonun ilk şartıdır.

Sıkça Sorulan Sorular#

Bash betiği ile shell betiği aynı şey mi?#

Tam olarak aynı değildir ama çok yakındır. Shell betiği, herhangi bir kabuk (shell) için yazılmış betiklerin genel adıdır; bash ise en yaygın kabuklardan biridir. #!/bin/bash shebang'i ile başlayan bir betik özellikle bash özelliklerini kullanabilir, #!/bin/sh ile başlayan bir betik ise yalnızca daha kısıtlı POSIX standardındaki özelliklere güvenmelidir. Yeni başlıyorsanız bash ile devam etmeniz, hem daha fazla özelliğe erişmenizi hem de bol kaynak bulmanızı sağlar.

Betiğimi çalıştırınca "Permission denied" hatası alıyorum, ne yapmalıyım?#

Bu hata neredeyse her zaman dosyanın çalıştırma iznine sahip olmamasından kaynaklanır. Terminale chmod +x betik.sh yazıp betiğe çalıştırma iznini verin, ardından ./betik.sh şeklinde tekrar deneyin. Eğer betiği bir sistem dizinine koyduysanız ve hâlâ hata alıyorsanız, o dizine yazma yetkiniz olmayabilir; bu durumda sudo ile denemeniz veya betiği yetkiniz olan bir dizine taşımanız gerekir.

Değişken tanımlarken neden hata alıyorum, sorun nerede?#

En sık yapılan hata, eşittir işaretinin çevresine boşluk koymaktır. Bash'te ad = "Ali" yazarsanız hata alırsınız; doğrusu boşluksuz ad="Ali" biçimidir. Bunun nedeni, boşluk bırakınca bash'in ad adında bir komut çalıştırmaya çalışmasıdır. Ayrıca değişkeni tanımlarken başına $ koymadığınızdan, ama kullanırken $ad şeklinde koyduğunuzdan emin olun.

Betiğin çalışırken hata verip vermediğini nasıl anlarım?#

Her komut çalıştıktan sonra bash, $? özel değişkenine o komutun çıkış kodunu yazar. 0 değeri başarıyı, sıfırdan farklı herhangi bir değer ise bir hatayı gösterir. Betiğinizde önemli bir komuttan hemen sonra if [[ $? -ne 0 ]]; then ...; fi kalıbıyla bu kodu kontrol edebilirsiniz. Daha güçlü bir yaklaşım, betiğin başına set -e eklemektir; bu, herhangi bir komut hata verdiği an betiği otomatik olarak durdurur.

read yerine argüman kullanmanın avantajı nedir?#

read komutu betiği çalıştıran kişiye anlık soru sorar ve klavyeden cevap bekler; bu yüzden yalnızca birinin başında oturup elle çalıştırdığı betikler için uygundur. Konumsal parametreler ($1, $2) ise değeri komut satırından baştan alır, dolayısıyla betik hiç kimseyle konuşmadan çalışabilir. Cron gibi otomatik zamanlayıcılarda betik etkileşim kuramayacağı için mutlaka argüman veya sabit değer kullanmanız gerekir; read orada takılıp kalır.

Betiklerimi sunucuda nerede saklamalıyım?#

Yalnızca kendi kullanacağınız kişisel betikler için ev dizininizde bir ~/bin klasörü açmak yaygın bir tercihtir; bu dizin çoğu sistemde otomatik olarak PATH içine eklenir, böylece betikleri her yerden adıyla çağırabilirsiniz. Sistem genelinde ve diğer kullanıcılar için de çalışması gereken betikleri ise /usr/local/bin altına koymak gelenektir. Hangi konumu seçerseniz seçin, betiklerin sürüm kontrolüyle (örneğin Git) yedeklendiğinden emin olun; bir betik ne kadar küçük olursa olsun, kaybolduğunda yeniden yazmak zaman alır.

Kapanış#

Bash betik yazmayı öğrenmek, sunucu yönetiminde verimliliğinizi kalıcı olarak artıran becerilerden biridir. Bu rehberde bir betiğin iskeletini oluşturan tüm temel parçaları gördük: #!/bin/bash shebang satırıyla yorumlayıcıyı belirlemeyi, chmod +x ile betiği çalıştırılabilir kılmayı, değişkenleri tanımlayıp doğru biçimde alıntılamayı, $() ile komut çıktısını yakalamayı, read ile kullanıcıdan girdi almayı ve $1 gibi konumsal parametrelerle betiğe dışarıdan argüman geçmeyi. Sonunda da bunları birleştirip gerçekten işe yarayan bir yedekleme betiği yazdık. Buradan sonrası tekrar ve deneme meselesi: her gün elle yaptığınız bir işi fark ettiğinizde, "bunu bir betiğe dökebilir miyim?" diye sormaya başlayın.

Yazdığınız betiklerin gerçekten değer üretmesi için, onları kararlı ve kesintisiz çalışan bir ortamda barındırmanız gerekir. Otomasyon senaryolarınızı çalıştıracağınız güçlü bir altyapı arıyorsanız VDS sunucularımızı ve tam kök erişimi sunan sunucu çözümlerimizi inceleyebilir; günlük betiklerinizin ürettiği yedekleri güvence altına almak için yedekleme hizmetimize ve sunucunuzun yönetim yükünü bize devretmek isterseniz sunucu yönetimi paketlerimize göz atabilirsiniz. Web projeleriniz için daha hafif bir başlangıç düşünüyorsanız, hosting paketlerimiz da SSH erişimiyle küçük betiklerinizi çalıştırmanıza olanak tanır. Clou.TR ekibi olarak, terminaldeki ilk adımlarınızdan tam otomasyona kadar her aşamada yanınızdayız.