le jour où le gus a perdu le contenu de /repertoireimprobable,
"/repertoireimprobable" n'est pas sur le contrat de sauvegarde, qu'il assume ses propres conneries.
ça ne marche que si tu as l'appui de ta direction sur ce point. Ce n'est pas toujours le cas.
C'est d'ailleurs la même chose pour le principe des backups systèmes. Si la direction les veut et n'accepte pas tes arguments, tu les fais quand même. Et au final, ce n'est pas très dommageable parce que :
-la déduplication, ça existe et est maintenant très utilisé : le calcul dans ton post initial est du coup complètement foireux.
-le volume des système doit pas dépasser 2 à 3% du volume des backups. Donc au final, que ce soit sur un plan comptable ou au niveau de l'infrastructure, c'est négligeable.
Dernier point, dans plein de boites où le nombre de serveurs est important >500 je dirais, le travail d'administration système est scindés en plein d'équipes différentes. Ce ne sont pas forcément les mêmes qui gèrent la configuration des serveurs et la politique de backup. Et comme chacun le sait plus la boite est grosse plus c'est le bordel pour que les gens s'entendent et s'accordent sur beaucoup de sujets.
Un dernier point est le problème de gestion des exceptions. Si tu dois avoir une politique de sauvegarde pour les serveurs "standards" bien gérés selon les best practices (pas de changements manuels sur les serveurs, uniquement de la gestion de config, pas de droits admins aux utilisateurs tiers, etc) et une autre pour les serveurs "dégueux", tu as toujours le risque d'en avoir un qui a été mis dans la mauvaise case (parce que oubli, parce que mauvaise information, etc) et que du coup tu te trouves dans la merde un jour. Des fois c'est plus simple et moins dangereux de faire du "bête et méchant" partout que de devoir gérer 1000 exceptions.
Bref je comprends tes arguments, mais ce n'est pas toujours applicable ni du ressors du sysadmin.
[^] # Re: Tout dépend des postes
Posté par Psychofox (Mastodon) . En réponse au journal Les sauvegardes, et les logiciels de sauvegarde. Évalué à 7.
ça ne marche que si tu as l'appui de ta direction sur ce point. Ce n'est pas toujours le cas.
C'est d'ailleurs la même chose pour le principe des backups systèmes. Si la direction les veut et n'accepte pas tes arguments, tu les fais quand même. Et au final, ce n'est pas très dommageable parce que :
-la déduplication, ça existe et est maintenant très utilisé : le calcul dans ton post initial est du coup complètement foireux.
-le volume des système doit pas dépasser 2 à 3% du volume des backups. Donc au final, que ce soit sur un plan comptable ou au niveau de l'infrastructure, c'est négligeable.
Dernier point, dans plein de boites où le nombre de serveurs est important >500 je dirais, le travail d'administration système est scindés en plein d'équipes différentes. Ce ne sont pas forcément les mêmes qui gèrent la configuration des serveurs et la politique de backup. Et comme chacun le sait plus la boite est grosse plus c'est le bordel pour que les gens s'entendent et s'accordent sur beaucoup de sujets.
Un dernier point est le problème de gestion des exceptions. Si tu dois avoir une politique de sauvegarde pour les serveurs "standards" bien gérés selon les best practices (pas de changements manuels sur les serveurs, uniquement de la gestion de config, pas de droits admins aux utilisateurs tiers, etc) et une autre pour les serveurs "dégueux", tu as toujours le risque d'en avoir un qui a été mis dans la mauvaise case (parce que oubli, parce que mauvaise information, etc) et que du coup tu te trouves dans la merde un jour. Des fois c'est plus simple et moins dangereux de faire du "bête et méchant" partout que de devoir gérer 1000 exceptions.
Bref je comprends tes arguments, mais ce n'est pas toujours applicable ni du ressors du sysadmin.