Plantons le décor. La fin de contrat dans un data center approche. Il faut déménager les services ailleurs. On prend les devants et on cherche un autre, pas trop cher pour y mettre notre machine. C'est pas gagné :-/ Finalement on va squatter chez une bonne âme pour tout ce qui est dev et asso. Pour le pro (rien pour le moment) on y mettra les frais et on se payera un truc en temps voulu.
On prend tout notre temps. On devrait être prévenus quand ce sera le moment de faire le ménage et de rendre les clefs. On migre les sites, les services et tout et tout. Un simple
rsyncà la fin devrait suffire pour la synchro finale des machines.
Driiiiiing ! Coup de téléphone doublé d'un mail : c'est demain que ça coupe. On n'a plus trop le temps de faire le rsync, d'autant qu'on n'a plus des masses d'espace sur la nouvelle machine. Faut trancher dans le vif ! Tiens les bases de données mysql de type InnoDB ne peuvent que grossir. On essaye de suivre la procédure pour limiter la casse décrite sur le blog de crazytoon [1]. Tout roule... sauf que mysql veut plus se lancer. Bon, pas trop grave pour le moment, vu que les données sont bien sagement rapatriées dans le /tmp de la nouvelle machine. Attention, vous venez de lire un élément important.
On galère, on cherche et au final on trouve. Peut-être un problème de quotas sur la nouvelle machine, peut-être aussi un problème d'options de mysql lors du mysql_install_db. Bref on peut maintenant importer les données. Sauf que les données, elles sont plus là :(( Un reboot intermédiaire a fait le ménage dans /tmp. Pas grave, on refait une copie du fichier depuis l'ancienne machine et ça devrait marcher. Sauf que ça marche pas : la machine est down. Murphy's law diront certains. Qu'on y croit ou pas, en tous cas, ça fait bien suer (je pensais à un autre mot, je l'avoue) !
Acte trois, téléphone de droite et de gauche pour accéder à la machine. "Pas moyen", elle est prise en otage car la société qui payait l'espace dans la baie ne payait plus, et ce depuis quelques mois ! Douche froide... et on est réduit à se demander : on paye et on récupère nos données, ou on cherche un backup en attendant que la situation se règle toute seule. Faute de moyen, ce sera la solution 2. Mais pour le coup, le backup le plus récent (en fait le seul que j'ai pu retrouver) datait de fin 2006.
Mine de rien, en subissant une migration foirée, on a inventé la machine à remonter le temps !
[1]http://crazytoon.com/2007/04/03/mysql-ibdata-files-do-not-sh(...)
# Backup backup backup !!!
Posté par IsNotGood . Évalué à 10.
En passant, il faut être un peu con (désolé) pour mettre les backups dans /tmp...
Je fais les backups (dumps) toutes les nuits + un logrotate. Comme ça je peux récupérer la base de données de la semaine passée si nécessaire.
[^] # Re: Backup backup backup !!!
Posté par Florent Peyraud (site web personnel) . Évalué à 6.
C'était juste pas un backup, mais seulement un dump pour importer direct derrière, le genre de fichier qu'il faut pas oublier d'effacer car il pèse 2 tonne et qu'il servira plus dans 3h de temps, d'où le stockage dans /tmp...
je le ferai plus comme ça la prochaine fois ! Merci :)
[^] # Re: Backup backup backup !!!
Posté par IsNotGood . Évalué à 2.
[^] # Re: Backup backup backup !!!
Posté par ccomb (site web personnel) . Évalué à 3.
C'est après le reboot que je réalise que ce que j'avais ouvert, c'est un fichier placé par firefox dans /tmp. Et paf la trad.
[^] # Re: Backup backup backup !!!
Posté par IsNotGood . Évalué à 3.
Dans le genre con, j'ai fait un truc fabuleux. C'était il y a longtemps.
J'avais un disque qui déconnait. Je regarde vite fait la commande badblocks. Dans un terminal je lance "badblocks -w ...". Dans un autre je continu de lire la man page badblock. Vers la fin il est indique que "-w" efface tout ...
NB: ce n'est plus cas aujourd'hui.
Une autre boulette que j'ai faite (et qui n'est peut-être plus possible).
Je ne regardais pas bien ce que je faisais et fais un "put *" (et non "mput *") dans un client ftp.
Plus tard sur la bécane de destination du ftp, je vois le fichier "*". Ben je tape "rm *".
[^] # Re: Backup backup backup !!!
Posté par Christophe HENRY (site web personnel) . Évalué à 1.
>NB: ce n'est plus cas aujourd'hui.
C'est toujours le cas. -n fait bien la même chose sans effacer mais -w écrase tout.
[^] # Re: Backup backup backup !!!
Posté par Thomas Douillard . Évalué à 2.
( -->[] ;) ... [balise blague] )
# A envoyer à ...
Posté par Prae . Évalué à 5.
# De la nécessité de tester les sauvegardes
Posté par Raphaël SurcouF (site web personnel) . Évalué à 7.
Par contre, ton expérience semble surtout démontrer la négligence des personnes chargées des contrats d'hébergement : prévenir la veille, c'est beaucoup trop tard. Évidemment, si la date de fin de contrat était précisément le lendemain, c'est que vous aviez pris trop de temps pour vous préparer.
Par contre, ça n'explique pas pourquoi le loyer n'était plus payé depuis des mois. Parfois, l'informatique n'est pas qu'une question de technologies et il faut que tout le monde coopère et partage les informations (oui, un admin a besoin de savoir quand un contrat d'hébergement se termine, si, si).
[^] # Re: De la nécessité de tester les sauvegardes
Posté par Mouns (site web personnel) . Évalué à 2.
1bit de modifié sur un tgz, et c'est le tgz qui est bon pour la poubelle.
1bit sur une image FS, ca se récupère plus facilement.
donc ne jamais faire des fichiers tar et encore moins de tar.gz pour de la sauvegarde !
le tar ne doit être utilisé que comme outil qui à l'origine archivait sur bande ... donc avec un lecteur de bande.
sur un disque, rsync c'est très bien ( par contre, je ne sais pas si il existe une FS avec systeme de correction d'erreur pour l'intégrité des données - genre backupFS et non e2fs over RAID )
Au pire, tu prend un MACOS X léopard avec time-machine + time capsule ( pas de truc équivalent au niveau backup en libre ).
http://www.apple.com/fr/timecapsule/
[^] # Re: De la nécessité de tester les sauvegardes
Posté par kowalsky . Évalué à 3.
donc ne jamais faire des fichiers tar et encore moins de tar.gz pour de la sauvegarde !
le tar ne doit être utilisé que comme outil qui à l'origine archivait sur bande ... donc avec un lecteur de bande.
Pourquoi on utilise ça partout sur le net pour diffuser sur le net
des sources ?
[^] # Re: De la nécessité de tester les sauvegardes
Posté par Ellendhel (site web personnel) . Évalué à 2.
À partir de là, on peut vérifier la validité du fichier et éviter des problèmes de copie ou de support non fiable.
Bien évidemment, ce n'est pas forcément adaptable à tous les cas (en particulier pour les gros jeux de données où ces opérations vont prendre du temps).
[^] # Re: De la nécessité de tester les sauvegardes
Posté par Prae . Évalué à 4.
zip ?
rar ?
cat * > mongrosfichier ?
[^] # Re: De la nécessité de tester les sauvegardes
Posté par Benoît Ganne (site web personnel) . Évalué à 7.
Le problème des archives compressées (zip, tar.gz, tar.bz2, rar, ce que vous voulez) c'est que on élimine la redondance d'informations (au sens large), d'où la compression. Mais de ce fait c'est beaucoup plus sensible aux altérations.
Par exemple, mon super format de compression :
"aaaabccddd" est compressé en "4abcc3d"
Si dans la chaine originale je modifie le 2ème caractère "a" -> "e" on a "aeaabccddd"
Si c'est dans la chaine compressée, on obtient "4ebcc3d" et à la décompression, patatatra, ça empire, on obtient "eeeebccddd".
Dans un cas : 1 erreur, dans le second : 4 erreurs.
Bon mon exemple est bidon mais l'idée est là.
Le cas des archives tar (sans gzip, bzip2) est un peu différent, parce que ce n'est jamais que la concaténation des données telles quel avec quelques métadatas. Donc c'est assez robuste.
En gros si on stocke les fichiers tels quels sur un filesystem ailleurs, ce sera plus robuste aux altérations que l'archive .tar.gz/rar/... correspondante.
Par contre on perd beaucoup de place.
Donc sur le net on fait des tar.gz parce que ce qui importe c'est la bande passante alors que pour des sauvegardes, en générale c'est les données qui sont importantes.
[^] # Re: De la nécessité de tester les sauvegardes
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
Si l'on suit l'importance des données, tar n'est pas à remettre en cause.
Et il y encore beaucoup de lecteurs de bandes magnétiques utilisées pour la sauvegarde, les disques dur ne les ont pas encore remplacés.
[^] # Re: De la nécessité de tester les sauvegardes
Posté par Mouns (site web personnel) . Évalué à 5.
le tar ne doit être utilisé que comme outil qui à l'origine archivait sur bande ... donc avec un lecteur de bande.
je ne jette pas l'oprobe sur tar !
nous parlons de sauvegarde, et tar rend service sur un lecteur de bande pas sur un disque !
le format tar.gz est un détournement de l'usage originel de tar ( un peu comme cliquer sur "démarrer" pour éteindre son windows :p )
un des critères les plus important d'une sauvegarde est la fiabilité d'une information.
je parle de cela.
Compresser une information dans le but de sauvegarde est pire que ne pas faire de sauvegarde.
Pourquoi je parle de cela ? parce que les problèmes nécessitant une sauvegarde sont :
- risque de corruption des données
- risque de perte des données
- risque d'indisponibilité partielle ou totale des données ( hard cassé )
Donc une sauvegarde doit garantir :
- une étanchéité vis à vis du support = support un peu défaillant, données lisibles
- une étanchéité vis à vis du format = format plus ou moins corrompu, format quand meme exploitable
- une étanchéité vis à vis des outils = le soft de restitution est out, il faut pouvoir retablir
- une étanchéité vis à vis de l'accessibilité = il faut pouvoir vérifier rapidement l'intégrité du support, du format, des outils de restitution
Donc :
A. il ne faut pas stocker dans un format compressé.
L'exemple du RLE était parfait pour comprendre.
sur un algorithme de la famille des LZ qui est à dictionnaire dynamique ( cas de compress, zip, gzip & co ), une erreur de reconstitution du dictionnaire produit un arret de l'algorithme donc tout est perdu après l'erreur
B. il faut un format le plus proche du format natif
le mieux pour sauvegarder des données SQL est un fichier texte contenant des INSERT.
le mieux pour un fichier HTML est HTML.
le mieux pour un binaire, c'est le binaire lui meme et ses sources.
un binarydump des tables ou une copie à chaud des tables, introduit un risque d'erreur indetectabe. on peut détecter une erreur de charset ( en UTF16 ou UTF32 ) d'un fichier texte, pas une erreur dans un binaire sans un parser pour chaque format.
C. il faut que le support ( logique ou/et physique ) offre une redondance des données
souvenir souvenir, les lignes séries, les bits de terminaison, les sommes de controles & co ...
on envoyait plus d'info sur une liaison de type série longue distance, ce qui induisait un debit effectif largement inférieur au débit réel : pour éviter de rejouer l'ensemble d'une communication, il était préférable de pouvoir détecter les séquences à problèmes et les corriger automatiquement et d'envoyer un signal d'erreur pour qu'il rejoue la fenetre de séquence.
Au niveau du support logique et physique, il faut la même chose :
- des sommes de contrôles non pas sur un tar ou une iso, mais sur chaque fichier de l'iso ou du tar
- pouvoir automatiser les corrections les plus fréquentes ( plusieurs fois 1 bits unique dans un bloc signé )
D. l'outil doit s'assurer qu'il sauvegarde bien ce qu'il doit sauvegader
Sur une sauvegarde, il faut que le support physique puisse offrir une redondance exploitable mais il faut aussi que l'outil de sauvegarde ( le cas de rsync me semble t il moyennant le mode batch et checksum ) puisse garantir que ce qui a été copié est bien ce qui devait être copié ( comparaison post copie ).
Sur une FS subissant beaucoup d'ecriture, un LVM snapshot sera nécessaire au préalable après s'être assuré du lock de la FS pour sauvegarder un état sans écriture en cours.
Conclusion :
un tar + gz + ftp ( ou autre ) n'offre pas la même garantie au niveau sauvegarde que ce dont je parle.
Si c'est pour sauvegarder ses photos de voyage, un tgz sur cd gravé est parfait.
Si c'est des données d'une entreprise, il faut s'assurer que ce qui est fait est bien fait, et il faut donc vérifier/Tester ( et je rejoins celui à qui je répondais ).
mais vérifier 1 sauvegarde, ne fait que vérifier 1 sauvegarde au moment de la vérification, cela n'offre aucune garantie qu'au bout de 1 semaine les données sont toujours exploitable ... c'est un pari sur une croyance pas un fait garanti.
La sauvegarde ne s'improvise pas ... et les bons outils de sauvegardes libres sont très rare, et ceux qui sont simple à mettre en oeuvre, sont inexistant.
Donc je maintiens, si la time machine d'apple n'est pas parfaite, elle doit servir de modèle.
[^] # Re: De la nécessité de tester les sauvegardes
Posté par IsNotGood . Évalué à 2.
Oui.
Mais j'ai l'impression que tu es limite dans un délire. Tu peux faire des checksum, mais à dans ce cas de parano, il faut aussi auditer les outils qui font les dumps, etc...
Le tar.gz c'est bien. Ce n'est pas parfait, mais c'est bien. S'il manque un 1 bit, gzip et tar savent gérer ça. Mais OK, tu perds plus d'un 1 bit.
Notons que tous les archivages vidéo sont en compressé... Sinon c'est impossible.
Autre avantage de tar, il stocke les informations du système de fichier. Comment tu fais pour sauvegarder les droit rwxrwxrwx sur Windows ? Comment tu fais pour sauvegarder les propriétaires si tu n'as accès qu'à un compte sur le serveur de backup ? Comment tu fais si tu as les fichiers TOTO et toto et le serveur de backup est Windows ?
On ne devrait pas parler d'un backup mais de plusieurs backups. Car il faut toujours au moins deux backups (sur deux bécanes différentes ou qu'une bécane mais archiver les bandes dans des lieux différents).
Enfin il faut mettre dans le contexte. Pour un serveur, je fais des sauvegardes en cpiio.gz, dump de base de données, etc. Je gardes sur 2 mois (10 backups fait la nuit et 10 backups fait le week). Mais surtout je m'impose de faire un test de restauration tous les mois ! Si je n'arrive pas à restaurer mon serveur rapidement, alors j'ai un problème dans mes procédures de backup/restauration. Que j'utilise du cpio.gz est accessaire. Évidemment, c'est pour mon cas particulier et d'autres cas demande d'autres procédures.
[^] # Re: De la nécessité de tester les sauvegardes
Posté par Mouns (site web personnel) . Évalué à 3.
http://en.wikipedia.org/wiki/Gzip ( http://www.ietf.org/rfc/rfc1952.txt pour le format ) algo http://en.wikipedia.org/wiki/DEFLATE ( mix de LZ77 et Huffman ) connu sous la RFC 1951 ( http://www.ietf.org/rfc/rfc1951.txt ).
donc en fait tu stockes dans un gzip, ton arbre de token via un arbre de huffman ( = le token le plus fréquent sera le plus court ), puis tes données sous forme de liste de token.
Donc, une erreur dans l'arbre de token, sur un token long est peu génant, une erreur sur un token court est grave.
Apres une erreur dans la liste des tokens est génante ... tu peux imaginer des sommes de controle sur ton block mais bof.
Du coté de tar, tu as l'option -t qui permet de verifier l'intégrité d'un tar. en cas de problème, le tar considère que tout le reste est foiré ... sauf bidouille assez infect dans le format tar, cela n'est pas top.
Donc sur ton tar.gz, il suffit d'une petite erreur ( facile à obtenir ), pour chier ton archive.
je n'appelle pas cela un format de sauvegarde, c'est bien pour un truc qui est "in the cloud" ( pour faire dans la hype actuelle - sinon pour faire dans le revival du film "antitrust", "la solution est dans la bande passante !" ).
un exemple avec tes photos argentiques :
tu entasses et presse au sers-join les negatifs et les photos ou tu les séparent proprement en isolant chacun de manière plus ou moins hermetique de l'humidité, de la lumière, de la poussière ?
dans un cas, ca prend moins de place et au moindre probleme tout par à la poubelle ... dans l'ordre, ca prend beaucoup plus de place mais au moins tu les conserve pendant très longtemps et si un negatif ou une photo à un probleme, c'est juste un petit probleme dans une immensité bien conservé.
[^] # Re: De la nécessité de tester les sauvegardes
Posté par IsNotGood . Évalué à 3.
Mais c'est comme ça pour tout !
T'as une merde dans le dump de base de donnée, et le dump peut être foiré. Et les dumps en pure SQL tu ne peux pas toujours les faires (sinon ça prend des prombe). T'as une merde dans l'outil qui fait le dump, et le dump est foiré. T'as un merde dans le SGBD, et le dump est foiré. T'as une merde dans le FS, et tous tes backups sont foireux, etc.
Mais pour une raison que j'ignore, tu fais une fixation sur tar et gzip.
Tu m'expliques ?
Je ne fais pas une fixation sur tar ou pg_dump ou autre. Je fais une fixation sur l'ensemble de la chaine. D'où l'importance de faire des restaures réguliers pour tester l'ensemble.
Un exemple de "petit problème". .Tes backups et dumps de base de données roulent nickel. Un l'admin fait une mise à jour de la base de donnée. Manque de chance, pour les dumps t'utilise une option qui n'est plus supportée. Bref, tes backups sont nazes.
Ou avec la nouvelle version de la base donnée, l'admin de la base de donnée utilise de nouvelle fonctionnalité qui sont sauvegardées que si tu utilises la nouvelle option "-z" de l'outils de dump de base. Mais comme cette option n'est pas activée...
Bref, ça peut merder à 50 endroits, alors pourquoi cette fixation sur tar ?
Et rsync peut aussi merder (ça m'est déjà arrivé).
[^] # Re: De la nécessité de tester les sauvegardes
Posté par IsNotGood . Évalué à 1.
Et j'ai aussi eu cpio qui merdait (et pas pour faire une archive, mais un cpio -p). Les droit et propriétaire des fichiers étaient perdus (ce qui est très casse couille).
[^] # Re: De la nécessité de tester les sauvegardes
Posté par Mouns (site web personnel) . Évalué à 6.
JE n'ai aucun problème particulier avec tar ou gzip :D
JE les utilise là où JE considère qu'ils satisfassent mes attentes.
par contre, JE expose MON opinion en disant "tar et gzip c'est bien pour certaines choses mais JE ne l'utilise pas au niveau backup disk pour diverses raisons"
Et quand une personne m'interpelle sur le pourquoi, j'expose plus précisement MES raison qui ME permettent de justifier MON opinion.
par contre TU as un problème de lecture du francais, TU sembles avoir une lecture orientée de MON propos.
Maintenant, si tu as des arguments au niveau algorithmique justifiant le fait que gzip est génial pour du backup ( je te rappelle que j'ai dit que tar etait bien pour les backup sur bande ), expose les.
Personnellement, JE t'ai sorti plein d'infos avec des sources tel que les RFC, les descriptions des algorithmes qui permettent de se faire une opinion argumenté ... TOI, TU n'as exposé que TON sentiment, aucun argument laissant entendre une preuve avec une démonstration.
"RFC" contre "croyance benoite" ... ben ca dépend si tu es croyant parce qu'il faut croire ou tu crois à ce que tu peux expliquer.
Donc ton exemple de on upgrade un SGBD ... je te pose une question simple :
Pour quel raison faire un upgrade d'une version majeur d'un SGBD alors que tu as une prod qui fonctionne ( hors faille de sécurité ) ?
TU N'AS AUCUNE RAISON !
ON NE COUPE PAS UN SERVICE QUI FONCTIONNE !
TU NE COUPE QUE POUR DES PROBLEMES DE SECURITE OU D'INTEGRITE DES DONNEES !
en fait, je pense qu'elle est là la différence entre MA vision et TA vision :
pour moi, si il y a une mise à jour du sgbd, il y a test, recette et donc vérification de la compatibilité de tous le systeme d'information
pour toi, tu fais le jacgeek, tu fais du tuning de soft plutot que que voiture, mais c'est pareil, plus le numero de version est gros et plus tu es content.
tu fais ta prod en unstable, tu as 300 gentoo différentes ( compilé chacune à la mano avec amour ).
Moi, j'ai une vie, je veux que mon SI soit stable, je m'en fous d'avoir une truc top moumoute, je veux pouvoir dormir la nuit, pouvoir aller au ciné ... en fait, ne pas avoir à dire "je suis informaticien, le boulot m'appelle" chaque fois que je sors diner avec ma femme ... donc, validation, vérification, controle, redondance, redondance, duplication.
Concretement, un tar étendu via un BASE64+controle sur les 4x2bits vacants , ca me semble largement plus sur que le meme tar suivi d'un gzip
Ton gzip prend peu de place à coté de mon bloat ...
maintenant, essaie de corrompre la totalité de mon bloat autrement qu'en passant au pilon le support :p
Par contre, prend une image, gzip là, change 1 octet quelque part, et ungzip apres ...
je pense que tu vois la différence ... sauf si tu n'as rien compris au seul interêt de la compression de données.
[^] # Re: De la nécessité de tester les sauvegardes
Posté par IsNotGood . Évalué à 2.
Je n'ai pas dit ça.
Je n'ai pas dit que X ou Y est génial.
En passant, je n'utilise pas tar.
> Personnellement, JE t'ai sorti plein d'infos avec des sources tel que les RFC, les descriptions des algorithmes qui permettent de se faire une opinion argumenté ...
Ton raisonnement est : si ça va de travers, ben ça va de travers. Et si tu utilises tar ou gzip, ça ira encore plus de travers.
ON EST D'ACCORD !
Mais si mon fichier tar ou gzip est pourri, ben je le sais. Et je récupère un sauvegarde précédante. Je ne vais pas prendre le risque de vaguement restaurer un truc. Et toi ? Et restaure vaguement des trucs ?
Si un backup a un problème, ben il a un problème. Et même si ce n'est qu'un fichier, va savoiir quelles sont répercutions.
Oui, si un secteur de disque dur ou bande magnétique déconne ben t'aura plus de problème avec tar/gzip que si tu utilises rien. C'est évident, pas besoin de RFC pour savoir ça.
Mais tu (ou je) peux aussi dire, arguments (ou RFC) à l'appuis, qu'un système de fichier c'est dangereux pour les backups car si il déconne t'es dans la merde et qu'il vaut mieux et "tar .... > /dev/sdm" qu'un "cp -r ... [destination]". Que ODF qui groupe des fichiers dans une archive c'est plus dangereux que si c'est non compressé et dispersé sur plusieurs fichiers. Qu'un système de fichier + journalisation + lvm + raid c'est HYPER dangereux car il suffit qu'un seul déconne pour être dans une merde noir. A chaque fois que tu ajoutes un truc, il y a un risque.
Mais si tar (ou cpio, ou rsync ou gzip ou...) marche, ben il marche (et ce n'est pas de la croyance, c'est un constat). Si ton système raid/lwn/ext3/pg_dump marche, ben il marche. Si les archives compressées de ODF marchent, ben elle marchent. Au fais, tu décompresses systématiquement tes fichiers ODF ?
J'imagine que tu dois rêver d'un SDB qui mets chaque enregistrement et chaque champs dans un fichier séparé... Pour le "au cas où" (comme pour le "au cas où un bit de ton gzip ....")
Tu peux aussi éviter les disques durs, les bandes magnétiques, etc car ils finissent tous par planter et privilégier la pierre gravée tant que tu y es.
Il y a toujours un risque. Mais il doit être évalué.
Es-ce que utiliser tar un gros risque ?
Je ne crois pas. Du moins si l'ensemble sauvegarde/restauration est sérieusement testé ET plusieurs sauvegardes archivées (rotation).
Si je peux éviter tar, ben j'évite tar. Si tar me rend service, ben je l'utilise.
J'utilise, et ça va être un standal pour toi, le format "custom" de pg_dump (PosgreSQL) qui par défaut est compressé. Et je ne suis VRAIMENT pas le seul. Ça présente plein d'avantage par rapport au dump SQL "plain". Es-ce un risque ? Oui. Mais ridicule. Et ça marche (comme tes serveurs en prod).
> "RFC" contre "croyance benoite"
Lis ce que j'ai écris.
Si j'avais une "croyance benoite" tu crois que je vérifierais mes backup et procédures de restauration tous les mois ?
> "RFC"
Ben lit la doc sur ext3, et ext3 comme tar, s'il y a un problème de disque (secteur ou autres) ou qu'un problème d'OS, ou la mémoire vive qui déconne, ben tu n'es pas à l'abris de perdre des donnés (un secteur, un cluster, un group ou 1000 fois pire). C'est hypra clair. Pourtout tu utilises bien des systèmes de fichier ?
Tar est une sorte de un système de fichier, ça a les mêmes problèmes.
> Pour quel raison faire un upgrade d'une version majeur d'un SGBD alors que tu as une prod qui fonctionne ( hors faille de sécurité ) ?
Car tu ne sauvegardes pas les serveurs de développement, pré-production ?
C'est les développeurs qui vont être heureux d'entendre ça...
Puis le "ça marche je n'y touche pas" il est vrai pour une période donnée. Sinon les admins seraient au chômage.
Il y a plein de serveur en production qui doivent évoluer. Et parfois tu ne peux pas avoir la base de production complète en test (trop cher) et faire des tests exhautif.
> ON NE COUPE PAS UN SERVICE QUI FONCTIONNE !
BEN MES BACKUPS GZIP, PG_DUMP, ETC MARCHENT !
> pour moi, si il y a une mise à jour du sgbd, il y a test, recette et donc vérification de la compatibilité de tous le systeme d'information pour toi, tu fais le jacgeek, tu fais du tuning de soft plutot que que voiture, mais c'est pareil, plus le numero de version est gros et plus tu es content.
Puisque tu le dis...
T'as trouvé ça dans une RFC ?
> je m'en fous d'avoir une truc top moumoute
T'es seulement obsédé à avoir un truc théoriquement sans point faible. Mais il ne l'ai pas et ne le sera jamais (idem pour moi).
Je te laisse dans ta croyance absolue de ton système parfait.
> Par contre, prend une image, gzip là, change 1 octet quelque part, et ungzip apres ...
Change un secteur d'un système de fichier au hazard. Tu m'en diras des nouvelles. Si t'as un peu de chance, tu tombes sur un secteur non utilisé. Si t'as moins de chance, ça va te prendre des semaines pour constater les dégâts, remonter le problème et récupérer un backup vieux de 2 semaines.
Mais dis moi, si pour toi c'est dangeureux d'utiliser tar ou gzip, pourquoi tu utilises les systèmes fichiers ?
[^] # Re: De la nécessité d'aller se boire une bière entre geeks
Posté par jeffcom . Évalué à 4.
[^] # Re: De la nécessité de tester les sauvegardes
Posté par Mouns (site web personnel) . Évalué à 2.
debugfs est mon meilleur ami depuis decembre 95 :D
tu confond un systeme parfait avec un système dont on sait qu'il peut tomber en panne.
Si tu as de la chance, cela ne tombe pas en panne.
Si tu n'en as pas, en cas de panne, tu peux identifier ce qui merde.
Entre restaurer un fichier client intégral datant de J-14 ou la quasi intégralité du fichier qui a J-7 et juste ce qui manque dans le fichier J-14 ... il y a une différence ;)
Détail, l'intégrité des données est importante, et cela se gere aussi du coté backup ... donc, il faut pouvoir identifier les informations manquantes pour agir en conséquence.
maintenant, un secteur complet d'une FS qui est corrompu, fsck en mode -n ( le -y etant le piège à con ) pour identifier les problèmes, debugfs pour reconstruire ... c'est plus mieux quand meme qu'un tgz intégralement bon pour la poubelle.
je me repete :
tar n'est pas un probleme, c'est juste un format d'archivage linéaire/séquentiel ... donc parfait pour une lecteur de bande, inutile pour un disque avec des accès aléatoire.
il faut d'autres modèles d'archivage sur disque qu'un archivage de type bande ... surtout pour de la sauvegarde incrémental ( et le mode batch de rsync est cool pour déterminer le delta à archiver et le delta qui a été archivé ).
maintenant, gzip/compress/rar/zip/uc2/bzip/... sont des algorithmes de compression de données ... le but de la compression n'est pas de faire des archives, mais de faire que l'information prenne le moins de place possible en éliminant la redondance, les bits inutiles.
Donc plus ton taux de compression est important plus chaque bit du fichier compressé comporte de l'information. Si tu introduit une corruption dans un fichier compressé, cette corruption n'a pas un impact local, mais à un impact global sur toute le document.
Si tu corromps un tar non compressé, tu peux détecter la corruption et essayer de passer outre ( histoire de vanter tar tout court ) ... même si ce n'est pas facile à faire, c'est faisable.
par contre, sur ton tar.gz, si tu le corromps, tout est bon pour la poubelle.
maintenant, un systeme de fichier offre des outils comme fsck et un systeme d'accès non linéaire ... alors que pour sortir un fichier d'une grosse archive tar, il faut :
init - aller au début
1 - lire les entete
2 - si le nom correspond on extrait le fichier et on s'arrete
3 - sinon deplacer la tete de la taille en octet déclaré dans les entetes puis aller à l'etape 1
donc un tar de 1Go de plein de petits fichiers, c'est une plaie au niveau acces ... alors qu'une filesystem de 1Go avec les memes petits fichiers, offre un moyen de trouver rapidement le fichier que l'on cherche.
maintenant, rien ne t'empeche de compresser ton image disque, mais cela sera comme un tar.gz ;)
Quand tu rétablis une sauvegarde, tu ne rétabli pas nécessairement toute cette sauvegarde ... par exemple tu n'as besoin que de rétablir 2 fichiers et non le reste.
l'image disque offre donc un moyen d'acces rapide quand on stocke ses sauvegardes sur des disques ... sur un lecteur de bande, tar est largement plus efficace.
Est ce plus clair ?
[^] # Re: De la nécessité de tester les sauvegardes
Posté par IsNotGood . Évalué à 2.
Mais c'est clair depuis le début.
M'enfin tu ne peux (ou ne devrais pas) sous-entendre qu'un tar (gzip en plus ou pas) n'est pas un backup. C'est un backup avec ses faibles comme tous les backups.
Tu peux le juger moins fiable, c'est tout à fait recevable et compréhensible.
J'évite les archives et la compression seulement car c'est moins pratique (ça ne se prête pas à un rsync par exemple). Pas car c'est (forcément) moins fiable.
Si tu fais un mirroir de kernel.org, tu n'as pratiquement que des fichiers compressés, mais c'est un backups. Évidemment si tu mets le tout dans un gros tar de 10 To, ce n'est pas malin.
[^] # Re: De la nécessité de tester les sauvegardes
Posté par Mouns (site web personnel) . Évalué à 3.
tu fais pas 3 000 kilometres de désert en smart, tu fais pas tous les jours tes 10 blocs d'immeuble à paris avec un 4x4 :
- un 4x4 c'est adapté au désert
- une smart c'est adapté à la ville
tu ne stockes pas une FS sur une bande, c'est contre performant au niveau des IO.
de la même manière utilisé un tar plutôt qu'une image disque sur un disque est contre performant au niveau des IO.
tar est linéaire, une fs est un arbre ... et si tu prend une fs pensé de manière judicieuse, tu te garantie une profondeur d'au plus log(total fichier)/log(densité)
et cette profondeur représente le nombre maximum d'accès disque pour trouver un fichier.
donc si tu veux une densité de 256, pour une profondeur de 4, tu gères 4 milliards de fichiers :)
donc tu peux identifier un fichier parmis 4 000 000 000 en seulement 4 acces disques ! sur un tar, au mieux tu auras 1 acces disque au pire tu en auras 4 000 000 000 :)
donc, sur une bande linéraire ou tu ne peux que dérouler ou enrouler, tar est parfait, et il te faudra dérouler les 4 000 000 000 de fichiers si celui que tu cherches est tout à la fin de la bande.
sur un disque, tar est contre productif. ca ne veut pas dire que c'est un mauvais outil, non, tar est un bon outil ... mais il faut l'utiliser là ou c'est utile :)
maintenant, c'est une question de liberté individuelle, comme pour les 4x4 en ville : certaines aiment les 4x4 en ville d'autre trouvent cela absurde ;)
[^] # Re: De la nécessité de tester les sauvegardes
Posté par totof2000 . Évalué à 2.
Pour quel raison faire un upgrade d'une version majeur d'un SGBD alors que tu as une prod qui fonctionne ( hors faille de sécurité ) ?
TU N'AS AUCUNE RAISON !
ON NE COUPE PAS UN SERVICE QUI FONCTIONNE !
TU NE COUPE QUE POUR DES PROBLEMES DE SECURITE OU D'INTEGRITE DES DONNEES !
Au hasard : l'éditeur du logiciel (propriétaire) que tu utilise ne supporte plus la version qui tourne sur ton SI, et tu dois upgrader car il y a un bug emmerdant parce que ton applicatif a évolué un chouia et fait apparaitre ce bug.
[^] # Re: De la nécessité de tester les sauvegardes
Posté par Ph Husson (site web personnel) . Évalué à 3.
Couper l'archive en plusieurs morceaux et utiliser par2, qui permet de récuperer des morceaux à partir de ceux existant grace à l'algorithme de Reed-Salamon, qui utilise quelques blocs de correction (comme du raid5 grosso modo mais en beaucoup plus souple en % de données utilisées pour les codes de correction) ( http://fr.wikipedia.org/wiki/Code_de_Reed-Solomon ), qui est franchement efficace à mon avis (et permet de garder une restauration automatique et avec, je penses plus de chances de réussites)
[^] # Re: De la nécessité de tester les sauvegardes
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
# /tmp et backup , construire sa maison sur du sable ......
Posté par eastwind☯ . Évalué à 3.
Jamais entendu un truc pareil , le truc qu'on doit garder sur le LONG terme on le met dans l'espace à super COURT terme ???? et pourquoi pas dans la RAM ? C'est peut être pas un hasard s'il s'appelle repertoire temporaire ?? ?
la /tmp c'est cool pour faire des tests de soft , de fichiers etc .. qu'on sait qu'on peut récupérer rapidement au cas ou un reboot intempestif interviendrait ...
Si un admin me dit ca , je le vire sur le champ :) même si je suis pas son boss (je vire son numéro gsm , msn , jabber etc ... de ma liste de contact :)
[^] # Re: /tmp et backup , construire sa maison sur du sable ......
Posté par feth . Évalué à 2.
[^] # Re: /tmp et backup , construire sa maison sur du sable ......
Posté par IsNotGood . Évalué à 4.
Il y a un petit truc "marrant" avec /tmp.
Fedora voulais purger /tmp à chaque boot. Mais comme beaucoup de gens qui stockent des choses, l'idée a été abandonnée.
SeLinux voulais aussi le faire pour "autorelabel". En effet, les fichiers dans /tmp n'ont pas de label par défaut, et donc on ne peut pas restaurer les labels. Si un truc sucks avec SeLinux à cause d'un fichier dans /tmp, un relabel n'est pas suffisant.
Bref, /tmp (et /var/lib/tmp, etc) porte bien son nom.
Notons que des gens montent /tmp en tmpfs. Comme ça il est clean à chaque boot.
[^] # Re: /tmp et backup , construire sa maison sur du sable ......
Posté par totof2000 . Évalué à 2.
# en même temps ...
Posté par Fabien (site web personnel) . Évalué à -7.
sinon, faire des backups sur la machine même ça sert presque à rien ...
et puis dans ton cas (remonter un serveur identique), la backup de la configuration de la plateforme peut aussi être très utile.
[^] # Re: en même temps ...
Posté par kowalsky . Évalué à 8.
si vous choisissez de mauvais outils tels que ce sgbd alors qu'il en existe un bien meilleur sous tous points de comparaison ....
MSSQL n'est pas ( encore ? ) disponible sous linux, en attendant
on fait avec ce que l'on a... :)
[^] # Re: en même temps ...
Posté par IsNotGood . Évalué à 2.
Il y a mieux que MSSQL, c'est PostgreSQL. View, réécriture de requête, language embarqué, function, vrai système de transaction, etc. Que du bonheur.
Et ce n'est pas la chianlie avec PostgreSQL de gérer les dates...
[^] # Re: en même temps ...
Posté par Toto . Évalué à 2.
Hop, pu la -->[]
# Poisson?
Posté par srp51 . Évalué à -1.
# Après les script kiddies...
Posté par fcartegnie . Évalué à 6.
On avait déjà les script kiddies, voici une nouvelle espèce: les admins tutos.
[^] # Re: Après les script kiddies...
Posté par Larry Cow . Évalué à 5.
Ceci dit, trève de cynisme : les dédiés pas chers, c'est très pratique. Mais effectivement, faut pas oublier qu'on a ce pour quoi on paye, comme partout.
[^] # Re: Après les script kiddies...
Posté par fcartegnie . Évalué à 2.
# Mise au point
Posté par Florent Peyraud (site web personnel) . Évalué à 10.
J'ai aussi bien lu tous vos bons commentaires et je pense que j'ai oublié de préciser quelques trucs pour que je ne sois pas définitivement classé dans la catégorie des débiles mentaux, script kiddies ou admin débutants :
1. je ne suis pas admin de profession, et je sens que tout le monde respire mieux maintenant qu'ils savent qu'ils ne risquent pas d'avoir à me fréquenter dans ce cadre là :)
2. Je pense qu'on a tous fait des conneries un jour et que tout le monde en est ressorti un peu moins con que la veille.
3. Ce journal n'est pas seulement une auto flagellation, mais aussi un rappel pour tous que les backups sont plus que nécessaires et que c'est pas tout de les faire, faut aussi les faire correctement.
Sur ce dernier point, je vous remercie d'avoir apporté de l'eau au moulin avec des éléments constructifs.
Maintenant, que celui qui ne s'est jamais trompé me lance la première pierre...
[^] # Re: Mise au point
Posté par briaeros007 . Évalué à 1.
Suffit juste de demander, aux utilisateur d'emacs entre autre
"Qui a jamais fait rm * ~ ?
Ouep y'a plus grand monde dans la salle"
XD
L'autre truc qui est assez courant en entreprise (donc tu n'as pas à t'inquiéter) c'est de faire toute la conf d'un routeur cisco ou autre, et d'oublier d'écrire XD (lorsqu'on configure un cisco, la conf est en RAM, et on ne modifie donc que la ram. Il faut lui spécifier, une foi qu'on a terminé, de stocker la conf !).
Première panne de courant "Ben pourquoi le réseau marche pas ?"
[^] # Re: Mise au point
Posté par Jean-Max Reymond (site web personnel) . Évalué à 1.
[^] # Re: Mise au point
Posté par dguihal . Évalué à 3.
sinon j'ai vu aussi un subtil chmod -R 0777 à la racine assez ravageur
[^] # Re: Mise au point
Posté par BAud (site web personnel) . Évalué à 2.
/bin/rm -R * # rha marche pas
su - # et zou ça va être bon
/bin/rm -R * # le copier/coller à la souris ça a du bon
... et merde le cd à faire avant /o\ (heureusement que je n'étais pas sur un slowlaris :D)
[^] # Re: Mise au point
Posté par totof2000 . Évalué à 2.
root@toto : / >/bin/ls -l
Un caractere de trop dans le copier/coller et on vire la commande LS.
Les admins/utilisateurs qui utilisent de tels prompt devraient se faire virer/flagelller sans pitié.
[^] # Re: Mise au point
Posté par CrEv (site web personnel) . Évalué à 4.
C'est pour ça qu'il est intéressant d'avoir :
alias cp="cp -i"alias mv="mv -i"
alias rm="rm -i"
dans /etc/profile.d/alias.sh par exemple
Evidemment ça empêche pas les rm -Rf mais bon y'a un moment où on cherche vraiment à se faire du mal...
sinon, pour apporter de l'eau avec ma petite histoire personnelle :
j'avais une machine qui plantait souvent mais de manière aléatoire. Pensant que j'avais eu raison du système et profitant d'une nouvelle version de ma distrib, je me suis dit que j'allais la réinstaller.
Je fais des sauvegardes dans tous les sens, je tar.bz2 le tout (oui j'ai l plus haut, je sais que c'est maaal...) et je copie tout sur un disque externe.
Je formatte (évidemment sans avoir tenter de décompresser mon archive, réinstal ma machine ... qui continue à planter...
Pris d'une illumination, je fais un memtest -> qq dizaines de millier d'erreur -> contrôlleur mémoire HS... (mais ram OK)
Evidemment ... lecture impossible de l'archive, elle a été corrompue durant la copie vers mon disque externe, probablement à cause des problèmes mémoire.
Bilan : qq mois de documents (y compris très importants), mails et divers de perdu
Rq : j'ai toujours l'archive de côté, dans l'espoir qu'un jour j'arrive à récupper au moins une partie du contenu...
[^] # Re: Mise au point
Posté par Xavier . Évalué à 2.
dans ma boîte, ils font tous \rm...
Sont des fois chiant les users :-P
[^] # Re: Mise au point
Posté par Raphaël SurcouF (site web personnel) . Évalué à 6.
[^] # Re: Mise au point
Posté par ✅ ffx . Évalué à 1.
Hier encore j'ai fait un "cp script*" au lieu de "cp script* destdir", et je n'avais évidemment que deux fichiers commençant par script...
(heureusement, ce n'était pas très critique, mais ca énerve quand même)
[^] # Re: Mise au point
Posté par CrEv (site web personnel) . Évalué à 2.
En tout cas sous mandriva, il y a ceux-ci ainsi que ll, la, lsd ;-) cd.. (au lieu de cd ..)
Et le mieux à mon avis, est de le mettre directement dans la config de base du système, pour que tous les utilisateurs en profite directement.
[^] # Re: Mise au point
Posté par totof2000 . Évalué à 4.
Il est la le risque ....
[^] # Re: Mise au point
Posté par totof2000 . Évalué à 4.
alias cp="cp -i"
alias mv="mv -i"
alias rm="rm -i"
NON SURTOUT PAS !!!!
Parce que sinon tout le monde s'imagine que c'est le comportement par défaut de la commande, et c'est justementy parce qu'un jour ils seront sur un système ou il n'y a pas cet alias que ça va merder.
Unix/Linux a uin comportement précis, et suppose que l'intervenant SAIT CE QU'IL FAIT.
[^] # Re: Mise au point
Posté par Ellendhel (site web personnel) . Évalué à 2.
Je profite d'un peu de simplicité sur ma machine mais je garde la rigueur nécessaire sur les machines du service.
[^] # Re: Mise au point
Posté par octane . Évalué à 5.
Je suis d'accord; quelle a été la plus belle bêtise que vous avez faite?
Je démarre dans le mode <mavie>:
On me prévient que le site web a des problèmes. Je me connecte en vitesse en ssh, et effectivement tout est en vrac.
Des vieilles versions du site qui trainent, des vieux trucs, des services zarb qui tournent, une arborescence qui a été modifié, le souk complet.
Sueurs.
Je vais chercher des backups, je remonte le bin's, en plus le serveur rame comme pas permis, le service ftp est ouvert, le service smtp, j'espère qu'on s'est pas fait pirater. Je me rends compte que la base SQL est en vrac aussi, je remonte le minimum, je me déchire, j'arrive a faire un truc qui tourne sur trois pattes bien crado, mais bon.
Et là, je me rends compte que je me suis trompé d'adresse IP... J'étais connecté sur un vieux bouzin qui servait à faire du dev et non pas sur le serveur de prod.
10litres de sueur et 4h de perdues parceque je me suis précipité bêtement sans m'assurer de là ou j'étais.
[^] # Re: Mise au point
Posté par ham . Évalué à 2.
2) durant l'install d'un bsd (valable pour un linux aussi) sur une machine :
- tout virer de hda2,mettre en securité sur hda1
- lancer l'installeur
- formater hda1
- tient il est ou mon linux?
[^] # Re: Mise au point
Posté par titi toto . Évalué à 1.
Euh, non.
[^] # Re: Mise au point
Posté par Romeo . Évalué à 1.
rm blah*
S'il n'y a qu'un seul fichier le tab rajoutera un espace.
[^] # Re: Mise au point
Posté par titi toto . Évalué à 1.
[^] # Re: Mise au point
Posté par Xavier . Évalué à 2.
#reboot
sans prêter attention sur quelle machine je me trouvais.
Resulats: serveur principal (NIS avec le share NFS des homes de tous les users)
et le pompom, le scan des volumes au reboot puisqu'on ne le redemarre pas tout le jours cette bonne bête... et 2To c'est long...
p.s oui il y a un alias maintenant.
[^] # Re: Mise au point
Posté par IsNotGood . Évalué à 3.
Mais ce n'était pas vraiment de ma faute. J'avais une nouvelle bécane de développement. Pour le développement, on a le mot de passe root. Je demande le mot de passe à l'admin, il me le donne et je le sent un peu embarassé.
Quelques minutes après je veux rebooter la bécane (pour passer sur la dernière version de l'OS et faire des tests/portages/etc), je fais "su ... reboot". Sauf que j'étais sur le serveur...
Cet "abrutis" d'admin avait mis le même mot de passe root sur ma bécane que sur le serveur.
Heureusement ce n'était pas 30 000 utilisateur, mais une bonne cinquantaine. En 5 secondes on m'enformait que le serveur était down. Ce qui expliquait que ma bécane n'était en train de rebooter...
[^] # Re: Mise au point
Posté par kowalsky . Évalué à 5.
Mais ce n'était pas vraiment de ma faute. ( ... )
Cet "abrutis" d'admin avait mis le même mot de passe root sur ma bécane que sur le serveur.
J'aime ton sens de la remise en questions et du respect des autres...
[^] # Re: Mise au point
Posté par eastwind☯ . Évalué à 2.
Maintenant, que celui qui ne s'est jamais trompé me lance la première pierre...Si tu fais référence à JC alors tu vas avoir droit a une crucifiction et si c'est son papa alors ca va être un météore :)
[^] # Re: Mise au point
Posté par Nick Depp . Évalué à -1.
[^] # Re: Mise au point
Posté par Anonyme . Évalué à 3.
hop je l'efface sudo rm -r usbdisk
rrrrrrr (ronronement du disque dur)
ctrl+C
bref un manque d'attention, snif
# Récupération de données
Posté par liberforce (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.