Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-Marc Molina
Antoun a écrit/wrote :
par exemple... en l'occurence, j'ai créé ce script suite à la suppression de la table principale par le webmaster, lors d'une fausse manouvre :-|
C'est une sécurité en plus mais il faudrait peut-être mieux revoir la conception de l'interface d'admin. Si c'était à partir du gestionnaire de la BDD là il a fait très fort :). Une solution encore plus radicale consisterait simplement à ne pas donner ce droit de suppression... même au webmaster... qui n'est pas l'admin de la BDD après tout.
-- Jean-Marc.
Antoun a écrit/wrote :
par exemple... en l'occurence, j'ai créé ce script suite à la
suppression de la table principale par le webmaster, lors d'une fausse
manouvre :-|
C'est une sécurité en plus mais il faudrait peut-être mieux revoir la
conception de l'interface d'admin. Si c'était à partir du gestionnaire de la
BDD là il a fait très fort :). Une solution encore plus radicale
consisterait simplement à ne pas donner ce droit de suppression... même au
webmaster... qui n'est pas l'admin de la BDD après tout.
par exemple... en l'occurence, j'ai créé ce script suite à la suppression de la table principale par le webmaster, lors d'une fausse manouvre :-|
C'est une sécurité en plus mais il faudrait peut-être mieux revoir la conception de l'interface d'admin. Si c'était à partir du gestionnaire de la BDD là il a fait très fort :). Une solution encore plus radicale consisterait simplement à ne pas donner ce droit de suppression... même au webmaster... qui n'est pas l'admin de la BDD après tout.
-- Jean-Marc.
Jean-Marc Molina
Microbug a écrit/wrote :
Intéressant, mais n'est ce pas trop couteux de gérer cela en php ? (en terme de performance)
Tant que ça reste une opération quotidienne qui se est lancée à minuit... ça va :).
Tu vas me dire que tout dépends de la taille de la base, c'est sûr :) (perso je travaille sur un site énorme, pdafrance.com , et nous utilisons pour les sauvegardes un service proposé par l'hébergueur, et je pense que ta solution ne marcherait pas trop sur un tel site non ?)
En effet il faut mieux se reposer sur son hébergeur mais il est toujours bon de savoir comment les sauvegardes sont effectuées... on a parfois des surprises. Pour les paranos vous pouvez même provoquer un faux crash de votre base et voir si leur solution de restoration fonctionne... indispensable à vrai dire car en cas de crash si la restoration ne fonctionne pas... tout est foutu.
Fonctionnalités : - Mirroring des disques sur lesquels le site est hébergé (solution RAID) - Sauvegarde quotidienne - Mirroring de la base si pas de solution RAID (à la maison par exemple)
Généralement les bons hébergeurs ont des serveurs en RAID-5 (disque principal copié sur plusieurs disques, en cas de crash d'un disque... le serveur continue à tourner, il suffit de remplacer le disque défaillant), et les sauvegardes sont quotidiennes (généralement lancées à l'heure où les fantômes viennent pourrir les serveurs).
-- Jean-Marc.
Microbug a écrit/wrote :
Intéressant, mais n'est ce pas trop couteux de gérer cela en php ?
(en terme de performance)
Tant que ça reste une opération quotidienne qui se est lancée à minuit... ça
va :).
Tu vas me dire que tout dépends de la taille de la base, c'est sûr :)
(perso je travaille sur un site énorme, pdafrance.com , et nous
utilisons pour les sauvegardes un service proposé par l'hébergueur,
et je pense que ta solution ne marcherait pas trop sur un tel site non
?)
En effet il faut mieux se reposer sur son hébergeur mais il est toujours bon
de savoir comment les sauvegardes sont effectuées... on a parfois des
surprises. Pour les paranos vous pouvez même provoquer un faux crash de
votre base et voir si leur solution de restoration fonctionne...
indispensable à vrai dire car en cas de crash si la restoration ne
fonctionne pas... tout est foutu.
Fonctionnalités :
- Mirroring des disques sur lesquels le site est hébergé (solution RAID)
- Sauvegarde quotidienne
- Mirroring de la base si pas de solution RAID (à la maison par exemple)
Généralement les bons hébergeurs ont des serveurs en RAID-5 (disque
principal copié sur plusieurs disques, en cas de crash d'un disque... le
serveur continue à tourner, il suffit de remplacer le disque défaillant), et
les sauvegardes sont quotidiennes (généralement lancées à l'heure où les
fantômes viennent pourrir les serveurs).
Intéressant, mais n'est ce pas trop couteux de gérer cela en php ? (en terme de performance)
Tant que ça reste une opération quotidienne qui se est lancée à minuit... ça va :).
Tu vas me dire que tout dépends de la taille de la base, c'est sûr :) (perso je travaille sur un site énorme, pdafrance.com , et nous utilisons pour les sauvegardes un service proposé par l'hébergueur, et je pense que ta solution ne marcherait pas trop sur un tel site non ?)
En effet il faut mieux se reposer sur son hébergeur mais il est toujours bon de savoir comment les sauvegardes sont effectuées... on a parfois des surprises. Pour les paranos vous pouvez même provoquer un faux crash de votre base et voir si leur solution de restoration fonctionne... indispensable à vrai dire car en cas de crash si la restoration ne fonctionne pas... tout est foutu.
Fonctionnalités : - Mirroring des disques sur lesquels le site est hébergé (solution RAID) - Sauvegarde quotidienne - Mirroring de la base si pas de solution RAID (à la maison par exemple)
Généralement les bons hébergeurs ont des serveurs en RAID-5 (disque principal copié sur plusieurs disques, en cas de crash d'un disque... le serveur continue à tourner, il suffit de remplacer le disque défaillant), et les sauvegardes sont quotidiennes (généralement lancées à l'heure où les fantômes viennent pourrir les serveurs).
