Le meilleur moyen d'empêcher le système racine de se remplir en cas d'échec d'un montage?

Nous avons un serveur Web interne (virtualisé, hébergeant ReviewBoard, mais pas super pertinent) et nous avons un mode de défaillance relativement cohérent avec des montages NFS défaillants provoquant / à se remplir. Distro est Ubuntu (ne demandez pas) si une solution dépend d'une distribution différente, elle sera plus lente à implémenter.

Des sauvegardes sont effectuées dans / mnt / backup /, qui est censé être monté sur NFS sur un autre système. Malheureusement, lorsque le montage échoue ou tombe, les sauvegardes sont effectuées sur le système de fichiers racine, ce qui, comme vous pouvez l'imaginer, ne prend pas longtemps avant / est complet, puis les services commencent à échouer.

Un certain nombre de solutions possibles ont été discutées.

1. Surveillez / mnt / backups et assurez-vous que ce n'est pas root. Peut-être un travail cron.

2. Utilisez / mnt / protected / backups, et montez / protégé d'abord sur un petit système de fichiers, peut-être un montage en boucle sur un fichier local, il est donc beaucoup moins susceptible d'échouer.

3. Chmod a-rwx / mnt / backups (le point de montage du système de fichiers racine). Je ne sais pas si le montage sur un directeur protégé fonctionnera, je pense que oui.

4. Dans l'arborescence montée, créez un répertoire appelé "Sauvegardes", puis un lien logiciel "ln - s / mnt / backup / Backups / Backups". L'utilisation de / Backups pour les sauvegardes échouera sauf si / mnt / backup est monté, car l'arborescence locale ne contient pas le sous-répertoire.

5. Vérifier que le répertoire est correctement monté dans le script de sauvegarde.

Je suis intéressé par tout commentaire sur ces approches, les inconvénients ou toute technique supplémentaire que les gens utilisent comme moyen standard de protéger le système de fichiers racine de ce type de méchanceté.

Numéro 5 - Mettez un test dans votre script de sauvegarde pour vous assurer que le répertoire est monté avant de continuer. Le script doit échouer si le montage n'est pas disponible ou présent. Ou vous pouvez simplement vous assurer que les éléments sont montés avant d'exécuter la sauvegarde.

Essayez la mountpointcommande, qui vérifie si un répertoire spécifié est un point de montage:

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

La solution la plus sûre est de rendre le point de montage non accessible en écriture. Ce serait votre solution # 3. Cependant, vous devez effectuer une étape supplémentaire. chattr +i /mnt/backups. En effet, même sans autorisation, root serait toujours en mesure d'écrire dans le répertoire. Avec chattr +i(définit le drapeau immuable), même root ne peut pas y écrire. Une fois le montage monté, les autorisations n'ont plus d'importance car les autorisations seront du répertoire distant, pas du répertoire local.

Quel ewwhite a dit. De plus, une surveillance supplémentaire de l'intégrité du système de base ne serait pas une mauvaise idée.

Quelque chose comme Monit peut vérifier l'espace restant . Si vous voulez vous lancer dans la surveillance du système, vous pouvez regarder Nagios, mais Monit est léger et fera les bases.

Puisque vous utilisez Ubuntu, Monit est déjà dans le référentiel, vous pouvez donc faire "sudo apt-get install monit", puis commencez à regarder les fichiers de configuration pour lui dire d'envoyer des alertes au bon endroit, de surveiller les bons services, etc. Voici un petit tutoriel .

Voici une doublure que vous pouvez exécuter en tant que tâche cron, elle suppose que le montage en question est dans fstab:

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

Pour une solution à plus long terme: je ne sais pas comment faire cela sur Ubuntu (je suis centré sur RH) ou si cela en vaut la peine (si vous n'avez qu'une seule machine) mais une méthodologie qui a fonctionné pour nous pendant de nombreuses années consiste à créer des logiques distinctes les volumes, les systèmes de fichiers et même les groupes de volumes sur les machines serveurs. Donc, dans la pratique courante, nous créons des volumes logiques LVM pour /, / tmp. / usr, / usr / local, / opt, / home, / var, swap space et une partition séparée pour / boot. Cette approche rend les systèmes de fichiers très difficiles à remplir et à désactiver. En fait, cette approche rendra presque impossible de remplir le système / file. Vous devez toujours regarder / tmp, / var bien sûr. Si nous devons héberger des données, nous créons un groupe de volumes totalement différent pour elles. Cette approche présente également d'autres avantages: étendre les systèmes de fichiers à volonté, les déplacer, en créer de nouveaux, etc.