Stratégie de sauvegarde bdd ?

[Zecat]

Hello les wrnautes du dimanche ...

Sur un site j'ai mis enplace une sauvegarde de la bdd a deux niveaux :

1 - manuelle : dans son espace d'admin, l'admin a un lien "faire une sauvegarde" (ca boucle sur les table, fiches et champs), ca fabrique in .sql.gz par table et ca regroupe tout dans un .zip. J'affcihe le deroulement de la sauvegarde et 2 liens : 1 pour telecharger le .zip en local et l'autre pour supprimer la sauvegarde du serveur (pour pas laisser trainer). Jusque la tout va bien.

2 - automatique : un cron lancé chaque jour a heure regulière qui fait la meme sauvegarde (mais dans un repertoire différent bien sur). Ce qui ne manque pas de poser un pb de securité puisque le zip traine ainsi sur le disque tant qu'on est pas venu le telecharger et le supprimer du serveur... Et la la question est : avez vous mis aussi en place ce type de sauvegarde auto et quelle stratégie avez vous adopté pour contourner ce pb ?

 

[nervusdm]

Au niveau de la sauvegarde auto, pourquoi ne pas envoyer ton fichier zip de la BDD en pièce jointe par mail ? ( en te créant limite un email gmail que pour ça ^^ )
Ou alors, crypter le zip ( mdp ). Bon la deuxième partie je ne sais pas faire, mais ça doit se trouver sur php classes.

 

[spout]

J'utilise la sauvegarde auto avec http://www.backup-manager.org/
Sinon RSYNC est parfait pour faire des backups.

 

[UsagiYojimbo]

Et pourquoi ne pas créer ce fichier dans un dossier non accessible ?

 

[Zecat]

Et pourquoi ne pas créer ce fichier dans un dossier non accessible ?

A priori, les dossiers sont deja non accessibles en direct et meme si je renforce la protection du dossier avec un password, ca change rien sur le fond : si pour une raison ou une autre un margoulin accède au ftp, il a de fait aussi la bdd ... (style les récents chevaux de troie qui choppaient tes accès filezila ...).

La démarche cryptage (limitée a quelques champs stratégiques) évoquée plus haut me semble plus aller dans le sens de ce que je veux couvrir (quitte a compliquer une éventuelle restauration).

 

[chtipepere]

Personnellement, un backup auto est effectué et envoyé sur un autre serveur via scp.
Le(s) serveur(s) de production n'ont pas à conserver ce genre de fichiers. Les backups sont fait au cas où une mauvaise manipulation est effectuée, mais aussi en cas de problème disque.
Donc en conservant le backup sur le même disque, si le disque lâche, tout est perdu.

D'ailleurs, tu parles de mise en place de cron, est-ce un serveur dédié ?
Si oui, tu peux très bien déplacer ton archive en dehors des répertoires accessibles via ftp.

 

[fandecine]

Lorsque l'on parle de sécurité il faut voir les choses globalement.

La première question à se poser est "à quoi sert le FTP ?"

Si c'est juste pour uploader les sources du site il existe d'autres solution en sftp (protocole supporté par fillezilla et autres logiciel du genre) dans ce cas FTP ne sert plus et le supprimer limitera les failles de sécurité potentielles

Ensuite pour ce qui est du backup, comme cela a été dit précédemment, la meilleure solution consiste à déporter le backup sur un autre serveur (si on dispose d'un autre serveur bien sur)

L'idéal étant même d'avoir une image du site complète (html+php+bdd) sur un autre serveur et d'avoir un IP failover. En cas de pépin, on fait pointer l'IP failover sur l'autre serveur qui a été configuré pour et le site reste accessible pendant qu'on corrige le problème.

 

[YoyoS]

Perso, j'ai un petit script bash en CRON qui envoie les backups (gzip des sources et bdd) avec historique de 30jours sur le ftp backup OVH

 

[spout]

Idem que YoyoS mais avec Backup-Manager.

 

[Zecat]

Personnellement, un backup auto est effectué et envoyé sur un autre serveur via scp.
Le(s) serveur(s) de production n'ont pas à conserver ce genre de fichiers. Les backups sont fait au cas où une mauvaise manipulation est effectuée, mais aussi en cas de problème disque.
Donc en conservant le backup sur le même disque, si le disque lâche, tout est perdu..

Nou ssommes bien d'accord ...

D'ailleurs, tu parles de mise en place de cron, est-ce un serveur dédié ?
Si oui, tu peux très bien déplacer ton archive en dehors des répertoires accessibles via ftp.

Non pas un dédié, juste un mutu ovh perso.

 

[Zecat]

Perso, j'ai un petit script bash en CRON qui envoie les backups (gzip des sources et bdd) avec historique de 30jours sur le ftp backup OVH

Tu me fais suivre ? ca m'interesse ... C'est la premiere fois que je bosse sur un site (d'un pote) hebergé sur un mutu ovh et donc je connais mal toutes les possibilités

 

[spout]

http://www.dansteph.com/backupftp.php

 

[_Soul]

J'ai un truc du genre:

DBUSER="lolol"
DBPASS="lololol"
DATEFORMAT=`date +%d-%m`
FILEOUTPUT="backup-sql.sql"
mysqldump --user=$DBUSER --password=$DBPASS --all-database > $FILEOUTPUT

Et après tu l'envoie par mail.

Pour les fichiers vu que c'est un peut plus gros j'ai des comptes ftps sur des gros hébergeurs genre oron pis j'y upload dessus en chiffré.

 

[YoyoS]

C'est celui de spout, voila

 

[spout]

J'avais bien deviné :mrgreen:

 

[YoyoS]

Il trainait sur le forum ovh non ?
En tout cas bien efficace, tourne depuis up 375 days

 

[Leonick]

si pour une raison ou une autre un margoulin accède au ftp, il a de fait aussi la bdd ...

si il accède au ftp, il aura aussi accès aux identifiants bdd utilisés dans tes scripts, non ?

 

[Zecat]

si pour une raison ou une autre un margoulin accède au ftp, il a de fait aussi la bdd ...

si il accède au ftp, il aura aussi accès aux identifiants bdd utilisés dans tes scripts, non ?

arfffff cemafoivré :roll:

Problématiques ces problèmes de sécurité :!:

 

[YoyoS]

l'avantage du ftp backup ovh c'est que tu ne peux y acceder que depuis ton serveur. Donc il faut avoir obligatoirement le mot de passe root ou compte backup pour aller fouiner dans tes backups ;p

 

[Zecat]

l'avantage du ftp backup ovh c'est que tu ne peux y acceder que depuis ton serveur. Donc il faut avoir obligatoirement le mot de passe root ou compte backup pour aller fouiner dans tes backups ;p

Ouep je vais m'orienter vers cela