2

I was editing a script I wrote some time ago to automatically backup the contents of my Raspberry Pi SD card, and in the course of editing, I missed a "/", and so here is the entire shell script:

#!/bin/bash
date
echo BACKING UP RASPBERRY PI
sudo dd if=/dev/mmcblk0p2  of=/media/USBDRIVE/RPi-Backups/RPi-Backup-$(date +"%m_%d_%Y").img bs=10M
echo COMPRESSING RASPBERRY PI BACKUP
sudo gzip -9 -c /media/USBDRIVE/RPi-Backups/RPi-Backup-$(date +"%m_%d_%Y").img > /media/USBDRIVE/RPi-Backups/RPi-Backup-$(date +"%m_%d_%Y").img.gz

and once I did this, I realized that I made a mistake and stopped the script. I checked the directory where my backups are kept, and they were all gone. What was strange, was that there was as much space taken up in the drive as there had been before I ran the script, about half the 500 GB USB drive.

As far as I can tell, the backups are gone, which kind of undermines the whole point of the backups.

Is there a way to recover these files?

If not, is there a way to recover the space without wiping and reformatting the drive?

Update 1/2015: This has since happened to me on a brand new drive, different make and model, in both cases making over 200 GB simply disappear, with the space still somehow in use. To happen twice in a row, with two different drives made by two different manufacturers seems fairly unlikely. Could there be something in my backup script causing these failures? If the files are truly gone, why is the directory still there? Why does the disk and OS still think that the same amount of space is still in use as opposed to just calculating it as if the files were wiped (since they are apparently gone)?

  • 1
    That doesn't make sense to me. Multiple slashes are just ignored by the VFS. I just tried that with dd: no problem. And why should a problem with the input path delete your backups? You should run your script through bash -vx script and show us the output (edit your question). – Hauke Laging May 20 '14 at 3:40
  • 1
    Can we see the rest of the command? It's the of part that can overwrite, not the if. In any case, as Hauke pointed out, the // is irrelevant, it will be ignored. – terdon May 20 '14 at 3:41
  • 1
    There's absolutely no way that this script would delete any files in your backup directory. It will create the .img and .img.gz files, but that's the only modifications it does. Something else deleted them. – Barmar May 20 '14 at 4:41
  • 2
    How could this code cause something to happen 30 seconds after the script finishes? Maybe there's a cron job or a program using inotify that's cleaning up the backup directory. – Barmar May 20 '14 at 5:11
  • 1
    @Gilles Absolutely possible that there was something else missed in my script, but I'm not recognizing anything that looks odd (see above). Also, after re-running, and stopping the script, as I mentioned I can't see it in the GUI, and when I try to ls the directory, I get "ls: reading directory /media/USBDRIVE/RPi-Backups: Input/output error". Does the fact that the other directories and everything else on the drive is fine give any more clues? It seems odd to me that the issue is confined to just one directory. And since it seems that //dev means nothing, should I move to a new question? – iwantmyphd May 21 '14 at 3:26
1

ls: reading directory /media/USBDRIVE/RPi-Backups: Input/output error

This is your problem. Always read error messages! The files didn't vanish: they didn't make it, and the dd or gzip process would also have exited with an I/O error.

This error can be a bit generic sometimes, but here, you're dealing with a straightforward filesystem-over-hardware situation. An I/O error means that the hardware is defective. There may be additional messages in the system logs. Usually, the problem is with the hard disk. Sometimes the cable goes bad — try another cable (it rarely solves anything, but it's cheap). It can also be a controller problem, or even a driver problem, but these tend to turn up pretty quickly, not the 50th time you use the drive.

  • Thanks for identifying this! Yeah, it didn't occur to me at first to check the directory from the console since I was in the GUI while writing and running the script, but right you are. Since it seems to be a hardware issue, would this be something like bad blocks/sectors, since the rest of the files are intact? Also, I've had this external drive for about 9 months, so as you said, it's an issue that tends to happen early. I think however, it's still under warranty, so perhaps I can get a replacement/refund. Is there anything I can run to get more specifics on what went wrong? – iwantmyphd May 21 '14 at 13:17
  • @iwantmyphd Check the kernel logs (/var/log/kern.log). Look for messages containing sdb or whatever the device letter for the disk is. – Gilles May 21 '14 at 20:42
  • Couldn't find a kern.log in /var/log (or elsewhere), and all the other log files I checked (user.log, auth.log, daemon.log) had nothing about it. I did see a /var/log.hdd, which was an empty file. Where else might it be? The good news is, it's still under warranty from my documentation, I'd just like my backups back! At least everything else is intact (for now)! – iwantmyphd May 21 '14 at 23:58
  • @iwantmyphd What unix variant/distribution is it? There's no standard for log location — /var/log/kern.log is common but not universal. Try grep sdb /var/log/* (or grep sda /var/log/* or whichever it is). – Gilles May 22 '14 at 0:05
  • Sorry I forgot to mention that. I'm running Raspbian (based on Debian Wheezy) and a Raspberry PI. – iwantmyphd May 22 '14 at 0:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.