Showing posts with label USB drive. Show all posts
Showing posts with label USB drive. Show all posts

Tuesday, December 29, 2009

Ubuntu: Backup with Rsync

In a previous post, I got as far as concluding that rsync was the tool of choice for backing up my computer in Ubuntu 9.04. I didn't pursue it because I was short on time and patience for writing scripts at that point. But eventually the need for a regular backup system became acute. So this post logs the steps I took to make rsync and cron work for me.

First, here's what I wrote previously:
As an alternative to rdiff-backup, what people had actually mentioned more frequently was rsync. It did not have the incremental backup features of rdiff-backup, to my knowledge, but it seemed to be an established tool for backup purposes. So for now, at least, I thought I might try that instead. Once again, I did a Google search and got a package details page with no apparent link to any help files. Eventually I found what looked like the official rsync webpage and, after looking at their FAQs and some other pages, landed on their Examples page. It was intimidating.
This time, I went to their Documentation page. This gave me links to, among other things, Michael Holve's rsync tutorial. The tutorial said, "You must set up one machine or another of a pair to be an "rsync server" by running rsync in a daemon mode." I was curious, so I did a Google search for "what is daemon mode" and I got back, would you believe, exactly one page. One webpage in the entire known planet answered the question, "What is daemon mode?" Except it didn't really answer it. It just said, "It makes wget put standard output into a log file and not bug you while downloading." Accepting that as the best available answer (and ten points to the answerer!), I typed "rsync --daemon" in Ubuntu's Terminal and proceeded to the next step, "Setting Up a Server." After reading it, I decided it didn't seem to apply to me. It was for people who wanted to back up files between computers. I just wanted to back up to another drive.

So I went on to the tutorial's "Using Rsync Itself" section. Since I wasn't sure what daemon mode did, or if it was necessary, I killed that Terminal session and started another. I didn't know if that would shut off daemon mode, or if doing so was what I should do. I read the section and then checked another source of documentation, the rsync man page ("man" being short for "manual"). The man page would ordinarily be output in response to a Terminal command, but someone had put it here in html form, so that's what I used. It reminded me, first, to check Ubuntu's System > Administration > Synaptic Package Manager to make sure I had rsync already installed, here on my secondary computer. I searched Synaptic for rsync and got back a couple dozen listed programs; rsync was among them and was shown as being installed. I looked partway into the man page and got an answer to one question I had from the tutorial. So here's how I translated what the tutorial was telling me. First, the tutorial listed these lines:

rsync --verbose --progress --stats --compress --rsh=/usr/local/bin/ssh --recursive --times --perms --links --delete \
--exclude "*bak" --exclude "*~" \
/www/* webserver:simple_path_name

The first thing to know was that this all represented a single command line. It was too long to fit on one line, though, so apparently the trailing backslash said, "This line continues on the next line." The command would be typed into a file and saved as a script, not typed directly into Terminal. I didn't know why the first line didn't end with a backslash. I decided I would want to experiment with this in a relatively safe place -- with a junk directory on my secondary computer, perhaps -- to see what it was doing.

So as the tutorial explained it, the first line of this example told rsync how to proceed: verbosely (i.e., with lots of information about what it was doing), showing a progress report, with statistics. The rsh part was for encryption, to be used optionally if you were sending your stuff online to another computer. I wasn't, so I decided to try leaving that off. I also didn't want to compress the output, because that made the process slower and required more attention from the CPU.

The second line of the example, above, told rsync to recurse -- to work through all of my directories and subdirectories under the folder that I would be naming. It also told rsync to preserve file timestamps and file permissions -- so if, for example, a file was readable only by root on the source drive, it would be the same way on the target drive. The -- links command was an instruction to preserve symbolic links -- not sure what that meant -- and the --delete command, as I understood it, would tell rsync to delete anything on the target that wasn't on the source. So you'd have a mirror, and not just an accumulation of backups of files that you have deliberately trimmed out of your file collection.

The third line of the example told rsync not to bother copying some kinds of files. I liked the sound of that at first, but then I decided I would rather be able to do a Properties comparison of source and target and verify that both had exactly the same number of files. So I decided to leave out this line when I used rsync.

The fourth line of the example named the source and target locations. I wasn't going to be using it with a remote source or target, so mine was going to look somewhat different from this.

On that basis, here's what I assembled as a test version of the rsync example from above:

rsync --verbose --progress --stats \
--recursive --times --perms --links --delete \
/media/DATA/Source /media/DATA/Target

I created a Source subfolder in my DATA folder and put a TestFile.txt file into it. I also created a Target subfolder in DATA. Then I copied those three rsync lines into a file in Ubuntu's Text Editor (gedit) and saved it to Desktop as TestRun. To make it executable, I went into Terminal, typed "cd /home/ray/Desktop" and then "chmod +x TestRun" and then double-clicked on TestRun and said Run. And, you know, it worked. Just like that. Not exactly as intended -- I had not only TestFile.txt but also the whole Source folder underneath my Target folder -- but, yeah, there it was. I deleted the Target folder and ran it again and, sure enough, it created the Target folder and then inserted a copy of the Source folder into it. Excellent!

Now it was time to try something a little bolder. I wanted to see how it worked if I tried to copy the whole DATA folder to an external drive. This part was a little confusing. The external drive seemed to have two different names. If I looked in /media, its name was simply "disk." But if I hit the Computer icon in File Browser, it came up as "193.8 GB Media." I decided the latter sounded more specific, so I would try that first. So now the third line of my TestRun file read like this:

/media/DATA "/media/193.8 GB Media"

I used quotation marks because there were spaces in the name. I saved TestRun and double-clicked it again on the Desktop. It didn't seem to do anything. I realized that I had probably made a mistake in that line, and tried again like this:

/media/DATA "/193.8 GB Media"

That didn't do it either, so I tried again, without the leading slash:

/media/DATA "193.8 GB Media"

That still didn't work, so I tried the other approach:

/media/DATA /media/disk

Still nothing. I went into System > Administration > Partition Editor (GPartEd), wiped out the target partition, and recreated it as a FAT32 partition. Now the drive was totally invisible to Ubuntu. I went back into GPartEd and reformatted it as an ext3 partition. Then I realized: it was an IDE drive, so apparently it would not be recognized until I rebooted. I decided to reboot into Windows (I had a dual-boot system) and format it as NTFS. I named it 186GB (which seemed to be the net amount of space available in NTFS format) and rebooted into Ubuntu. I revised TestRun's last line again:

/media/DATA /media/186GB

and ran it again. This time, it seemed to be working -- the external 186GB drive was making noise -- but I wondered why I wasn't getting a verbose indication of what was going on. I guessed that, if I wanted the verbose information, I would have to execute rsync on the command line, not in an executable script. While I was rooting around for an answer to that question, I was reminded that I could also use the shorthand versions of these commands. So instead of typing --verbose into the script, I could just type -v and whatever other letters I needed. In this approach, the final contents of TestRun, which were as follows:

rsync --verbose --progress --stats \
--recursive --times --perms --links --delete \
/media/DATA /media/186GB

could instead be expressed like this, if I understood the man page's Options Summary section correctly:

rsync -vshlEPtrip --del --delete-excluded --force \
--exclude RECYCLER \
--exclude "System Volume Information" \
/media/DATA /media/186GB

In that version, I added a couple other options that seemed appropriate, and also told rsync to exclude (i.e., don't copy) those extra folders that Windows XP seemed to put on every drive. I revised TestRun along these lines and, when the external drive settled down and it looked like the foregoing TestRun process had ended, I ran it again. But it didn't seem to make any difference. The extra folders were still there. I had understood that it would delete them. Part of the problem seemed to be that I had not used the syntax correctly. I was supposed to use an equals sign: --exclude=RECYCLER. But another part of the problem was that it was not clear whether the "exclude" command was supposed to work with directories. It didn't seem so. The man page just referred to excluding files. I tried again with equals signs, but still no change. I posted a question on it, but the kind response was unfortunately not able to resolve the issue.

Next, I tried a modified version of TestRun on the primary computer. I went through several revisions and wound up with this version, which seemed to work:

rsync -vchlEtrip --progress --del --ignore-errors --force /media/CURRENT/ "/media/OFFSITE/P4 CURRENT"

The partition being backed up, in this case, was an ext3 partition named CURRENT, and the target to which it was being backed up was a USB external drive named OFFSITE. (Some weeks have passed since I started this post, so there may be some discontinuity in my writing at this point.)

I did not run this command as a script within a file called TestRun that I would start by double-clicking on it, because I discovered that you would only get the detailed output if you entered the rsync command on the command line. I was able to enter all of the foregoing rsync command on one line. I did not need the "exclude" commands because this was not an NTFS drive formatted by Windows. I still had ext3 "lost+found" and Trash folders that got copied over in this way, but they were small, so it was OK.

As I think I may have said before, I got the selected rsync parameters by typing "man rsync" at the command line. It did take some trial and error to get this particular set. The resulting backup, when checked by right-clicking and selecting Properties, seemed to be virtually identical.

When I ran that rsync command, it showed me lots of detail on what it was doing. It concluded with this message:
rsync error: some files could not be transferred (code 23) at main.c(977) [sender=2.6.9]
Eventually, however, I did figure out how to do it.  Here is an example of an rsync command that worked for me:
rsync -qhlEtrip --progress --delete-after --ignore-errors --force --exclude=/.Trash-1000/ --exclude=/lost+found/ /media/CURRENT/ /media/CURRBACKUP

This one would back up what Windows sees as drive D (named CURRENT) to a partition that Windows sees as drive G (named CURRBACKUP).  Both partitions had to be mounted in Ubuntu before this would work.  I used a similar command to copy a folder on CURRENT to a USB jump drive named KINGSTON.  That gave me a portable copy of the current state of that folder, ready to take along.

The next thing I needed to do was to back up my blogs.  I started by just wanting to be able to back up a webpage.  I had discovered that all of the posts on a Blogger (i.e., Blogspot) blog like this one could be displayed in a single webpage, at least if you had less than 1,000 posts.  To do that, you just needed to go to this URL:  http://blogname.blogspot.com/search?max-results=1000.  I wasn't sure what would happen if you entered a larger number than 1000.  So now that I had that webpage, I wanted to know how to save a copy of it automatically.  Strangely, at this point, Google searches for any of these sets of terms
ubuntu "back up a webpage"
rsync "back up a webpage"
rsync "copy a webpage"


produced zero hits.  Eventually, it started to look like this was because I was barking up the wrong tree.  As described in a separate post, it seemed that what I wanted for this purpose might be wget, not rsync.

Sunday, August 9, 2009

Trying to Use a FreeDOS USB Drive to Flash the BIOS via Ubuntu

I wanted to flash the BIOS on my Gigabyte motherboard. I downloaded the updated BIOS from Gigabyte's website. Now, how to flash the BIOS? In the past, I had always used floppy drives for BIOS updates. At this point, though, my last floppy disks were really old and I was not eager to risk BIOS corruption. This post describes the gyrations I went through before winding up with the floppy approach after all. To test my old floppy disk, I went to Ubuntu's Terminal utility and typed "gfloppy" and chose the Thorough formatting mode. This gave me "Error formatting track #0." Somebody suggested that this was because I already had the floppy inserted in the drive, so I ejected it and tried "gfloppy" again. This gave me "Unable to access the floppy disk." Now I inserted the floppy and clicked OK. But no, still the same error. Following a somewhat related discussion, I went to Synaptic and installed the pmount package. In Terminal, I typed "sudo pmount -h." That brought up some help information which told me that pmount was useful for mounting devices. Not quite what I needed. It seemed that there used to be a Floppy Formatter menu option in Ubuntu, but I wasn't finding that anymore; but then it seemed that this was just the fancy way of invoking gfloppy. Somebody else said that Linux can't handle a completely blank floppy, and suggested using these two command lines in that case: setfdprm -p /dev/fd0 1440/1440 fdformat /dev/fd0 The first line gave me an error indication, "The program 'setfdprm' is currently not installed. You can install it by typing sudo apt-get install fdutils." So I did that, and then tried these two lines again. This time, the first line went OK, but the second line said, "Device or resource busy." I ejected the floppy and tried again, but this time I got, "No such device or address." David Haas suggested that automount might be the problem so, following his advice, I typed "gedit /etc/fstab" and looked for the line for /dev/fd0 (i.e., for the floppy drive). But its default was already "noauto" (he thought maybe automount was the problem, and advised setting it to noauto to prevent that), so that wasn't the solution. But I tried what the other person said in response to his advice, which was to enter "sudo umount /dev/fd0" and then I tried again with the fdformat command (above) and, you know, it worked! Ah, but it had occurred to me that making my BIOS update depend upon something as flaky as a floppy drive might not be the ideal approach. Surely Gigabyte offered a way to flash the BIOS from some other kind of drive? Yes, as it turned out, they did - but only if you were running Windows. Since I had a double-boot system, that could be arranged. But what about booting from a USB drive? Andrew provided instructions on how to create a bootable Windows or Linux USB drive using UNetbootin. I decided to do that once I could find where I had put my larger USB drive (1GB minimum required). Aside from Andrew's approach, the UNetbootin instructions looked kind of complicated. For now, though, as Linerd said, sometimes you just need a DOS boot disk. Following his instructions, I dedicated my smallest USB drive - a 256MB unit that had been gathering dust - to this very purpose. Following his instructions, I plugged that USB drive into the system that was running Linux and opened System > Administration > Partition Editor (i.e., GParted). In GParted, I wrote down the address of the USB drive (in my case, it was /dev/sdd1); unmounted the USB drive and formatted it to FAT16; and then I right-clicked on it (still in GParted) and, under Manage Flags, made sure the "boot" flag was checked. Then I mounted it by double-clicking on it in Nautilus (i.e., Ubuntu's File Browser). (Like most or all drives, it was located in File System > media.) In my case, I couldn't actually mount it until I went back into GParted, right-clicked on it, and ran a Check; then it showed up in Nautilus as "259.5 MB Media." Now double-clicking on it in Nautilus revealed that it contained nothing. So, back to Linerd's instructions: I closed GParted and, from the website for the ultra-mini FreeDOS distribution known as Odin, I downloaded the odin1440.img image file and copied it to the USB drive. In Nautilus, I also copied the file called "memdisk" from File System > usr/lib/syslinux to the USB drive. Then I created a folder called "grub" on the USB drive. I went to File System > usr/lib/grub. There, I saw that I had only one folder, called x86_64-pc. (This was different from Linerd's example because I was running 64-bit Ubuntu.) He told me to copy all of the files from that folder into the grub folder on the USB drive. Next, using Ubuntu's Applications > Accessories > Text Editor, I created a file containing these lines: default=0 timeout=10 root=(hd0,0) title FreeDOS kernel /memdisk initrd /odin1440.img I called that file "menu.lst" and saved it in the grub folder on the USB drive. Then I installed grub (the program) on the USB drive. This required, first, getting to the grub prompt by entering these two commands: cd /media/disk sudo grub At the grub prompt, I then entered these commands: grub> device (hd5) /dev/sdc grub> root (hd5,0) grub> setup (hd5) grub> quit My impression was that the first grub command would create a virtual device called hard disk no. 5, and would then install the necessary runtime programs in it. The Gentoo webpage that Linerd drew upon had some additional information. Anyway, with the USB drive still plugged into the computer, I rebooted, hit Del to go into my BIOS Setup, and (in the Advanced BIOS Features section) chose USB-FDD as my first boot device. I saved the BIOS changes and rebooted. Apparently the USB thing didn't work, because I found myself back at the usual GRUB menu. I hit Ctrl-Alt-Del and then, on reboot, hit F12 to call up my boot menu. (Not an option for everyone, I'm sure.) I tried USB-FDD from here too, but still no luck. I realized that I had copied down Linerd's instructions verbatim, and had therefore probably entered sdc (the location of his USB drive) rather than sdd1 (the location of mine, according to GParted) in the grub command (above). So I tried again with sdd1. That part went OK, but then, when I typed the "root (hd5,0)" line, grub said, "Error 22: No such partition." I took another look in GParted. I thought maybe grub wanted "sdd" rather than "sdd1," so I tried again with that. It accepted that, so I finished and rebooted. It still didn't boot from the USB drive. I rebooted and hit F12 again. This time, instead of USB-FDD, I chose USB-CDROM. Still not right. I tried again with USB-ZIP. Bingo! This gave me a GRUB menu with FreeDOS listed as the only item. (Later, it looked like I could also have selected USB-HDD.) Now I had another menu, with options to load FreeDOS for 8086, 186, 286, or 386-based computers. There were four 386 options: with HIMEM, EMM386, XDMA, and CDROM. I chose option 6, the last one (i.e., with all four of those programs loaded). I got a floppy (A:\) prompt. I typed C: and it gave me what looked like a corrupt drive directory. I tried D: and it gave me three options in some Eastern European language. I hit Ctrl-Alt-Del, changed the BIOS so it would always try USB-ZIP first, and let it go through its boot process. This time, I went with option 3 rather than 6; and at the A: prompt, I typed DIR /W. It showed me a list of DOS programs and files (e.g., XCOPY.EXE). I typed B:. There was no B drive. I tried C: again. DIR still gave me no joy. E: gave me "Invalid drive E:." This was different from what Linerd said: he said his system booted with C: as the default (and working) prompt. I rebooted again and, this time, from the FreeDOS menu, I chose the F5 ("Bypass startup files") option. This yielded the same results as above. Trying another reboot, I chose the F8 option and walked through each line of AUTOEXEC.BAT. There weren't any error messages; it seemed to be booting and loading as intended. On another try, booting the USB-HDD option didn't fix the problem. Basically, this setup was not working for me. Possibly the problem lay in the note that said, "ATAPICDD should be replaced by your own driver"; possibly my 64-bit system messed things up. Either way, I had no idea what the solution would be. At this point, I gave up on the USB drive approach. Moreover, for some reason (probably related to the router), Windows on this machine was not able to go online. So I went back to the floppy-based approach for flashing the BIOS. In about two minutes, it was done. But I would rather have had a working USB solution and avoid the risk of floppy-based flashing.