Sachant qu'il suffit d'un rien pour perdre son site — erreur personnelle ou attaque externe, panne de serveur ou encore oubli de renouvellement de l'hébergement... — il est impératif de faire des sauvegardes complètes du site de manière régulière.

Pour cela, j'ai longtemps été adepte de la sauvegarde par ftp à laquelle j'ajoutais la sauvegarde manuelle de la base de données (voir cet article). Puis je suis passé à Akeeba backup, bien plus pratique à mon sens, que j'associe à LazyDbBackup. Akeeba backup est utilisé pour des sauvegardes complètes, le plus souvent hebdomadaires, et LazyDbBackup pour des sauvegardes de la base de données, quotidiennes voire multi-quotidiennes sur certains sites comme des e-commerces.

Pour commencer, il faut installer Akeeba backup comme n'importe quelle extension, en version gratuite ou commerciale, version à récupérer sur le site de l'auteur akeebabackup.com

Sur ce même site, on récupère aussi le fichier de langue française, tant qu'à faire, et on l'installe aussi comme une extension.

Puis on ouvre le menu "Composants->Akeeba backup" qui va proposer une configuration automatique (si elle n'est pas lancée automatiquement, il faut cliquer sur le bouton en haut de page). Celle-ci teste le serveur afin de définir la meilleure configuration possible. Une fois cette étape passée, on peut modifier le dossier de stockage des sauvegardes (par défaut "administrator/components/com_akeeba/backup") afin de le placer éventuellement hors du site, ce qui est plus sûr. Autre paramètre : le nombre de sauvegardes à conserver, par défaut 3, que je préfère augmenter surtout en phase de création de site.

En version Pro, il est possible, après sauvegarde, d'envoyer automatiquement le fichier sur un serveur externe, en en conservant ou non une copie locale, le fichier de décompression "kickstart", du même auteur, étant capable d'importer ces sauvegardes depuis une adresse distante.

Dans les deux versions Depuis la version 7.0, avec la version commerciale il est aussi possible d'automatiser les sauvegardes en l'autorisant dans les paramètres généraux du composant, puis en choisissant une des diverses méthodes à utiliser dans une tache cron, régulièrement déclenchée.

Lorsqu'on utilise une seule base de données pour plus d'un site sur le même serveur, il faut penser à passer par le bouton d'exclusion de tables afin de ne pas sauvegarder les tables d'un autre site. Les sauvegarder n'est pas un problème, mais si on a besoin de restaurer, elles seront restaurées aussi et pourraient faire perdre les modifications faite sur l'autre (les autres) site(s) entre la sauvegarde et la restauration du premier.

Faire une sauvegarde manuelle est très simple : il suffit de cliquer sur le bouton correspondant au profil par défaut (ou d'un profil complémentaire, lorsqu'on en a créé plus d'un, ce qui n'est pas souvent le cas), ou encore sur le bouton "Sauvegarder" (si on veut ajouter un commentaire) et d'attendre que le processus se termine.

Une fois la sauvegarde terminée, il est conseillé de s'assurer qu'elle n'est pas corrompue. Pour cela, il faut l'importer soit en local afin de la décompresser avec Akeeba Extract Wizard (n'est plus disponible en 2020) ou avec kickstart (en local, j'utilise maintenant sous Windows 10 UwAmp en version non installable, juste décompressée dans son dossier) , soit sur un autre serveur distant (décompression par kickstart) et restaurer une copie du site. On saura avec Extract wizard si l'extraction s'est faite sans erreur, dans le second cas si la copie est fonctionnelle. Si c'est bien le cas, on a donc bien une sauvegarde fiable qu'on pourra utiliser en cas d'incident grave sur le site.

Impératif ! En local, il est impératif de neutraliser le fichier .htaccess distant (à noter que depuis ds versions récentes, si un .htaccess est repéré, le processus de restauration le remplace par défaut par un .htaccess standar) et de désactiver la réécriture au vol des URL, sauf si on a paramétré le serveur pour activer le "mod_rewrite" auquel cas il est conseillé de remplacer le contenu du fichier .htaccess par celui du fichier htaccess.txt (ce que fait donc maintenant le script de restauration) si on veut continuer à utiliser la réécriture au vol (sans "index.php" dans les adresses), les instructions contenues dans le fichier .htaccess distant pouvant comporter des instructions spécifiques au site distant et incompatibles avec le site local.

Bien sûr, cette vérification de la qualité des sauvegardes, qui devrait être systématique, est à mon sens irréalisable, mais doit cependant être faite de temps à autre, histoire d'en perdre le moins possible en cas d'incident grave sur le site.