Comme rm -rf / ? Une histoire à nous partager peut-être ?

Ouais, un jour, j'ai fait un truc genre :
Et j'ai viré le projet au lieu de vider le cache

D'où le fait de se faire une commande : r par exemple, qui mv les fichiers vers /Trashes (par exemple) .

C'est surtout que maintenant, je fait un halt avant chaque rm, pour bien prendre le temps de visualiser ce que je vais virer.

C'est surtout que maintenant, je fait un halt avant chaque rm, pour bien prendre le temps de visualiser ce que je vais virer.

Et encore c'était que le projet que tu as virer ça nous est bien arriver au moins une fois de faire un rm -rf à un endroit ou se trouve certains fichiers "primordiales". Non ?

Ah j'avoue que j'ai jamais supprimé des ressources vitales, mais pas loins puisque qu'un jour j'ai lancé un cp sur / au lieu de ./

bon, on clos la partie nostalgie , personne à une idée ?

Par avance merci de votre aide

Je réponds tout de suite, je réagirais plus tard : Et ensuite tu redémarres apache.

killall n'éxistait pas, killall5 oui, malheureusement :

# /usr/local/bin/httpd -k start
httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName
(98)Address already in use: make_sock: could not bind to address [::]:80
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs

J'ai dût mal le configurer.

Mon fichier de compilation : Voilà, par avance, merci de votre aide

PS : Si ça peut aider, apt ne peut plus rien installer par un
soit disant manque de place même après clean et auotclean
et le message personnalisé d'OpenSSH à disparut,
si ça peut vous aider...

T'as compilé apache ? Pour quelle raison ?

Euh, killall5 te donnait quel résultat ?

Fait un et poste le résultat

D'où le fait de se faire une commande : r par exemple, qui mv les fichiers vers /Trashes (par exemple) .

C'est surtout que maintenant, je fait un halt avant chaque rm, pour bien prendre le temps de visualiser ce que je vais virer.

Il y a des techniques qui permettent en effet de limiter les erreurs, vous auriez pu citer l'alias rm = rm -i. Mais toutes ces techniques sont humainement faillibles. Si on utilise souvent la commande, on prendra peu à peu l'habitude :
Pour HyWaN : Pour zeus : Tout comme moi j'ai l'habitude de faire : On prend des automatismes à force, et on se rend compte juste après qu'on a fait une connerie.
La véritable sécurité n'est pas dans une sécurité faillible humainement, mais dans une sécurité automatique : le backup.
C'est vraiment le plus important, c'est même capital. Un pc ou un serveur peut cramer, le coût matériel sera quasiment systématiquement négligeable par rapport au coût inhérent à la perte des données. C'est vrai même dans un cadre personnel. Donc : On fait une sauvegarde automatique et "versionnée" (c'est à dire qu'une sauvegarde n'écrase jamais la précédente).
Quand on fait un backup sérieux, on peut faire tous les rm -rf que l'on veut, on ne perdra jamais que quelques heures de travail.

En plus t'es loggué en root...

Bah, pour prendre sa défense, il y a pas mal de distributions (surtout les distributions qui demandent un haut niveau de connaissance) pour lequelles le compte root est activé de base. C'est pareil pour les hébergeurs. On te donne le mot de passe du compte root, pas d'un compte admin. Et les débutants n'ont pas le réflexe d'installer sudo et de désactiver le compte root.

PS : en plus j'ai mis testdisk ^^

Euh, si tu fais un rm -rf /, ton testdisk tu vas avoir du mal à le lancer…

On prend des automatismes à force, et on se rend compte juste après qu'on a fait une connerie.
La véritable sécurité n'est pas dans une sécurité faillible humainement, mais dans une sécurité automatique : le backup.
C'est vraiment le plus important, c'est même capital. Un pc ou un serveur peut cramer, le coût matériel sera quasiment systématiquement négligeable par rapport au coût inhérent à la perte des données. C'est vrai même dans un cadre personnel. Donc : On fait une sauvegarde automatique et "versionnée" (c'est à dire qu'une sauvegarde n'écrase jamais la précédente).
Quand on fait un backup sérieux, on peut faire tous les rm -rf que l'on veut, on ne perdra jamais que quelques heures de travail.

Entièrement d'accord.
Et c'est pour ça que j'en parle aussi aujourd'hui comme ça.

C'est que sur le coup, tu as un "merdmerdmerdmerd".
Puis tu souffles, tu cherches la sauvegarde, extract selectif, copie, affichage du site et ... pfiouuuuuu, soulagement

C'est que sur le coup, tu as un "merdmerdmerdmerd".
Puis tu souffles, tu cherches la sauvegarde, extract selectif, copie, affichage du site et ... pfiouuuuuu, soulagement

Ouais
Ou alors t'as pas de chance, t'as perdu ta sauvegarde en même temps, et t'arrête le serveur / pc en urgence pour pas que tes données soient écrasées

Je ne sais pas les précos de sauvegardes que tu utilises, mais pour ma part, j'ai toujours, en local et sur un serveur distant, une sauvegarde de 4 derniers jours par applicatifs, puis celle du dernier jour du mois précédent pour le serveur complet.

En ce qui concerne notre architecture de dev, on rajoute même une sauvegarde sur un serveur qui ne se situe pas dans les mêmes locaux, histoire d'éviter les catastrophes naturelles ou les cambriolages.

Je ne sais pas les précos de sauvegardes que tu utilises, mais pour ma part, j'ai toujours, en local et sur un serveur distant, une sauvegarde de 4 derniers jours par applicatifs, puis celle du dernier jour du mois précédent pour le serveur complet.

Bah justement on a pas les capacités techniques pour l'instant pour faire de sauvegarde (ouais, je ne regarde pas la poutre qu'il y a dans mon oeil). C'est un problème critique que je suis content de pouvoir régler dans les prochaines semaines.
Après concernant la politique de sauvegarde, tout dépend de la perte que l'on accepte. Quand j'avais une sauvegarde, par exemple, je sauvegardais les mails toutes les 10 minutes. Par contre la sauvegarde en local, je trouve que c'est pas réellement utile en fait (sauf si elle est sur un autre disque dur);

En ce qui concerne notre architecture de dev, on rajoute même une sauvegarde sur un serveur qui ne se situe pas dans les mêmes locaux, histoire d'éviter les catastrophes naturelles ou les cambriolages.

Normal, je prend justement l'habitude de demander où se situent les locaux de chacun de mes hébergeurs (dont la sauvegarde) Pour l'instant, à notre niveau, on peut accepter le risque de garder la sauvegarde dans le même datacenter que le serveur (pour l'hébergement que nous allons prendre), mais on aura peut être d'autres exigences à terme.
Bah là, rien à redire, si vous perdez vos données, c'est que vous avez pas de chance.

Les sauvegardes en local, c'est pour etre capable de rétablir rapidement un applicatif après déterioration (humaine ou via l'appli)