After an unexpected power cut during the weekend, both Drobo FS at work restarted (21 hours later when the power was restored) but the samba/windows shares could not be accessed.

When I tried my droboStatus script, everything was displayed normally, except for one line:

As the linked page does not give an answer, it seems that it means that everything is ok after a file system check (fsck) but the shares do not work.

A simple reboot with the button at the back of the Drobos was enough to get everything on line again.

WordPress is used for a small website in my workplace. The server must use a proxy to connect to the web, and this is necessary for many plugins and for updates.

As explained in the documentation, the proxy is declared in wp-config.php

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

Since 3.8.1, the Dashboard does not show any update available (even if now 3.9.1 is out). No error message is displayed either.
I had to run wireshark to see what was happening :

1. WordPress sends a POST request to https://api.wordpress.org/plugins/info/1.0
2. Squid proxy answers Error 501 : “Unsupported Request Method and Protocol”

It seems that the proxy does not support HTTPS POST requests. So I had to find where the https URL was defined in WordPress. It turns out it is in wp-includes/update.php. But the URLs are defined as http, and the following code is used (in three different places) to convert it to https if ssl is available :

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

I thus commented those :

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

And I could update the server. Of course, I will have to do that again after each update…

Five years ago I made backups of my data to three hard drives. When my desktop died, I used a small laptop where I could not copy the 1+Tb of data stored on the backups.

Last week, I tried to copy back all the data from my laptop and the old data from my Backups onto a new computer.
Of the three backup disks, one was completely dead (it did not even power up), the second one worked but contained only a partial backup (it was a smaller disk), and the last one was apparently unreadable.

When this disk was plugged in, ‘dmesg’ was printing ‘Read errors’ all over the place, and Linux did not detect any partition on the disk. I thought I had lost 1Tb of data…

Then I found this, this and this.

And here is how I got almost everything back :

1. Plug in the dying disk (/dev/sdi)
2. In dmesg, I had hundreds of lines such as :

   [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. Make an image of the disk, ignoring read errors (replaced by 0’s in the file). This took 5 days for 1Tb.

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

4. Repair the partition table using testdisk (sudo apt-get install testdisk)
   It found one Linux (Ext3fs) partition filling up the disk image, asked to rewrite the partition table and saved the result.

   testdisk /home/myself/backupdisk.bin

5. Display the partition table in the disk image

   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. Set up the partition using the loopback device
   From the partition table, the partition begins at block 63 and units are 512 bytes. So the offset of the partition in the image is 32256 = 63*512. We can now set the /dev/loop0 partition as the first partition of the disk image

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

7. Check and repair the partition
   Option -y is used to force fsck to correct errors (without it, it asked for confirmation thousands of times, such as “Free inodes count is wrong for group n°7230 (16384, should be=16378). Correct ?)

   sudo fsck  -y /dev/loop0
   
   #  This ends with :
   /dev/loop0: ***** FILE SYSTEM WAS MODIFIED *****
   /dev/loop0 : 968660/122109952 files (3.9% non contiguous), 234454083/244190000 blocks

8. Mount the partition and access files

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

9. Explore files and copy them from /mnt/backupdisk
10. Unmount the partition et free the loopack device

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

Goal : Saving MySQL databases to a samba (windows share) server (Ubuntu Linux).

Relatively easy thing to do, but I will keep this here if I need to do it again someday… Here is the code of a small bash script used to do that (not optimal, I know). But first, to get things started  :

# Create a backup user to get read access to the database
mysql -u root -p
mysql> GRANT SELECT,RELOAD,LOCK TABLES ON *.* TO ‘backup_user’@’localhost’;

# Add the root user to the mysql group (as cron jobs run as root)
sudo usermod -a -G mysql root

# Allows read access to users of the mysql group for the directories of mysql data files
sudo find /var/lib/mysql -maxdepth 1 -type d -exec chmod g+r \{\} \;
# List all databases
mysql -u backup_user -B -e ‘show databases;’
# Backup one database
mysqlhotcopy -u backup_user databaseName /TheBackupDir/
# Backup all databases -> this does not work as some databases listed do not really exist !
for i in `mysql -u backup_user -B -e ‘show databases;’`; do   echo $i; mysqlhotcopy -u backup_user “$i” /TheBackupDir/ ; done

On the samba share, create a directory WebServerBackup and in this directory, an empty file autoBackup to allow the script to confirm that the right directory is mounted before backing the database to it.

The samba share used here does not need a username or password, but adding user=”myuser”,password=”mypassword” to the list of options when mounting the share should work nicely in other cases.

The /var/www dir will be saved as is (no old versions) in the same directory and kept syncrhonized by rsync. A log will be written in /var/log/backup.log

Here is the script itself :

#!/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

Finally, the script (executable, thanks to a sudo chmod a+x /usr/bin/backupWebsite.sh) is linked to from the directory /etc/cron.daily/  so it will launch automatically once a day. The .sh is removed in the link name as some versions of cron don’t execute .sh files.

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