Najlepszy sposób, aby zapobiec zapełnieniu systemu root w przypadku niepowodzenia montowania?


16

Mamy wewnętrzny serwer WWW (zwirtualizowany, hostujący tablicę ReviewBoard, ale niezbyt odpowiedni) i mamy stosunkowo spójny tryb awarii z nieudanymi montowaniami NFS powodującymi / wypełniającymi się. Distro to Ubuntu (nie pytaj) jeśli rozwiązanie zależy od innej dystrybucji, wdrożenie będzie wolniejsze.

Kopie zapasowe są wykonywane w / mnt / backup /, który ma być zamontowany w systemie plików NFS w innym systemie. Niestety, gdy podłączenie nie powiedzie się lub spadnie, kopie zapasowe są wykonywane w głównym systemie plików, co, jak można sobie wyobrazić, nie trwa długo, zanim / zostanie zapełnione, a następnie usługi zaczną się nie powieść.

Omówiono szereg możliwych rozwiązań.

  1. Monitoruj / mnt / kopie zapasowe i upewnij się, że nie jest to root. Być może praca crona.

  2. Użyj / mnt / protected / backups i najpierw zamontuj / chronione w małym systemie plików, być może w pętli do pliku lokalnego, więc prawdopodobieństwo niepowodzenia jest znacznie mniejsze.

  3. Chmod a-rwx / mnt / backups (punkt montowania głównego systemu plików). Nie jestem pewien, czy montaż nad chronionym reżyserem zadziała, myślę, że tak.

  4. Na zamontowanym drzewie utwórz katalog o nazwie „Kopie zapasowe”, a następnie miękkie łącze „ln - s / mnt / backup / Backups / Backups”. Użycie / Backups do tworzenia kopii zapasowych zakończy się niepowodzeniem, chyba że zostanie zamontowane / mnt / backup, ponieważ lokalne drzewo nie zawiera podkatalogu.

  5. Sprawdzanie, czy katalog jest poprawnie zamontowany w skrypcie kopii zapasowej.

Interesuje mnie informacja zwrotna na temat tych podejść, zalet i innych technik stosowanych przez ludzi jako standardowy sposób ochrony systemu plików root przed tego rodzaju nieprzyjemnością.

Odpowiedzi:


13

Numer 5 - Przeprowadź test w skrypcie kopii zapasowej, aby upewnić się, że katalog jest podłączony przed kontynuowaniem. Skrypt powinien zakończyć się niepowodzeniem, jeśli mount nie jest dostępny lub obecny. Możesz też upewnić się, że wszystko jest zamontowane przed uruchomieniem kopii zapasowej.

Wypróbuj mountpointpolecenie, które sprawdza, czy określony katalog jest punktem montowania:

mountpoint -q /mnt/backups || mount /mnt/backups


Hmm, chyba dodam || echo „Błąd montowania / mnt / kopii zapasowych nie powiódł się” 2> i 1 Lub może po prostu tam istnieją. W każdym razie dzięki !!!
Peter

22

Najbardziej odpornym na błędy rozwiązaniem jest uczynienie punktu montowania niezauważalnym. To byłoby twoje rozwiązanie nr 3. Jest jednak jeden dodatkowy krok, który należy wykonać. chattr +i /mnt/backups. Dzieje się tak, ponieważ nawet bez uprawnień root nadal mógłby zapisywać do katalogu. Dzięki chattr +i(ustawia niezmienną flagę) nawet root nie może do niej pisać. Po zamontowaniu montowania uprawnienia nie mają znaczenia, ponieważ będą dotyczyły katalogu zdalnego, a nie lokalnego.


1
To całkiem fajna sztuczka - nigdy nie myślałem o użyciu „chattr”
warren

1
Używam tej techniki na wszystkich moich punktach montażu.
3dinfluence,

1
Próbowałem tego z encfssystemem plików bezpieczników. Daje błąd:fusermount: user has no write access to mountpoint
ctrl-alt-delor

Jest to rozwiązanie, którego zwykle używam i myślę, że powinna to być zaakceptowana odpowiedź.
shodanshok

3

Co powiedział ewwhite. Ponadto dodatkowe monitorowanie stanu podstawowego systemu nie byłoby złym pomysłem.

Coś takiego jak Monit może sprawdzić, ile pozostało miejsca . Jeśli chcesz się nudzić przy monitorowaniu systemu, możesz spojrzeć na Nagios, ale Monit jest lekki i zrobi podstawy.

Ponieważ używasz Ubuntu, Monit jest już w repozytorium, więc możesz zrobić „sudo apt-get install monit”, a następnie zacząć przeglądać pliki konfiguracyjne, aby poinformować go, aby wysyłał alerty we właściwe miejsce, monitorował właściwe usługi itp. Oto krótki samouczek .


1

Oto jedna linijka, którą możesz uruchomić jako zadanie crona, przy założeniu, że dany mount jest w fstab:

if mountpoint -q /mnt ; then : ; else mount /mnt ; fi

0

W przypadku rozwiązania długoterminowego: Nie jestem pewien, jak to zrobić na Ubuntu (jestem RH zorientowany) lub czy warto (jeśli masz tylko jedną maszynę), ale metodologią, która działała dla nas przez WIELE lat, jest stworzenie osobnej logiki woluminy, systemy plików, a nawet grupy woluminów na serwerach. Tak więc zgodnie ze standardową praktyką tworzymy woluminy logiczne LVM dla /, / tmp. / usr, / usr / local, / opt, / home, / var, przestrzeń wymiany i osobna partycja dla / boot. Takie podejście bardzo utrudnia systemom plików wypełnienie i wyłączenie systemu. W rzeczywistości takie podejście prawie uniemożliwi wypełnienie systemu plików /. Nadal musisz oglądać / tmp, / var oczywiście. Jeśli potrzebujemy przechowywać dane, tworzymy dla nich zupełnie inną grupę woluminów. Takie podejście ma również inne zalety, dowolne rozszerzanie systemów plików, przenoszenie ich, tworzenie nowych itp.


Więc twoim rozwiązaniem zapobiegającym zapełnieniu systemu plików w przypadku niepowodzenia montowania jest dodanie większej liczby montowań? Co?
Patrick
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.