Soru Linux'u büyük bir bölüme kurmak ne kadar kötü?


Yeni sunucumuzda CentOS 7'yi çalıştırıyor olacağız. Sunucuya dahili olarak 6 x 300GB sürücümüz var. (Depolama, büyük ölçüde 40TB bir baskın kutusu şeklinde haricidır.) Dahili birim, tek bir birim olarak biçimlendirildiğinde yaklaşık 1,3 TB'a gelir. Sistemimiz, OS'yi büyük bir 1.3TB disk bölümüne kurmanın gerçekten kötü bir fikir olduğunu düşünüyor.

Ben biyologyum. Çalışmak ve test etmek için sürekli olarak yeni yazılımlar yüklüyoruz, bunların çoğu / usr / local içinde. Ancak, sistemi kullanan yaklaşık 12 bilgisayar bilgisine sahip olmayan biyologumuz olduğu için, aynı zamanda evde / evde de çok büyük bir hamle yapıyoruz. Son sunucumuzda 200GB'lik bir bölüm vardı ve 2.5 yıl sonra% 90 doluydu. Bunun tekrar olmasını istemiyorum ama aynı zamanda uzman tavsiyelerine karşı çıkmak istemiyorum!

Ne zaman ve nerede ihtiyaç duyulduğundan emin olmak için sysadmin için bir bakım kâbusu yaratmadığından emin olmak için 1.3TB'yi en iyi şekilde nasıl kullanabiliriz?


92
2017-09-18 08:12


Menşei


LVM kullanın ve irade ile yeniden boyutlandırın - thanasisk
@thanasisk İnternette küçültülebilen linux üzerinde dosya sistemi olmadığından yeniden boyutlandırılabilirlik bir efsanedir. ext2 eski zamanlarda böyle bir yama vardı. - peterh
@PeterHorvath - "genişlet" ile "yeniden boyutlandır" değiştirirseniz mutlu musunuz? - thanasisk
Şu anda 2,5 yılda optimal olmak için ne yaparsanız yapın, beklemek biraz gerçekçi değil! Ve merak uyandırıcı olmayan kullanıcıların karışıklık yaratması, OS'yi veriden ayırmanın daha fazla nedenidir. - JamesRyan
@PeterHorvath Yorumunuzu bir kereden fazla okudum, böylece anlayabiliyorum. Genişleyebilecek bir dosya sistemi var mı diye bir dosya sistemi belirttiysem mutlu olursun. Bu kadar. - gparent


Cevaplar:


Bölümleme için birincil (tarihsel) nedenler:

  • için işletim sistemini kullanıcı ve uygulama verilerinizden ayırın. RHEL 7'nin yayınlanmasına kadar desteklenmedi yükseltme yolu ve büyük bir sürüm yükseltmesi, bir yeniden yüklemeyi gerektirir ve daha sonra örneğin /home ve ayrı bölümler (veya LVM birimleri) üzerindeki diğer (uygulama) verileri, kullanıcı verilerini ve uygulama verilerini kolayca muhafaza etmenizi ve OS bölümlerini (ler) silmenizi sağlar.

  • Kullanıcılar düzgün bir şekilde oturum açamazlar ve sisteminiz, disk alanınız tamamen bittiğinde ilginç şekillerde başarısız olmaya başlar. Çoklu bölümler, işletim sistemi için sabit disk alanı atamanıza izin verir ve bunu, kullanıcıların ve / veya belirli uygulamaların yazılmasına izin verilen alandan ayrı tutmanızı sağlar (ör. /home /tmp/ /var/tmp/ /var/spool/ /oradata/ vb.) , operasyonel riski hafifletmek kötü niyetli kullanıcıların ve / veya uygulamaların.

  • Kota. Disk kotası, yöneticinin, tüm mevcut alanı kullanmasını ve sistemin diğer tüm kullanıcılarına hizmet vermesini engellemesini sağlar. Dosya sistemi başına tek tek disk kotası atanır, bu nedenle tek bir bölüm ve böylece tek bir dosya sistemi sadece 1 disk tırnak anlamına gelir. Çoklu (LVM) bölümler, daha ayrıntılı kota yönetimi sağlayan çoklu dosya sistemleri anlamına gelir. Kullanım senaryosuna bağlı olarak, örneğin her kullanıcının 10 GB'sini kendi ana dizininde, harici depolama dizisindeki / data dizinindeki 2TB'ye izin vermek ve herkesin kendi ana dizini için çok büyük veri kümelerini boşaltabileceği büyük bir kazıma alanı oluşturmak isteyebilirsiniz. Ve politikanın "dolu dolu" olduğu yerlerde, ancak bu gerçekleşmediğinde hiçbir şey de kırılmaz.

  • Sağlama adanmış IO yolları. SSD'lerin ve dönen disklerin bir kombinasyonuna sahip olabilirsiniz ve bunları farklı şekilde ele almak için iyi bir şey yaparsınız. Genel amaçlı bir sunucuda çok fazla sorun olmamakla birlikte, veritabanı kurulumlarında oldukça yaygın olan bir şey de, IO çekişmesini önlemek için belirli amaçlara belirli işmillerini (diskleri) atamaktır, örn. işlem günlükleri için ayrı disk, gerçek veritabanı verileri için ayrı diskler ve geçici alan için ayrı diskler. .

  • Çizme Ayrı bir ihtiyacın olabilir. /boot bölüm. Geçmişte, 1024 silindir sınırının ötesine geçerek BIOS sorunlarını ele almak için geçmişte, günümüzde daha çok şifrelenmiş birimleri destekleme, bazı RAID denetleyicilerini destekleme gereksinimi, SAN ya da yükleyici tarafından hemen desteklenmeyen dosya sistemlerini desteklemeyen HBA'lar destekleme gereksinimi.

  • akort Farklı ayar seçeneklerine ya da tamamen farklı dosya sistemlerine ihtiyaç duyabilirsiniz.

Eğer sabit disk bölümleri kullanırsanız, az ya da çok yükleme süresinde doğru bir şekilde elde etmeniz gerekir ve daha sonra tek bir büyük bölüm en kötü değildir, ancak yukarıdaki bazı kısıtlamalarla birlikte gelir.

Genellikle ana sesinizi bölüm olarak ayırmanızı tavsiye ederim. tek büyük Linux LVM fiziksel ses düzeyi ve sonra mantıksal birimler oluştur mevcut gereksinimlerinize ve disk alanınızın kalanına uygun, gerekene kadar atamasız bırak.

Bu birimleri ve dosya sistemlerini gerektikçe genişletebilirsiniz (bu, canlı bir sistemde yapılabilecek önemsiz bir işlemdir) veya ek olanları da oluşturabilirsiniz.

Küçülen LVM ciltleri önemsiz fakat çoğu zaman Dosya sistemlerini üzerlerine küçültmek çok iyi desteklenmiyor ve muhtemelen kaçınılmalıdır.


104
2017-09-18 09:49



Performansla ilgili olarak, bir dosya sisteminin hızlı bir şekilde yanıtlanması gerektiğinde, "df" nin yararlı bilgileri "du -s $ DIRNAME" e göre çok daha hızlı bir şekilde geri getireceğine de dikkat çekmek istiyorum. - symcbean
Katılıyorum emin değilim "kadar ... RH7 ... desteklenmeyen yükseltme yolu yok"Zaman aşımına uğradığı zamandan beri güncellemeleri destekledim ve kesinlikle RH4-> 5 sistemlerini güncelledim. sadece Böyle bir yola sahip olmayan RH5-> RH6, bilgime - ve RH'nin bu eksikliği için kullanıcılarına kapsamlı bir şekilde spankedilmiş hissetmesini sağlıyorum. Yine de mükemmel bir yanıtın geri kalanı için +1. - MadHatter
"RHEL 7 sürümü yayınlanana kadar desteklenen bir yükseltme yolu bulunmadığı" ile ilgili olarak ne diyorsunuz? RHEL, RHEL 7 ve ilerideki büyük sürümler arasında yükseltmeleri destekleyecek mi? - Markus Hallmann
Yükseltmeler işe yaramadı, ancak Kırmızı şapka genel politika hala: Red Hat, Red Hat Enterprise Linux'un büyük sürümleri arasında yerinde yükseltmeleri desteklemiyor.  ve biraz daha aşağı doğru Red Hat şu anda yalnızca Red Hat Enterprise Linux 6'dan Red Hat Enterprise Linux 7'ye özel / hedefli kullanım durumları için güncellemeleri destekliyor ve el kitabı kontrol etmek - HBruijn


Çoklu bölümler kullanma kavramı, yanlış yerde bir bütünün, tüm sistemin beklenmedik şekilde çalışmasına neden olmamasıdır.

Bir boş alan dolduran bir süreç düşünün, boş alan bulunmadığı noktaya kadar oldukça hızlı bir şekilde logfile doldurun. Tek bölümlü bir makinede, bu, örneğin, sistemin / tmp'ye yeni veri yazmasını engelleyebilir. / Tmp dosyasına yazmak isteyecek başka bir işlem varsa, büyük olasılıkla beklenmedik davranışlara neden olan bir hatadan çıkacaktır.

Kullanıcıların veya işlemlerin normal olarak yazdığı yerler için (/ home, / var, / tmp) farklı bölümler kullanıyorsanız bu durum engellenebilir.

Eski sunucunuzu hangi klasörlerin büyük olma eğiliminde olduğunu kontrol etmenizi tavsiye ederim. Bunu komut satırında yapabilirsiniz.

du -h -d 1 / 2> /dev/null

En fazla verinin biriktirildiği yeri görecek ve bir sonraki sisteminizi uygun şekilde tasarlayacaksınız. "-D 1", çıktının daha da okunabilir olmasını sağlayarak yalnızca bir klasör derinliği seviyesine sınırlar.


17
2017-09-18 08:38





Tek bir büyük bölüme sahip olmanın asıl problemi, dosya sistemini doldurabilmek, artık hiçbir girişin mümkün olmamasıdır.

Kullanıcı kökünün ana klasörü (/root) dışında /home bu nedenle. Dosya sistemi bazı durumlarda doldurulursa, kök sisteme giriş yapamaz ve sistemi onaramaz.

Normalde ayrı montaj noktaları yaratmanızın nedeni budur. /var, /tmp ve /home Diğer bölümlerden biri dolduğunda sistemi onarmak için en az root olarak oturum açabilmek.


12
2017-09-18 08:23



Bazı dosya sistemlerinde (ext3 f.e.), root kullanıcısı için bu davranışı engellemek için biraz ayrılmış alanınız olabilir. Bunu önlemek için kotalar kullanmanız gerekir, aynı sıklıkla unutulan / tmp için. - Dennis Nolte
@DennisNolte Unuttum /tmp. Teşekkürler, bunu cevabıma ekleyeceğim. - Uwe Plonus
@DennisNolte ayrılmış alan yardımcı olacaktır ama kotalar doğru bir şekilde kurmak zorunda olduğundan bakımın farklı bölümler kullanmaktan çok zor olduğunu düşünüyorum. - Uwe Plonus
Bence daha önemli bir sebep /root Dışarıda olmak /home bazı yüklemelerde /home bir ağ sürücüsünde olacak. Ağ üzerinden bir sorun olması durumunda, kök dosyaları erişilebilir durumda kalır. (Bu, genellikle bir metin düzenleyicinin nasıl olduğuyla karşılaştırılabilir. /bin, bu durumda /usr takılmayacak.) Bu uygulamada, bugünlerde daha yaygın bir senaryo olduğundan şüpheleniyorum. /home Bütün yolu dolduruyorum. - Eliah Kagan


IMHO, bir bölüm olarak oldukça makul.

Ama lvm'yi (mantıksal birim yöneticisi) kullanabilirsiniz. Tüm diski lvm grubu olarak kullanın, ancak /, / home, / usr ve sysadmin'iniz ne olursa olsun küçük mantıksal diskler oluşturun. Ardından, sisteminizin dolmaya başladığında ve ihtiyacınız olan diskleri genişletmeye başladığında, bazı gözlemler yapın. lvresize ve resize2fs çevrimiçi araçlardır ve sunucuyu yeniden başlatmadan genişletme yapabilirsiniz. Ancak diskleri azaltamazsınız, bu nedenle makul derecede küçük bir başlangıç ​​yapmalısınız ve ihtiyaç duyduğunuz yerde artış yapmanız gerekir.


10
2017-09-18 08:22





Linux'un büyük tek bölümlü kurulumu etrafında çok az sorun var, ancak büyük ödüller var.

Bir bölüm düzenini değiştirmek uzun süre durmadan sık sık yapamayacağınız biraz zor ve riskli bir şeydir.

Tek avantajı, disk sorunlarına karşı biraz korumanız olmasıdır. Ama sen bu problemleri bulacaksın çok genellikle. Bölümlerinizden biri dolu ise durumu düşünün, ve Neredeyse boş olsalar bile, diğer bölümlerdeki alanı kullanamazsınız!

Bazı profesyonel sistem yöneticileri bunun hakkında farklı görüşlere sahiptir. Birden fazla bölüme sahip olmanın sisteminizi daha güvenilir hale getirebileceğini ve bölümlemeden önce bilmeniz gerektiğini, bölümlerinizin ne kadar büyük olacağını söylüyorlar. Benim düşünceme göre, bu basitçe söylenemez, sistemdeki esneklik konusunda korkunç bir dezavantaj ve onların gerçek motivasyonları sadece bölüm haritalarıyla oynamayı seviyorum.

Adında basit bir sistem var lvm"sineklerin" (terminolojisinde, hacimlerinde) anında hareket etmesini / yeniden boyutlandırılmasını sağlar. Ancak tek bir yerel departman sunucusunda, IMHO normalde gerekli değildir.


9
2017-09-18 08:43



Ne tür bir mazoşist yönetici seviyor bölüm haritaları ile oynamak için ??? Eğlence bölümü çekirdeği inşa ediyor, Amin??? - bishop
Amin! Şimdi, yöneticilerin bölümlerle oynamayı sevdiği argüman hakkında, linux'un muhtemelen 100 farklı dosya sistemi türüne sahip olduğu ve kullanım şekillerine bağlı olarak, belirli bir görev için doğru dosya sisteminin seçilmesi ile ilgili olabilir. optimal sistem ve işlevsel olmayan bir sistem arasındaki fark. Ve belki sadece birkaç dosyada bu dosya sistemine ihtiyacın var. Orada. - Lennart Rolland


Bölümlemenin iki ana nedeni vardır:

  1. Statik verileri statik olmayan verilerden uzak tutmak için
  2. Herkese açık verileri özel verilerden uzak tutmak için

İlk sebep en belirgin olanıdır - dosyaları imkansız olan alanlardan dolduracak alanları ayırmanız ve özellikle önlenemeyen bir sistemden kaçınmak için / korumak istiyorsunuz. Örneğin, / var dizini, genellikle günlük dosyalarının saklanacağı yerdir (var "değişken" anlamına gelir) ve / var / var, ayrı bir bölüme /.

Yukarıdaki ikinci neden daha az alıntılanmıştır (En son 15 yıl önce bir Veritas Volume Manager kursunda duydum) ve gerçekten sadece birçok kişinin giriş yaptığı ve iş yaptığı sistemlerle ilgilidir.

Etkin bir bölüştürme için bir sanat eseri var ve belki de bu yüzden onu biraz fazla uzaklaştıran Sys Yöneticileri var (IMO). İçerideki dosya sistemini bilmeniz gerekmiyor, aynı zamanda kullanım amacını da bilmek zorundasınız. Kişisel olarak, bugün sunucuların kullanılma şekilleriyle daha az alakalı hale gelen oldukça eski moda bir yaklaşım olduğunu düşünüyorum.

Bir yazılım geliştiricisi olarak, özellikle Ops departmanı Sanal Makinaları'nı, mevcut toplam disk alanı ne olursa olsun / tmp, / home, / var ve /, boyutunu büyük ölçüde kısıtlayan düşüncesiz bölümleme şemaları ile beslemekten bıktım. / usr gibi açık seçimler veya ayrı olarak seç. Bu makineler genel olarak istediğiniz disk alanı dışında kalan herşeyi, kaçınılmaz olarak her şeyi kurmaya ve dönüştürmeye zorlayan bir "/ stuff" birimine koyarlar, ancak bu bir teselli değildir. Net sonuç olarak, çoğu zaman dosyaları gerçek bir iş yapmaktan daha fazla harcayarak ve uyarı e-postaları göndererek daha fazla zaman harcayabiliyoruz.

Tek bir bölüme sahip olma konusunda doğal olarak "kötü" bir şey yoktur. Herhangi bir sistemde, disk kullanımınızı proaktif bir şekilde izlemeniz ve mantıklı temizlik stratejileri kullanmanız gerekir (ör. Günlük döndürme, ev dizinlerinde kotalar), bu yüzden tek gerçek soru şudur: Kaç tane dosya sistemi hakkında endişelenmek istiyorsunuz?

Bu yüzden şunu söyleyebilirim: Belirli kullanım durumunuz için sistemi etkili bir şekilde bölme yeteneğinizden% 100 emin değilseniz, hiç bölümleme yapmayın..


3
2017-09-18 09:41



Kesinlikle. Tamam, belki de kamu-özel veri ayrımı dosya sistemindeki ve hizmetlerinizdeki izinlerle yapılmalıdır. - peterh


IMHO tamamen size kalmış. İlk önce birkaç şeyi düşünün, ancak tamamen biraz göreceli.

  • Bu sistem sık sık uygulanacak mı?
  • Bu sistem bir veya daha fazla kullanıcı tarafından kullanılacak mı?
  • Bu sistem bir masaüstü veya sunucu olarak mı yoksa her ikisi de mi olacak?

Bir kişi herhangi bir dizini bir bağlantı noktasını (neredeyse) göz önünde bulundurabildiğinden, aynı zamanda bir miktar büyüyen veriyi ve neyin büyüyen verileri içerdiğini de dikkate almalıdır.

Bir Linux sisteminin (biraz büyüyen veri) ne kadar küçük bir kısmının çalıştırılması gerektiğini ve büyüyen veriler tarafından ne kadar tüketildiğini (genellikle / var / opt / home / srv) şaşırtabilirsiniz.

Ayrıca, bölümleme gereksinimlerini özetleyen bu sistemin kullanımını nasıl tanımladığınıza bağlıdır. LVM için kullanım dahildir.

Tipik bir masaüstü sistemi, bir yazılım yükünü yüklemek için yaklaşık 20GB'a ihtiyaç duyar; LVM, sisteminizde küçük yüklere neden olur ve bu durumda bu büyük yararı yoktur. Görüşler farklılık gösterse de.

Bir sunucuda, kurulu yazılımın bir masaüstü sistemi kadar dinamik olması daha az olasıdır. Ayrıca, / tmp / var / usr / home / opt / srv gibi tipik dosya sistemi bileşenleri için gerçek bağlantı noktalarına sahip olmak akıllıcadır. LVM'nin burada kullanılması zorunlu değildir.

Bu, sisteminizin büyük ölçüde modüler olmasını sağlar, ayrıca bu bölümü bir VM'ye klonlamak gibi aptalca şeyler yapmaya da izin verir. Ya da dd kullanarak blok düzeyinde bir yedekleme oluşturmak.

Bazı deneyimlere dayanarak, birkaç not var. Ayrıca, daha fazla kontrol için çoklu montaj noktalarına izin vermeyi düşünün, hızlı veya yavaş bir disk cihazını bir montaj noktasına atamak, dünyayı bir fark yaratabilir ve maliyet verimliliğini önemli ölçüde artırabilir.

Mounpoint /

  • 1GB (/ var / usr / opt / home / tmp için ayrı bağlantı noktaları kullanılıyorsa)
  • Ayrı / ev içeren bir masaüstü sistem olarak kullanılıyorsa +10 veya hatta +20 GB

mountpoint / home kullanıyorsa

  • kullanılmışsa tüm boş alanı atayın, / home ne

mountpoint / opt kullanıyorsa

mountpoint / usr kullanılıyorsa

  • Bu zor bir ve yüklü yazılım tabanına büyük ölçüde bağımlı

mountpoint / var kullanılıyorsa

  • Bu zor bir ve yüklü yazılım tabanına büyük ölçüde bağımlı
  • Örneğin, veritabanları tüm Linux olmasa bile buradaki verilerini Debian tabanlı sistemlere yazarlar.
  • ayrı / var / tmp olması mantıksız değil

mountpoint / tmp kullanılıyorsa

  • Tmpfs var ve RAM için tahsis / tmp düşünün
  • Bazı uygulamaların burada çok fazla veri yazabileceğini düşünün

2
2017-09-18 14:18





Her şeyden önce, bu soruyu neden buraya gönderiyorsunuz sorusunu sormak zorundayım, çünkü sabit sürücü bölümlemelerinin daha ince noktaları ile ilgili olarak görünüşte yetkin bir sistem yöneticisi ile tartışan bir biyolog olmak! (hiçbir suç, sadece gerçekten neden senin sysadmin güvenmiyorsun merak).

Yani, birkaç gözlem:

  • 1,3 TB artık büyük bir sürücü değil. 2 TB, bugünlerde masaüstü dünyasında daha az veya çok standart bir SATA sürücü boyutu.

  • herhangi bir Linux Distro'nun kurulumunun 100 GB'den daha fazla bir süreye ihtiyacı yoktur. Kesinlikle, / (root) ve (swap) için büyüklük, bunları (root için) veya sistem yapılandırma yönergelerine (swap) büyük ölçüde aşırı boyutlandırılarak üst sınırlanmış sayılar olarak kolayca belirlenmelidir.

  • / home için bağlama noktası, 40TB RAID sunucunuzda bir şey işaret etmelidir. Bu veriye, kullanıcıların ana dizinlerine, bu kök cihazda herhangi bir yere gerek duyulmasına gerek yoktur. Bunları RAID sunucusuna koymak muhtemelen daha iyi koruma sağlar. Ve, büyük olasılıkla kolayca genişletilebilir bir NAS tesisi, sunucu kutusu içine inşa edilen küçük RAID muhtemelen değil.

  • muhtemelen özel yazılımınızı ayrı bir bölüme (/ usr / local / bin vb. için montaj noktası) koymalısınız, böylece bunu işletim sistemi güncellemeleri ve kök bölüm silme bezleri arasında koruyabilirsiniz. Aksi takdirde, "özel" yazılım uygulamalarınızı bir işletim sistemi yükseltmesi / düzeltmesi / herhangi bir şeyden sonra yeniden yüklemeniz olasılığından dolayı karşı karşıyasınız.

  • Sisteminizin yönetimi hakkında endişelenmek isterseniz, farklı bir soru sormak istiyorum: Bina yangını yakaladıktan sonra felaket kurtarma süreci nedir ve sunucular ve RAID kutuları yok edilir mi? İlgilendiğiniz veriler tamamen kafanızda kalmıyorsa, bu her kullanıcının kendi IT / sysadmin milletlerinden sorması gereken bir sorudur. Strateji, "ihtiyacımız olan donanımı nasıl çoğaltacağız" ve "geri dönüp koşabilmemiz için ne kadar zaman alacağı" gibi soruları içermelidir. Sunucularınızı sanallaştırma ile ilgili bazı tartışmalar, donanım bağımlılıkları ile ilgili sorunları çözmenize yardımcı olabilir ve işletim sisteminizi yeniden yapılandırmanıza gerek kalmadan bazı şeyleri yedekleyip çalıştırmaya yardımcı olabilir (çünkü "yumuşak" bir aygıt ortamında çalışacak şekilde yapılandırılabilir. temel donanım tamamen farklıdır)

  • Benzer şekilde, kullanıcı verilerini programa ve kullanıcı hatası veri kayıplarına karşı korumak için stratejinin ne olduğunu sormak isteyebilirsiniz. Boş bir dosyayı araştırma kağıdınızın gerçekten büyük taslağı üzerinden kaydetmek veya yanlış komut yazarak bir kullanıcıya sahip olmak (örneğin rm -rf *), bir deprem veya yangın veya diğer fiziksel hasarlar kadar veri kaybına neden olacaktır. Bireysel dosya kurtarma için çözümler toptan felaket kurtarma için en yararlı olanlardan biraz farklı (veya olabilir!).

  • -

2
2017-09-23 13:10





Bu, işletim sistemini kullanıcı verisinden bağımsız olarak yedeklemeyi, geri yüklemeyi veya yeniden yüklemeyi sağlar. Bu size özgürlük, bağımsızlık ve güvenlik sağlar.

  1. Kullanıcı verilerinin mutlak çoğunluğunu koruyan başka bir Linux dağıtımına geçmek çok daha kolaydır.

  2. İşletim sistemi bölümünün yedeklemesini uygulayarak buggy güncellemelerini geri almak kolaydır (ikili önyükleme gereklidir). Bu yedekleme oldukça eski olabilir - uygulayabilir ve daha sonra bilerek kararlı sürümüne güncelleyebilirsiniz.

  3. Son zamanlarda uygulanan "büyük yükseltme" yi (çift önyükleme gereklidir) beğenmezseniz, işletim sisteminin önceki sürümüne dönmek basittir.

Bu yaklaşımın en büyük potansiyeli için, çift önyüklemeyi de yapılandırmanız gerekir (ayrıca CentOS / CentOS da olabilir), böylece işletim sistemini bir başkasından çalıştırırken bir işletim sistemi bölümünün üzerine yazabilirsiniz. Ve elbette, sistem bölümünü en az birkaç ayda bir yedeklemelisiniz.


2
2017-09-18 11:13



Ve neden -1? Hata düzeltmesi için kablosuz olmadan daha profesyonel bir yaklaşım olarak bekler misiniz? Üç hafta içinde BTW yandı. - h22
Bilmiyorum ama telafi edildi. Benzer bir şey görürseniz, bunu da yapın. - peterh