Après une coupure de courant au cours du week-end, les deux Drobo FS au boulot ont redémarré quand le courant est revenu (21 heures plus tard). Par contre, les dossiers partagés amba/windows n’étaient pas accessibles.

Quand j’ai essayé mon script droboStatus, tout était affiché normalement, mis à part une ligne :

Comme la page en lien ne donne pas de réponse pour ce code, il semble que le status 98304 correspond à un état où tout fonctionne bien mais où les partages de fichier sont désactivés après uné vérification du disque (fsck).

Un simple redémarrage des drobos à l’aide du bouton arrière a suffit à revenir à un fonctionnement normal.

WordPress est utilisé pour un petit site web de mon boulot. Le serveur web qui l’héberge doit utiliser un proxy pour accéder au web, ce qui est nécessaire pour certains plugins et pour les mises à jour.

Le proxy est déclaré (comme spécifié dans la documentation) dans le fichier wp-config.php

define('WP_PROXY_HOST', 'myCache.fr');
define('WP_PROXY_PORT', '3128');

Depuis la version 3.8.1, le tableau de bord n’affiche aucune mise à jour disponible, alors que la version 3.9.1 est sortie. Idem pour les plugins. Aucun message d’erreur n’est affiché, y compris en forçant la vérification des mises à jour, et en activant les messages de debug de WordPress.
J’ai dû utiliser wireshark pour comprendre ce qu’il se passe :

1. WordPress envoit une requête POST vers https://api.wordpress.org/plugins/info/1.0
2. Le serveur proxy Squid répond avec une erreur 501 : « Unsupported Request Method and Protocol »

Il semble que le proxy ne supporte pas les requêtes POST en https. J’ai donc recherché où était définie l’URL https dans le code de WordPress. Elle se trouve dans wp-includes/update.php. Mais les URLs sont définies en http, et le code suivant transforme le protocole en https si ssl est disponible (à trois endroits différents):

if ( $ssl = wp_http_supports( array( 'ssl' ) ) )
                $url = set_url_scheme( $url, 'https' );

J’ai donc commenté ces lignes :

/**if ( $ssl = wp_http_supports( array( 'ssl' ) ) )
 $url = set_url_scheme( $url, 'https' );*/

La mise à jour a été détectée et elle s’est installée correctement. Bien sûr, je vais devoir refaire cette modification après chaque mise à jour…

I y a 5 ans j’ai sauvegardé mes données vers 3 disques durs externes. Quand mon PC fixe est mort, j’ai utilisé un petit portable sur lequel je ne pouvais pas copier le Téraoctet de données de mes sauvegardes.

La semaine dernière, j’ai essayé de récupérer les données du portable et les anciennes sauvegardes sur un nouveau PC.
Sur les 3 disques de sauvegarde, un était complètement mort (il ne tourne plus quand on le branche), le second fonctionnait mais ne contenait qu’une sauvegarde partielle (disque plus petit que les autres), et le dernier n’était apparemment pas lisible.

Au branchement du disque, ‘dmesg’ affiche des dizaines d’erreurs de lecture, et Linux ne détecte aucune partition sur le disque. J’ai cru avoir perdu 1To de données…

Puis j’ai trouvé ça, ça et ça.

Et voilà comment j’ai presque tout récupéré :

1. Brancher le disque mourant (/dev/sdi)
2. Dans dmesg, il y avait des centaines de lignes comme ceci :

   [200135.764454] Buffer I/O error on device sdi, logical block 9464
   [200160.490454] sd 9:0:0:0: [sdi] Unhandled sense code
   [200160.490457] sd 9:0:0:0: [sdi]  
   [200160.490458] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
   [200160.490460] sd 9:0:0:0: [sdi]  
   [200160.490461] Sense Key : Medium Error [current] 
   [200160.490463] sd 9:0:0:0: [sdi]  
   [200160.490465] Add. Sense: Data phase error
   [200160.490466] sd 9:0:0:0: [sdi] CDB: 
   [200160.490467] Read(10): 28 00 00 01 27 c0 00 00 08 00
   [200160.490472] end_request: I/O error, dev sdi, sector 75712

3. Faire une image du disque, en ignorant les erreurs de lecture (remplacées par des 0 dans le fichier). Ceci a pris 5 jours pour le disque de 1To.

   sudo dd if=/dev/sdi of=/home/myself/backupdisk.bin conv=noerror,sync

4. Réparer la table de partition en utilisant testdisk (sudo apt-get install testdisk)
   I a trouvé une partition Linux (Ext3fs) remplissant l’image de disque, a proposé de réécrire la table de partition et a sauvé le résultat.

   testdisk /home/myself/backupdisk.bin

5. Afficher la table de partition de l’image du disque

   sudo fdisk -lu /home/myself/backupdisk.bin
   Disk /home/myself/backupdisk.bin: 1000.2 GB, 1000204886016 bytes
   255 têtes, 63 secteurs/piste, 121601 cylindres, total 1953525168 secteurs
   Unités = secteurs de 1 * 512 = 512 octets
   Taille de secteur (logique / physique) : 512 octets / 512 octets
   taille d'E/S (minimale / optimale) : 512 octets / 512 octets
   Identifiant de disque : 0x00000000
   Périphérique Amorçage  Début         Fin      Blocs    Id. Système
   /home/myself/backupdisk.bin1   *          63  1953520064   976760001   83  Linux

6. Définir la partition avec le périphérique loopback (« rebouclage »)
   D’après la table de partition, la partition commence au bloc 63 and l’unité est de 512 octets. Donc le début de la partition dans l’imageest à 32256 = 63*512 octets. On peut maintenant définir la partition /dev/loop0 pour qu’elle pointe vers la première partition de l’image du disque

   sudo losetup -o 32256 /dev/loop0  /home/myself/backupdisk.bin

7. Vérifier et réparer la partition
   L’option -y est utilisée pour forcer fsck à corriger les erreurs sans poser de question (sinon il demande des milliers de fois de confirmer, par exemple « Le décompte des i-noeuds libres est erroné pour le groupe n°7448 (16384, décompté=16334). Corriger ? »)

   sudo fsck  -y /dev/loop0
   
   #  Ca se termine par:
   /dev/loop0: ***** LE SYSTÈME DE FICHIERS A ÉTÉ MODIFIÉ *****
   /dev/loop0 : 968660/122109952 fichiers (3.9% non contigus), 234454083/244190000 blocs

8. Monter la partition

   sudo mkdir /mnt/backupdisk
   sudo mount /dev/loop0 /mnt/backupdisk

9. Accéder aux fichiers et les copier depuis /mnt/backupdisk
10. Démonter la partition et détacher le périphérique loopback

    sudo umount /mnt/backupdisk
    sudo losetup -d /dev/loop0

Objectif : Sauver les bases de données MySQL vers un « partage windows » (ici un serveur Samba) depuis un serveur Ubuntu Linux.

On conservera une sauvegarde par jour avec trente jours d’historique.
C’est quelque chose de relativement simple mais que je garde sous la main ici au cas où je devrai le refaire… Voici le code d’un petit script bash script fait rapidement (pas optimal, je sais). Mais pour commencer, il faut :

# Créer un utilisateur de la base de données avec accès en lecture pour les sauvegardes
mysql -u root -p
mysql> GRANT SELECT,RELOAD,LOCK TABLES ON *.* TO ‘backup_user’@’localhost’;

# Ajouter root au groupe mysql (car cron lance les tâches en tant que root)
sudo usermod -a -G mysql root

# Autoriser l’accès en lecture aux fichiers de mysql pour les utilisateurs du groupe mysql
sudo find /var/lib/mysql -maxdepth 1 -type d -exec chmod g+r \{\} \;
# Lister les bases de données
mysql -u backup_user -B -e ‘show databases;’
# En sauvegarder une (pour tester)
mysqlhotcopy -u backup_user databaseName /TheBackupDir/
# Sauver toutes les bases -> Ca ne marche pas car certaines bases listées ne sont pas accessibles
for i in `mysql -u backup_user -B -e ‘show databases;’`; do echo $i; mysqlhotcopy -u backup_user « $i » /TheBackupDir/ ; done

# Sur le partage samba, créer un répertoire WebServerBackup et ajouter un fichier vide autoBackup pour que le script puisse détecter qu’il a accès au bon répertoire, et qu’il a été monté correctement avant de lancer la sauvegarde.

Le partage windows utilisé ici n’a pas besoin de login et de mot de passe, mais dans le cas contraire, il suffit d’ajouter user= »myuser »,password= »mypassword » à la liste des options de la commande « mount ».

Le répertoire /var/www dir sera sauvé (sans conserver d’anciennes versions) dans le même répertoire, et sera mis à jour avec rsync. Un log sera écrit dans /var/log/backup.log

Voici le script :

#!/bin/bash
echo >> /var/log/backup.log
echo >> /var/log/backup.log
day=$(date +%d-%m-%Y_%Hh%M)
# List of databases to backup. Unfortunately, 
#   mysql -u backup_user -B -e 'show databases;'
#   lists system databases that cannot be saved. Using manual list instead in the for loop
echo "-------------------------------------------------" >> /var/log/backup.log
echo "Beginning WebServer Backup -> Launching backupWebsite.sh" >> /var/log/backup.log
date -R >> /var/log/backup.log
mount -t cifs -o iocharset=utf8,file_mode=0777,dir_mode=0777 //MySambaServer/MySambaShare  /backupDisk
if [ -f "/backupDisk/WebServerBackup/autoBackup" ]
then
  rsync -rltp --del --stats  /var/www /backupDisk/WebServerBackup/www >> /var/log/backup.log # --del
  mkdir "/backupDisk/WebServerBackup/mysql_$day"
  # Backup all databases
  for i in 'mybase' 'wordpress' 'mysql'; 
    do 
      echo $i; mysqlhotcopy -u backup_user "$i" "/backupDisk/WebServerBackup/mysql_$day" >> /var/log/backup.log ;
    done
  # Remove the old database backups (more than 30 days)
  find /backupDisk/WebServerBackup -maxdepth 1 -type d -name "mysql_*" -mtime +30 -exec rm -rf \{\} \;
else
  echo "Echec du montage ! ***Pas de sauvegarde du serveur web !***" >> /var/log/backup.log
fi

umount /backupDisk

echo "WebServer BACKUP FINISHED (in //MySambaServer/MySambaShare/WebServerBackup )" >> /var/log/backup.log
date -R >> /var/log/backup.log
echo "**************************************************" >> /var/log/backup.log

Enfin, on met un lien vers ce script (rendu exécutable par un sudo chmod a+x /usr/bin/backupWebsite.sh) dans le dossier /etc/cron.daily/ pour qu’il se lance une fois par jour, mais sans l’extension .sh car certaines versions de cron ignorent les fichiers en .sh :

sudo ln -s /usr/bin/backupWebsite.sh /etc/cron.daily/backupWebsite