web-dev-qa-db-fra.com

Le moyen le plus sûr d'automatiser les sauvegardes WordPress

J'utilise plus de 20 sites sur un environnement de cloud partagé Linux. À l'heure actuelle, ma société d'hébergement effectue des sauvegardes quotidiennes hors site. Cependant, ceux-ci ne sont conservés que 30 jours.

Cela fonctionne très bien, mais que se passe-t-il si l'un de mes sites est infecté et que je ne l'ai pas remarqué pendant 60 jours? Je resterais avec une série de sauvegardes qui ont toutes été infectées.

Cela m'a amené à mener des recherches sur les sauvegardes automatisées et les plug-ins de sauvegarde.

J'ai trouvé 2 excellentes solutions premium ( Updraft Plus & BackUpWordPress ) qui va sauvegarder chaque site et en envoyer une copie à Google Drive.

Mes questions

1) Si un site est piraté avec l’un ou l’autre des plugins installés, que peut faire un pirate informatique avec les informations de l’API de cloud (par exemple, Google Drive) que j’ai fournies? L'attaquant pourrait-il accéder aux sauvegardes ou ajouter des fichiers aux sauvegardes?

2) Avec Updraft Plus , ma base de données sera cryptée, mais est-ce vraiment une bonne idée de placer ma base de données sur une plate-forme en nuage telle que Google Drive?

3) Existe-t-il une solution plus sûre pour sauvegarder votre site WordPress? configurer un travail cron et conserver des sauvegardes locales?

pluginssecuritybackup
1
Sam

(Réponse partielle, car je connais AWS et non Google Drive.)

Avoir une base de données WordPress stockée quelque part sur un service cloud n’est, à mon avis, pas pire que d’héberger le site sur un serveur virtuel ou cloud (les plates-formes de virtualisation vous permettent de réinitialiser le mot de passe root du serveur Toute la machine est à risque si quelqu'un découvre la connexion de votre panneau de contrôle.)

Assurez-vous que vous avez suivi les précautions de sécurité de base pour votre serveur et considérez également le authentification à deux facteurs plugin qui, même avec sa sécurité la plus basse, enverra un mot de passe à usage unique à l'adresse de messagerie de l'utilisateur lorsqu'il se connectera (l'adresse de messagerie de l'utilisateur devra également être piratée pour que le pirate puisse accéder à le tableau de bord WordPress.)

Personnellement, beaucoup de mes sites utilisent Linode. J'utilise leur service de sauvegarde par mesure de précaution, mais vous ne pouvez restaurer que l'intégralité du lecteur. Il n'est donc d'aucune aide si vous supprimez accidentellement un seul fichier ou répertoire. et voulez laisser intact tout ce qui a été changé depuis la sauvegarde.

backup2l est un utilitaire de sauvegarde en ligne de commande gratuit/simple/fiable qui vous permet de récupérer des fichiers individuellement. Il utilise des commandes Linux bien connues telles que tar et gzip. (Il existe des packages pour cela dans la plupart des distributions, pas besoin d'installer manuellement.)

Par défaut, il s'exécute tous les jours, mais il effectue des sauvegardes incrémentielles pour vous permettre de le configurer aussi souvent que vous le souhaitez.

J'utilise le code suivant dans mon /etc/backup2l.conf pour vider automatiquement les bases de données SQL avant l'exécution de la sauvegarde:

# This user-defined bash function is executed before a backup is made
PRE_BACKUP ()
{
    # e. g., shut down some mail/db servers if their files are to be backup'ed

    # On a Debian system, the following statements dump a machine-readable list of
    # all installed packages to a file.

    echo "  writing dpkg selections to /root/.dpkg-selections.log..."
    dpkg --get-selections | diff - /root/.dpkg-selections.log > /dev/null || dpkg --get-selections > /root/.dpkg-selections.log

    echo " dumping databases"
    for i in /var/lib/mysql/*/; do
        name=`basename $i`

        # get username + password
        user=$(grep user /etc/mysql/debian.cnf | awk '{print $3}' | head -n 1)
        pass=$(grep pass /etc/mysql/debian.cnf | awk '{print $3}' | head -n 1)

        # do the dump
        mysqldump --user="$user" --password="$pass" --ignore-table=mysql.event $name | gzip > /var/backups/mysql/$name.gz
    done

}

Ensuite, dans POST_BACKUP, je télécharge les fichiers de sauvegarde dans un compartiment Amazon S3 avec s3cmd :

# This user-defined bash function is executed after a backup is made
POST_BACKUP ()
{
    # e. g., restart some mail/db server if its files are to be backup'ed/
    /usr/bin/s3cmd sync -c /home/myhomedir/.s3cfg --delete-removed /var/backups/localhost/ s3://my-bucket-name/
}

AWS a " Versioning " ce qui signifie que si quelqu'un accède à votre serveur et utilise les informations d'identification IAM pour supprimer les fichiers de sauvegarde de votre compartiment, vous devez toujours être en mesure de les récupérer.

1
William Turrell