Backup base 400Go journalier

Citation:

---

Envoyé par pmithrandir

Nous explorons aussi la sauvegarde par snapshot de notre volume NFS, mais c'est moins stable sur ce datacenter, donc on est moins sur de notre coup.

---

Pour cela il faut aussi freezer les fichiers de la base sinon il y a toutes les chances que votre base soit corrompue. En effet, les contremarques (LSN) entre les journaux de transactions et les fichiers de données doivent correspondre. Si vous copiez séquentiellement ces fichiers il y a toutes les chances que l'alignement ne soit pas correct et votre base considérée comme corrompue avec aucune possibilité de récupération !

Bref, sauvegarde à froid uniquement et de l'intégralité de la base....

Moralité : avant de choisir bêtement un SGBDR "parce que ça coute pas cher" il faut étudier le cas avant !

A +

Encore une fois Arthemus vous supposez beaucoup de chose sur moi, alors que visiblement vous ne savez pas de quoi vous parlez...

Je vous ais déjà invité à lire mon ouvrage sur SQL et vous n'avez pas voulu...
Je vous ais aussi indiqué que je pouvais vous l'envoyer par la poste et vous avez refusé car vous voulez préservez votre anonymat...
Et vous avez mêle décliné la poste restante !
Et certains de vos posts montrent à quel point vos croyances sont fondés sur une certaine expérience qui est loin d'être la réalité....
Un peu d'ouverture et d'humilité serait bienvennue !

Citation:

---

Envoyé par Artemus24

Salut SQLPRO.


Le contraire m'aurai étonné ! Et c'est toi qui fait la confusion.

---

Ben voyons.....
La demande porte sur la sauvegarde et vous lui balancez la haute dispo et vous m'accusez d'entretenir la confusion alors que c'est vous qui l'avez introduite et moi qui ait pointé que vos dires n’avariant rien à voir avec la demande initiale !

Quelle mauvaise foi !

Citation:

---

Il n'y a pas de basculement à faire. La tolérance de panne consiste à doubler le matériel (pas uniquement les disques) pour éviter la panne physique.
De ce fait, le serveur ne tombe jamais en panne car tout est doublé. On se retrouve dans de la disponibilité en continue.
http://fr.nec.com/fr_FR/emea/product...ervers/ft.html

---

La doc que vous donnez montre un serveur NEC qui existe chez la plupart des autres constructeurs depuis des lustres (HP, IBM, DELL...) Mais il existe toujours un SPOF qui peut être l'onduleur ou le réseau....

Même le basculement d'un CPU pour isolation suite à défaut provoquera une légère interruption. En effet, certains processus système devront être redémarré sur l'autre nœud... Ce qui provoque automatiquement une attente....

Citation:

---

Il n'y a pas d'interruption en cas de panne. Justement la tolérance de panne est faite pour éviter ce genre de problèmes matériels.

La tolérance de panne concerne la disponibilité physique du matériel. Cela n'a rien à voir avec un backup et cela n'empêche pas de temps en temps d'en faire un.
J'ai surtout l'impression que tu ne sais pas ce que c'est la tolérance de panne !

---

Non, il est vrai que je n'ai écrit aucun article sur le sujet.... Comme par exemple :
http://sqlpro.developpez.com/cours/s...disponibilite/
écrit en 2006... Sans doute je ne sais pas de quoi je parle.....
En sus je n'ai jamais travaillé dans le domaine de la base de données, domaines dans lequel je n'ai jamais écrit de livre... Comme par exemple :
Pièce jointe 191958
En 2001
De même je n'ai pas d'entreprise spécialisée dans le conseil en matière de SGBD...
http://www.societe.com/societe/sql-spot-495059123.html
Et enfin, je ne suis pas considéré comme expert par Microsoft sur les technologies SQL Server :
https://mvp.microsoft.com/zh-tw/Publ...eric%20Brouard
Ce qui fait que jamais au grand jamais je ne me suis posé des questions sur la haute disponibilité des bases de données.... Même pas pour mes clients....

Dis, par hasard.... Tu me prendrais pas pour un con ?
Parce que si c'était ça, alors je pourrais devenir méchant !

Citation:

---

Ce que tu me décris n'est qu'une mauvaise pratique qu'il faut interdire ! Quand on est en production, on ne vient jamais bidouiller sur les bases de données.

---

Ça c'est de la théorie. La pratique (et je pense que tu n'as pas dû pratiquer souvent !) montre que c'est bien plus courant que cela. Comme je suis en congrès chez Microsoft à Redmond (MVP Summit 2015) - 3000 participants - j'ai posé la question à mon proche entourage à l'instant et la réponse est unanime... tous ont eu un client qui a effacé des tables un jour ou l'autre. J'ai moi même vu cela à deux reprises...

Citation:

---

Si tu as des tests à faire, tu dupliques ce site, par un backup qui ne pénalise en aucune façon l’accessibilité des bases de la production.
Ainsi, avec ce site dupliqué, tu es seul à travailler et si cela t'amuse à droper une table, tu seras le seul à en être pénalisée.

Si tu dois intervenir en production pour corriger un bug, tu dois le faire par l'intermédiaire d'un script qui aura été mis au point sur ton site de test.
Dans le creux de la journée, tu peux rendre ton site indisponible durant cette correction, à la condition que cela prend peu de temps.

---

Ça c'est encore la théorie.... Quand il y a urgence à rectifier sur un site Web sinon on perd du fric.... Ça se passe en direct... !
Personnellement j'étais là en tant que chef de projet quand nous avons eu un gros plantage sur le site ooshop en 2000... Bref, 3 h d'indispo à rectifier la chose avec remontage de la sauvegarde....

Citation:

---

Si le temps nécessaire à cette correction est beaucoup trop long, la solution consistant à recopier la nouvelle base de données vers le second disque qui est en mirroring.

---

N'importe quoi...

Citation:

---

Pour ce faire, il faut rendre indisponible le second disque durant cette manœuvre, puis remettre en activité le mirroring après la manœuvre, en indiquant que le premier disque est le clone du second.
Ce basculement dure très peu de temps, et ne nécessite même pas l'arrêt du serveur.

On peut toujours envisager le pire, comme le fait skuatamad :

Mais dans ce cas là, il n'existe aucune solution possible !


Oui, je suis au courant de cette pratique exigée par le fisc. On fait aussi un backup de la base de données au 31 décembre.
Et si des experts comptables, sur la demande du fisc, ont besoin de vérifier quelque chose, on crée un site de test par restauration de ce backup.

Le problème est que tu mélanges deux notions différentes :
--> la tolérance de panne afin d'avoir une disponibilité physique du matériel en continue.
--> le backup qui sert à dupliquer une base de données et dont on se sert pour recréer un site en vue de faire des tests.

Et s'il te plait, arrête de parler de sauvegardes car tu crées la confusion avec le backup.

---

On a tous beaucoup rigolé à la lecture de cette dernière phrase prouvant la bétise de tes propos.
Pour ton information, le terme BACKUP est un mot anglais dont la traduction est sauvegarde !
J'en pisse encore de rire !
Pièce jointe 191959Pièce jointe 191960

Citation:

---

Allez vas y, mets moi un '-1' puisque je viens de te contredire !

@+

---

Il est vrai que Arthemus était le rigolo du duo des "Mystères de l'ouest" !!!!

A +

Citation:

---

Envoyé par ddoumeche

Est-ce toujours le cas ?
un problème de configuration NFS ou de saturation au niveau de la compression ?

---

Je crois que c'est un peu plus haut, mais l'écriture disque + le réseau limite forcement en bout de course.

Citation:

---

Envoyé par SQLpro

Pour cela il faut aussi freezer les fichiers de la base sinon il y a toutes les chances que votre base soit corrompue. En effet, les contremarques (LSN) entre les journaux de transactions et les fichiers de données doivent correspondre. Si vous copiez séquentiellement ces fichiers il y a toutes les chances que l'alignement ne soit pas correct et votre base considérée comme corrompue avec aucune possibilité de récupération !

Bref, sauvegarde à froid uniquement et de l'intégralité de la base....

Moralité : avant de choisir bêtement un SGBDR "parce que ça coute pas cher" il faut étudier le cas avant !

A +

---

Dans le cas d'une sauvegarde Mysql par LVM , les bases et fichiers afférants (logs, transaction logs,...) reste en RW mais les données modifiées le sont sur un nouveau volume temporaire.
A la fin du Snapshot, ce volume temporaire est réconcilié avec l'ancien en écrasant tout simplement les anciennes données.
Vous pouvez normalement faire cela avec un bon SAN, sans vous poser plus de questions.

Mais je n'ai jamais testé cela pour avec une configuration NFS.

L'Open Source peut couter très cher si on ne se pose pas les bonnes questions et qu'on étudie pas son problème avant... mais le propriétaire aussi.
Le métier de DBA Myqsl a de l'avenir.

Citation:

---

Envoyé par pmithrandir

Je crois que c'est un peu plus haut, mais l'écriture disque + le réseau limite forcement en bout de course.

---

Normalement pas au point de tomber aussi bas.

Je me permet de relancer, on ne trouve pas des vrais sujets croustillants tous les jours.

Salut à tous.

Dès que vous vous sentez attaqué dans vos propos, voici votre réaction :

Citation:

---

Envoyé par SQLPRO

Dis, par hasard.... Tu me prendrais pas pour un con ?
Parce que si c'était ça, alors je pourrais devenir méchant !

---

Mais vous l'êtes déjà, et arrêtez de passer pour la victime !
Que dois-je comprendre ? Que l'opinion des autres ne vaut rien, face à votre éloquence coutumière.

Pourquoi avez-vous besoin de preuves annexes pour vous justifier ?
Un livre dont vous êtes l'auteur, les coordonnées de votre société, votre notoriété en tant que professeur ... Si ce sont vos seuls arguments, elles sont bien pauvre.

Vu votre mauvaise connaissance de MySql, il serait plus judicieux que vous restiez dans le forum consacré à 'Microsoft Sql server'.
Là-bas, vous serez plus à l'aise pour étaler votre connaissance livresque.

Citation:

---

Envoyé par SQLPRO

La pratique (et je pense que tu n'as pas dû pratiquer souvent !)

---

Allez y, continuez de me rabaisser si cela vous donne de l'importance.

Citation:

---

Envoyé par SQLPRO

j'ai posé la question à mon proche entourage à l'instant et la réponse est unanime... tous ont eu un client qui a effacé des tables un jour ou l'autre.

---

Ce n'est pas parce qu'ils sont nombreux à le faire qu'ils ont tous raisons. C'est bien ce que je dis, c'est une mauvaise pratique et elle est très courante dans le monde la micro.
Ils faut faire la distinction entre site de production et site de développement. D'où des problèmes récurrents à cause de mauvaises manipulations.
Avant de donner des leçons, il faudrait apprendre à travailler correctement !

Un backup, c'est :

Citation:

---

un système de redondance pour les applications vitales d'une entreprise (un plan de continuité d'activité ou un plan de reprise d'activité, dans le sens de système de secours).

---

Déjà, il faudrait sortir de l'environnement SGBD pour voir qu'il existe d'autre solution aux problèmes des backup.
Il n'y a aucune nécessité d'arrêter un serveur durant la phase du backup car c'est une sauvegarde à chaud.
Exemple : Acronis Backup

Autre exemple : Symantec System Recovery

Vous êtes tellement axé sur votre "Microsoft Sql Server" que vous oubliez qu'ils existent d'autres solutions offrant d'autres opportunités.

Citation:

---

Envoyé par pmithrandir

Quel conseils pouvez-vous nous donner pour effectuer nos backup quotidiens de toute la base.

---

Comme je l'ai dit dans mon premier message, j'utilise Acronis pour faire des backup.
Orientez-vous vers ce genre de solution qui se fait à chaud et ne nécessite pas d'instaurer un verrou en lecture sur la table que vous sauvegardez.
Elle offre la solution d'être général à un ordinateur et non spécifique à un SGBD.

Faites une recherche sur le net en cliquant sur ce lien.

En cherchant un peu plus sur Google, vous trouverez aussi :
--> Acronis Backup
--> Symantec Backup EXEC
--> DriveClone
--> Paragon Drive Backup
--> Avanquest Perfect Image 11

@+

[QUOTE=ddoumeche;8432441
Mais je n'ai jamais testé cela pour avec une configuration NFS.
[/QUOTE]

Hé bien testez en situation réelle de production et vous m'en reparlerez !

A +

Citation:

---

Envoyé par Artemus24

Un backup, c'est :
"un système de redondance pour les applications vitales d'une entreprise (un plan de continuité d'activité ou un plan de reprise d'activité, dans le sens de système de secours). "

Je ne sais pas ou vous avez pris cette définition dont vous n'avez pas cité d'ou eelle est estraite (sans doute de votre cerveau fumeux !), mais voici celle de Wikipedia :
https://fr.wikipedia.org/wiki/Sauveg...nformatique%29
"En informatique, la sauvegarde (backup en anglais) est l'opération qui consiste à dupliquer et à mettre en sécurité les données contenues dans un système informatique."
Comme vous le voyez on parle de données.... Et non pas de tout et n'importe quoi !


Déjà, il faudrait sortir de l'environnement SGBD pour voir qu'il existe d'autre solution aux problèmes des backup.
Il n'y a aucune nécessité d'arrêter un serveur durant la phase du backup car c'est une sauvegarde à chaud.
Exemple : Acronis Backup

---

Vous confondez backup de machine et backup de base de données. L'un ne garantie pas l'autre !
Et de toute façon, la sauvegarde concerne les données et pas un système en entier....

Citation:

---

Comme je l'ai dit dans mon premier message, j'utilise Acronis pour faire des backup.

---

Amusez vous à faire de la vrais prod et restaurez... On en reparlera !

Commencez par apprendre l'informatique... Et notamment les bases de données. Mon livre, comme mon site web peuvent vous y aider :
Pièce jointe 192116

A +

Citation:

---

Envoyé par Artemus24

Pourquoi avez-vous besoin de preuves annexes pour vous justifier ?
Un livre dont vous êtes l'auteur, les coordonnées de votre société, votre notoriété en tant que professeur ... Si ce sont vos seuls arguments, elles sont bien pauvre.

Vu votre mauvaise connaissance de MySql, il serait plus judicieux que vous restiez dans le forum consacré à 'Microsoft Sql server'.
Là-bas, vous serez plus à l'aise pour étaler votre connaissance livresque.

---

Vous discréditez sciemment ou vous êtes un réel imbécile ?

Voici quelques uns des articles que j'ai écrit et qui consacre toute ou partie à MySQL :
http://blog.developpez.com/sqlpro/p9...oudre_aux_yeux
http://blog.developpez.com/sqlpro/p9...alles_en_sql_1
http://blog.developpez.com/sqlpro/p1..._grand_folklor
http://blog.developpez.com/sqlpro/p9...text_search_no
....

Au moins cultivez-vous au lei de rabaisser les autres pour faire valoir votre savoir !

A +

Citation:

---

Envoyé par SQLpro

Hé bien testez en situation réelle de production et vous m'en reparlerez !
A+

---

D'abord, il y a heureusement d'autres protocoles que NFS, et je ne suis pas forcément mandaté par l'entreprise de pmithrandir pour tester sa configuration de production.

Ensuite, pourquoi ne le faites pas vous même au lieu de troller sur ces forums pour vendre vos bouquins ?

Salut à tous.

Citation:

---

Envoyé par SQLPRO

Vous confondez backup de machine et backup de base de données. L'un ne garantie pas l'autre !

---

Je ne confonds strictement rien, à l'inverse de vous. Vous croyez à tort que seul votre expérience prime sur celle des autres.
Et je le répète encore une fois, ici on est dans le forum consacré à "MySql" et non à "Microsoft Sql Server". Donc autres problématiques !

Citation:

---

Envoyé par SQLPRO

Et de toute façon, la sauvegarde concerne les données et pas un système en entier....

---

Votre remarque démontre encore une fois, que vous ne connaissez strictement rien en système !

Citation:

---

Envoyé par SQLPRO

Amusez vous à faire de la vrais prod et restaurez... On en reparlera !

---

Mais bien sûr, travaillez sur gros système IBM et faire de l'administration DB2, c'est pour les débutants.
Et se retrouvez avec des volumétries de l'ordre du Tera bytes, c'est une mini base de données.
Et faire en sorte de conserver les bases accessibles 24H/24H, c'est à la porté de n'importe qui.

Arrêtez de nous faire croire que vous êtes un champion des bases de données.
Vous ne connaissez strictement rien, à par peut-être "Microsoft Sql Server".
Quand vous aurez une réelle expérience et non de faire du bidouillage avec vos étudiants, on en reparlera.

Citation:

---

Envoyé par SQLPRO

Commencez par apprendre l'informatique... Et notamment les bases de données

---

Mais mon pauvre monsieur, je suis ingénieur en informatique à la retraite.
Je n'ai plus rien à apprendre, surtout venant de vous, qui avez une connaissance livresque.
Tout ce que vous savez faire, c'et troller en venant nous mettre vos bouquins.

Quand vous aurez les connaissances que j'ai, on reparlera de compétences.
A l'inverse de vous, je n'ai pas la science infuse, et j'ai lu vos liens.
Pour ainsi dire, la plupart date de 2006. Ne croyez-vous qu'il serait temps de les remettre à jour.

Citation:

---

Envoyé par SQLPRO

Vous discréditez sciemment ou vous êtes un réel imbécile ?

---

L'imbécile, c'et vous !!! Vous êtes incapable de supporter la contradiction.
Et vous n'avez aucun arguments à justifier pour défendre votre opinions.
Tout ce que vous savez faire, c'est rabaissez les autres et de nous donner les références de vos bouquins.

Citation:

---

Envoyé par ddoumeche

Ensuite, pourquoi ne le faites pas vous même au lieu de troller sur ces forums pour vendre vos bouquins ?

---

Tu le constates toi-même, ddoumeche, ce SQLPRO est un donneur de leçons, et il est incapable de fournir une seule information pertinente.
Je me demande même, s'il n'est pas interdit sur ce forum de faire de la publicité commerciale.

@+

Sujet temporairement verrouillé