Hakkaten direndim ama yok, illa muhabbete saracağız :)) Şimdi, öncelikle, bu zahmete evet, laptop'um için giriyorum. Aslında zaten laptop ile sunucu arasında da çok bir fark görmüyorum. Sanallaştırma sistemlerini de kullanıyorum elbette, ama özel işler için. Mesela VirtualBox olmazsa olmazlarım arasında. Onun dışında Docker kullanayım dedim, fakat Docker'da veri tutulamadığı yönünde yazıları okuyunca bundan vazgeçtim. Zaten Docker'ı mantık olarak kopyalamakta bir problem göremiyorum. Hazır görememişken, şöyle bir şey yapmıştım: https://github.com/aktos-io/lxc-to-the-future Şu anda bu yöntem sunucularımızda kullanılıyor.
Yani Docker yerine LXC'yi doğrudan kullanıyorum, Docker ile hazırlanan altyapı yerine kullandığım işletim sisteminin o anki kopyasını çıkarıyorum (`git clone` gibi). Bu kopyayı LXC ile açıyorum, ister ilelebet bir server gibi kullanıyorum, ister deneme yanılma yapıyorum (mesela basitçe `apt-get upgrade && apt-get dist-upgrade` burada yapılabilir). Sonra, bu sanal makina artık host makinam olarak çalışsın istersem bilgisayarı yeniden başlatıyorum, Grub ekranında `...subvol=/var/lib/lxc/mytest/rootfs` deyip sistemi buradan açabiliyorum. Bunlar hep güzel şeyler. Bu zamana kadar 2 kez diskim çöktü, 1 kez laptop'ım çalındı. İlkinde diskim çökmüştü, bitirme projemi aklımda kaldığı kadarıyla sıfırdan, 1 haftada yazmıştım. 2.'sinde bilgisayarım çalınmıştı, projelerimin ve kişisel dosyalarımın bir kısmına anneme hediye ettiğim makinada kalan dosyalarımdan ulaşmıştım (giden gitmişti, ayrıca bütün bilgiler çalan kişinin eline geçmişti), 3.sünde (geçtiğimiz günlerde) diskim bir anda çöktü, sıfır veri kaybıyla atlattım. Ama yedeklere dönme işi 3 günümü aldı (Cryptroot'un UUID meselesine takıldım). Şimdi, istiyorum ki, nasıl bir projeyi `git init && git ... && git push` yapıp sonra `git clone` deyip kopyalayabiliyorsak, tüm bilgisayarı da aynı şekilde yedekleyip geri yedekten yükleyebilmeliyiz. Nasıl ki `git` sadece değişiklikleri gönderiyorsa biz de değişiklikleri göndermeliyiz (vs.) ve nasıl ki `git` ile işler tek komutta bitiyorsa, bizimkinde de öyle kolay olmalı. "Buluttan çalışmak işi ile uzak masaüstü ile çalışma işi aynı şey" noktasından hareketle (yanılıyorsam düzeltin lütfen) internet bağlantısının sıkıntılı olduğu noktalarda bu şekilde çalışamayız. Kaldı ki bizler bilgisayarlarımıza dönüştürücüler takıp sahadaki makinalara bağlanıyoruz. İnternetin çok problemli olduğu veya hiç olmadığı zamanlar olduğu noktalarda bilgisayarlarımızı kullanmamız gerekiyor. UUID kopyalama işi zaten sorun değil, sonuçta yeni diskin UUID'sini de istediğimiz gibi değiştirebiliriz. Fakat iki tane aynı UUID'li diski bilgisayara aynı anda bağlamak mümkün olmayacağı için bilgisayara bağlı diskler sadece rol değiştiremeyecek. Aynı anda yalnızca biri bağlı olabilir. Kaldı ki problem sadece UUID'lerin farklılaşması değil, disk yerleşimi de değişebilir. Sanırım kullanım noktamı söylersem daha anlaşılır olacak. Bendeniz işimin bir parçası olarak laptop'ım ile sahada makina programlıyorum. "Saha" dediğimiz yer bir fabrika da olabilir, dağın başında bir tesis de olabilir. Böyle bir yerde, siloların tepesinde bilgisayarınızı elinizden düşürürseniz (evet, düşürmemeniz lazım, ama düşebilir) bunun size maliyeti bilgisayardan çok çok çok daha fazla olur. Bilgisayar birkaç bin TL'ye alınabilir, ancak orada işiniz durursa tüm ekip durur. Ben de şöyle bir çözüm buldum: Bilgisayara bir harici disk bağlayacağım, sahada güvenli bir noktada bunu bilgisayarla eşitleyeceğim (bu işlem en en en fazla bir çay içimi süresinde bitmeli). Bu aldığım yedek o güvenli noktada duracak. Ben çalışırken oraya bıraktığım yedek de çalınabilir (evet, garip bir ülkede yaşıyoruz, adam beğendiği için alabiliyor), dolayısıyla hiçbir özel verimin de başkaları tarafından okunmaması gerekir, bu yüzden kriptolu disklerde tutulmalı. Bir sürü garip garip dosya sistemi barındıracak bu diski bilgisayara bağladığımda da her biri için tek tek uğraşmamalıyım, taktığım anda kriptosu da açılmalı, LVM de aktifleştirilmeli, uygun disk uygun yere mount da edilmeli. Yani bir flaş belleği basitçe usb'ye dürtmekten farkı olmamalı. Bilgisayarımın başına bir şey gelirse herhangi bir bilgisayara "FBI adına" el koyup o az önce aldığım yedek diski takıp işime devam edebilmeliyim. Bu arada, yedek disk ile bilgisayarı açtığımda hemencecik herhangi bir diski az önceki yedeğin rolüne koyabilmeliyim. Bunun için belki o anda uygun ebatta disk bulamayacağım. O zaman birkaç disk bulmalıyım. Bunları da LVM ile biraraya getirip sistemin yedeğini tekrar oluşturmalıyım. Tüm bu "yeni yedek diski oluşturma işi" de yine 1 bardak çay içme süresini geçmemeli. Smith-sync'i bu yüzden yazmaya başladım: https://github.com/ceremcem/smith-sync Bu arada kişisel verilerin olduğu klasör anlık olarak webdav üzerinden yedekleniyor, ama bahsettiğimiz senaryoda internet erişimi kısıtlı olabilir demiştik. Bunu çözmek için de yanımızdaki kendi kablosuz ağımıza bağlı başka bir makine (bu bir Raspberry de olabilir) anlık olarak bu değişiklikleri yedekleyecek, uygun bağlantı bulduğunda kendi sunucularımızla eşitleyecek. Bunu henüz yapmadık ama yapılacaklar listesinde duruyor. rsync'nin de kendine göre sıkıntıları vardı, onu hallettiler mi bilmiyorum ama büyük boyutlu bir dosyanın yerini değiştirdiğinizde değişikliği "silme" ve "yeni dosya oluşturma" olarak görüyor. Aslında o konu çözülse rsync de gayet güzel kullanılabilir. Onun dışında deneme imkanım olmadı ama `bup` güzel bir seçenek gibi duruyor (https://bup.github.io/). Fakat yine, aynı noktaya geliyoruz, bunlar hep yedek alma stratejileri. Yedeklerden sistemi açma konusu bunların dışında kalıyor. Son birkaç haftada çeşitli sebeplerden dolayı tüm sistemimi (800 GB kadar) bir diskten diğer diske taşıyıp durdum. Bunlar arasında katman farkı olanlar da vardı (BTRFS//LVM//LUKS, BTRFS//LUKS) fiziksel farklar olan da vardı (rootfs//DISK_1 -> rootfs//DISK_1 + home//DISK_2). Tüm bu noktalarda işler gayet başarılı oldu ama özellikle şu initramfs'ye parametre verme işinde fena halde takıldım. Bir de yedek rootfs'nin değişmesi gereken /etc/fstab ve /etc/crypttab meselesine bir çözüm getirmek gerekir. 17 Ekim 2017 13:46 tarihinde Abdullah Ülker (Yandex) <abdullahul...@yandex.com> yazdı: > +1 > > > 17 Ekim 2017 13:24:02 Koray Toksöz <ktok...@gmail.com> yazdı: > >> Merhaba >> >> ben de sohbete bir köşesinden dahil olayım, >> Öncelikle şunu belirteyim, uzmanlığım sistem yönetimi değil, yazılım >> geliştirme. >> >> Bu kadar zahmete dizüstü bilgisayarınızı çalışır durumda tutmak için >> girmediğinizi varsayıyorum, kişisel bilgisayarda sadece verilerinizin >> yedeğini almak yeterlidir bence. Bu veriler resimler, libreoffice >> dokümanları vb. olabilir. En zorlu senaryoda bir NAS cihazı alır basit bir >> rsync scripti yazar cron a bağlarsınız. >> >> sunucu tarafına gelirsek, bence burada istediğiniz şey standard dışı bir >> durum olduğu için sorun yaşıyorsunuz. >> >> Normal şartlarda, “yedekleme", yedeklemeye çalıştığınız senaryoya özel >> olmalıdır, öncelik sistemi kurtarmadan önce, sistemi sürekli çalışır halde >> tutmak bence. >> Bir örnek vermem gerekirse, >> >> bir uygulamanız var, bu uygulama arkada dört tomcat uygulama sunucusu, >> mongo sunucuları, redis, iki nginx web sunucusu ve bir fiziksel load >> balancer cihazından oluşsun. >> >> Dikkat ettiyseniz bu uygulama katmanı, bu katmanda yedeklilik zaten >> uygulama sunucular seviyesinde sağlanmış, örneğin 4 app serverden herhangi >> birinin başına birşey gelirse kimsenin haberi bile olmaz (hatta sistem >> yöneticisinin de haberi olmayabilir, o yüzden monitoring önemlidir:)) >> >> birden fazla sunucu, redundant güç kaynakları, hatta birden fazla rack >> kabinet üzerinde şase yedekliliği de sağladınız, veritabanı yedeklerinizi >> düzenli alıyor, yazılım geliştirme yaşam döngüsünü oturtmuş ve >> uygulamalarınızı ona göre yaygınlaştırıp sistemlerinizi izliyorsunuz, >> network switchlerinizde de yedeklilik var ama yetmiyor, hatta tier-3 >> seviyesinde veri merkeziniz bile var ama felaket kurtarma istiyorsunuz, bu >> durumda, coğrafi olarak yedeklilik düşünebilirsiniz, bir tane de konyaya >> benzer sistemi kurarsınız. >> Tebrikler, ufak bir uygulamanız vardı, artık coğrafi yedekliliğiniz, >> jeneratörleriniz, upsleriniz, network cihazlarınızın yedekliliği, >> veritabanı ve sanallaştırma çözümleriniznn yedeklerini almak için LTO >> yedekleme üniteleriniz, firewall, IDS ve IPS sistemleriniz, yedekli hatta >> belki aynı anda birden fazla operatörden aldığınız internet hizmetleriniz, >> fiziksel güvenliği sağlamak için özel güvenlikleriniz, 24 saat veri >> merkezini izleyen elemanlarınız oldu :) >> >> Bütün bunların yerine, bulut çözümlerini de kullanabilirsiniz tabii ki, >> ihtiyacınız kadar alır, çok daha az ödersiniz. >> >> sunucularda sanallaştırmadan hoşlanmadığınızı söylemişsiniz, fakat ben >> sanallaştırmayı geçtim, yeni projelerimde mümkünse bulut içerisinde, >> değilse kendi sistemlerimde container tabanlı bir yapı kurmaya çalışıyorum >> (docker olarak anahtar kelime verebilirim) >> >> Bir küçük anıyla noktalayayım, >> >> bir şekilde üzerinde veritabanı çalışan sunucudan (maalesef açık kaynak >> değil) bazı sistem dosyaları da dahil olmak üzere silmeyi başarmışlar (rm >> -rf / belki de:)) çalışan başka bir sistemden ve rpm depolarından dosyaları >> kopyalayarak birkaç restart ile o sunucuyu çalışır hale getirmeyi >> başarmıştım yarım gün içerisinde. Demem odur ki, linux tabanlı sistemlerde, >> "mavi ekrana düşüyorum, güvenli kipte de açılmadı formatı basmam lazım >> başka çaresi yok (!)” demeden önce pek çok çözüm bulunabilir. >> >> iyi çalışmalar dilerim >> >> >>> On 17 Oct 2017, at 12:06, Cerem Cem ASLAN <cerem...@ceremcem.net> wrote: >>> >>> "Sistem" ve "koşan uygulamalar" derken tam olarak nasıl bir ayrımdan >>> bahsettiğimizi anlayamadım. Bana sorsanız "sistem zaten koşan >>> uygulamalardan oluşur" derdim, belki belki sanal makinaları bunun >>> dışında bırakmak gerekirdi. >>> >>> Sistemi sanallaştırmak her zaman çözüm olamıyor maalesef. Şahsen >>> sanallaştırma işini oldukça da gerilimli buluyorum. Mesela virtualbox >>> hatası verip durduğu için açılmayan sunucularınız oldu mu? Benim oldu >>> :) Dosya kurtarmaya kalkmak da oldukça sıkıntılı oluyor. Yani >>> sanallaştırma bir seçenek, fakat bir Alex değil. >> >> >> >> >> ---------- >> _______________________________________________ >> Linux-sohbet mailing list >> Linux-sohbet@liste.linux.org.tr >> https://liste.linux.org.tr/mailman/listinfo/linux-sohbet >> Liste kurallari: http://liste.linux.org.tr/kurallar.php >> > > > _______________________________________________ > Linux-sohbet mailing list > Linux-sohbet@liste.linux.org.tr > https://liste.linux.org.tr/mailman/listinfo/linux-sohbet > Liste kurallari: http://liste.linux.org.tr/kurallar.php _______________________________________________ Linux-sohbet mailing list Linux-sohbet@liste.linux.org.tr https://liste.linux.org.tr/mailman/listinfo/linux-sohbet Liste kurallari: http://liste.linux.org.tr/kurallar.php
