My attempts to back-up to an external hard disk finally met with apparent success but I cannot now mount the target drive.

To summarize:-
1. Installing a SATA hard disk, identical to my computer's main drive, in a USB 2.0 caddy and attaching this to the computer resulted in qualified recognition. 'fdisk' 'saw' both the main drive, as sda, and the USB drive, as sdb, respectively but initially noted that the latter, “... doesn't contain a valid partition table.” This was hardly surprising. At the point of first connection the external drive was essentially a 'bare metal' device, having had its data wiped. Nevertheless, 'fdisk' correctly reported its size, number of heads and cylinders, etc.
2. 'dmesg' also correctly identified the external disk as sdb, reporting its type and the USB port to which it is connected.
3. 'df' ignores the second hard drive, reporting only the main disk.
4. Attempts to clone/back-up the main disk to the external disk using the recommended tools EaseUS Todo back-up and RedoBackup, booting respectively from appropriate USB memory sticks, both failed. Neither utility was prepared to write to the external disk. EaseUS acknowledged the latter but crashed the whole computer when instructed to perform the clone. RedoBackup failed to recognize the external disk.
5. Then came the break-through. A bit more Net browsing led me to try the command 'dd if=/dev/sda of=/dev/sdb'. The main disk was bit-copied (cloned) to the external disk at roughly 20Gb per hour, meaning that my 80Gb disk was copied in just under 4 hours. Checking 'dd's resulting report showed what appeared to be a perfect copy.

So far, so good. I now have a back-up which, being identical to the main disk, should, I assume, be bootable. In the event of trouble with the main disk I should be able simply to exchange it for the external disk and carry on from the point at which I made my last back-up. I cannot, however, access and read the external disk. I assume that it must have a partition table and be mounted. The first requirement appears to have been resolved by the cloning operation. 'fdisk' reports no trouble with the partition table on the cloned external disk. It lists /dev/sb1 as the bootable Linux partition, /dev/sdb2 as the Extended partition and /dev/sdb5 as the Linux swap / Solaris partition, exactly mirroring the corresponding entries for the main, sda, drive.

My attempts to mount the external disk have all failed, however. I clearly do not understand the syntax of the mount command or have failed to meet some other requirement. 'mount' objected without hesitation to my early mistakes but “mount -t dev/sdb” was instantly accepted. No error messages or other output resulted and the command prompt was immediately redisplayed but 'mount' then failed to show that the external drive had been mounted. If I try something like 'mount -t /dev/sdb1 /mnt/xdisk', where xdisk is a directory I have been told to create, then I am presented with a prolix description of 'mount's syntax, most of which leaves me bewildered. 'mount' then once again confirms that sdb1 does not feature in the list of mounted devices.

Can someone offer any suggestions? I have read one or two of the other posts on this topic but none of the details match my problem too well and I did not understand some of the replies. If I try to add a line to /etc/fstab, for example, I find that I do not have a directory called 'fstab', only 'fstab.d' and that is empty.

I have roughly one year's experience with Linux Mint 13 which I chose because it so closely resembled Windows XP.

That's very slow copying - is this USB2.0 speeds?
You could try a suitable bs parameter on the dd command, so that it might run a bit faster.

You can mount partitions as empty directories...
e.g.
Your file system etc should be recognised and /media/part1 should now contain the same contents as /dev/sda1
If you edit any files in /media/part1, your changes will be written to your USB disk.

BEFORE you logoff:-
That spelling is correct!

1 members found this post helpful.

Close, but no cigar. The -t option must be followed by the filesystem type, such as ext3, ext4, etc. You also omitted the leading / to /dev/sdb, and the partition number.

Try "mount -t ext3 /dev/sdb1", assuming ext3 filesystem type is what you have.

If that fails, be more specific: mount -t ext3 /dev/sdb1 /mnt
to specify what to mount and where to mount it.

1 members found this post helpful.

You also have to specify WHERE to mount...

"mount -t ext3 /dev/sdb1 /mnt" will mount the filesystem on /mnt, thus all the files in the filesystem will be under /mnt.

USUALLY you don't have to specify the filesystem on the mount command - as long as the filesystem home block isn't corrupted, it will identify the filesystem from the information there, and use the appropriate type.

1 members found this post helpful.

specifies where to mount and relies on the backup being good - so the -t parameter is unnecessary...

I claim my cigar!

1 members found this post helpful.

I am increasingly indebted to William of Occam (c.1287-1347) and his famous razor which, in modern parlance, states, “Never go looking for complex solutions until you have exhausted the simpler ones.” For someone offering Linux support that could, perhaps, be better rendered as, “Never assume that a newbie has not done something silly or failed to do something obvious (well, obvious in your terms) before you start getting technical.”

When I could not get the external drive to work on my Linux machine I confirmed that it was properly installed in its caddy, and otherwise functional, by connecting it to a USB port on my ten year-old Windows XP computer, which immediately responded with the P&P message, “New hardware found,” followed quickly by a further message indicating that the device was an external 80Gb hard drive connnected via USB. Within seconds yet another message proclaimed that the device had been installed and was ready for use. It was obviously working. I have to say one thing about MicroSoft. It generally held your hand whilst checking your wallet with its free one.

In contrast, Linux was decidedly taciturn when the external disk was reattached. In the event of difficulties it can appear to be a case of, “Physician heal thyself.” Maybe I didn't get the cigar but, as acknowledged, I wasn't too far off, despite some clumsy commands. (The missing '/', by the way, was a typo in my question. It was present in the command.)

I then suddenly thought, “I wonder if the computer needs to be rebooted before it fully recognizes the disk?” This I did and noted a flurry of activity on the external disk LED as the computer came back on line. That looked promising. I did not need to issue the 'sudo mkdir /media/part1' command because I had used 'mkdir /mnt/xdisk' earlier and confirmed that the latter directory had been created, although it was empty. 'sudo mount /dev/sdb1 /mnt/disk' then populated it and, lo and behold, there was the external disk in the list of mounted devices when I typed 'mount'. It was time for high fives, or whatever it is that you youngsters do these days.

Celebrations proved premature, however. The external disk LED remained suspiciously active. The computer had, for some obscure reason (well, obscure to me) booted from the external drive – good news in one way. It proved that the clone was viable, but bad in that, from refusing to acknowledge the external disk, the computer now insists on using it instead of the main disk. I have rebooted and checked that sda1, the main disk, is offered, and was selected, as the only bootable device but this makes no difference. If the external disk is running, even though it has been unmounted before the preceding shut-down, then sdb1 is selected as the boot device. The only way to stop it appears to be to power it off before re-booting. The same boot options are offered but the computer then boots from its main hard disk. Progress continues in the familiar 'two steps forward and one back' fashion, it would appear. Any thoughts?

I also have a couple of questions arising from the feedback.
1. Why is it necessary to unmount the external disk before logging off? This means that I will have to repeat this operation every time I take a back-up. That's no great hassle but I would be interested to know why it has to be done. The boot order preference problem, noted above, seems to indicate that the external disk is taking scant notice whether it is mounted or not.
2. The slowness of the cloning operation rather intrigued me, too. You will see from my initial post that I was indeed using USB 2.0. The data transfer rate achieved, so the 'dd' report told me, was 5.7 Mb/sec, roughly one tenth of what I was expecting. I'll try a byte copy next time, to see if that speeds things up but, in the mean time, it's not a major problem. At least I now have a back-up utility, making me feel a lot safer.

It just leaves me to thank those who responded. I have a number of introductory Linux Mint guides and I have learned a great deal from them but they rarely appear to resolve the sort of problems that stop newbie's in their tracks.

If anyone should now feel that I deserve a cigar then I am flattered – but I don't smoke. A cream doughnut (sorry, 'donut') would be much more acceptable and probably no more harmful.

It is necessary to unmount the filesystem so that any system internal buffers are flushed to disk. Without it being dismounted the filesystem could be corrupted. This is less of a problem with journaling filesystems, but it can still be damaged (especially if a write is active at the moment the disk is unplugged).

Now unmounting at logout is not a necessity - but if it is mounted via the GUI then the GUI should attempt to unmount it while it is shutting down for the logout. Unfortunately, sometimes it doesn't get around to it, and the GUI controlling application gets terminated before it unmounts automatically. The other thing to realize is that when the next user logs in the initialization of the GUI will recognize the USB devices, and give that new user access when the previous user did not intend to give access.

1 members found this post helpful.

If redundancy is the main goal to have a backup in case something happens to the main drive, a raid 1 ( disk mirroring ) is a good option to use.

1 members found this post helpful.

Mirroring is good to keep a system running in the presense of a hardware drive failure...

But it does nothing to protect against fat fingering something which would destroy the data on both drives... at the same time.

I like keeping a backup... on a separate partition, and only update that second root when the primary gets validated after updates.

1 members found this post helpful.

I used to use snapshots with LVM to restore files that were changed or deleted, but I stopped a long time ago.

I decided not to backup my root filesystem anymore and just backup my home directory instead with rsync to my file server. And If updates brakes my system, I'll just re-install the OS if I can't resolved it.

That works if you have time to reinstall and reconfigure everything. It works for basic workstations.

It doesn't work well with servers that have to be restored to operational readiness in a minimum of time.

for my workstation I do have two roots... but right now, one is Fedora 16, and the other is Fedora 21.

There is a easy way. Just backup your user data.
It's not necessary to backup your distro, since this can be easily downloaded.

http://backup2l.sourceforge.net/ is a simple guard against fat finger syndrome.
It also runs automatically...

Similarly here, I use
The only things that is important for me to backup is in or under|beneath /home/jj/
I can re-install any OS and be 'up to speed' on it within an hour.

Repetitive re-installing on a disk I had nothing to lose is how I learned about partitions and mounting and how existing ones can be incorporated into my environment.

Once the light has been lit, it really is a confidence builder to know that you can re-install and not have to lose any data.

Thank you, everyone, for your help and suggestions. However, “To clone or not to clone. That is the question,” is one that I would rather avoid. Different users have different, and often strongly-held, views on whether it is better to copy the whole disk or simply back-up application files. There are sound arguments both ways but I remain a cloner. If my disk goes down I simply want to replace it with, or reload it from, another and carry on from where I left off. OK, cloning can be slow and, as one respondent pointed out, perhaps not the best way of safeguarding a server but I don't have that problem. If I have to leave a back-up or cloning operation running overnight then I'll not lose any sleep over it.

I remember a particularly valid comment made by a much more experienced user than I. He said, “Remember, it is not just the files that you think you are altering that are being changed. There are literally hundreds of files – many of them system files – that are being updated all the time and most of these you know nothing about.” Then, of course, there are your e-mails. Do you know where they are kept? I am not sure that I do, but then I don't care too much. When I restore a clone, everthing is put back where it was. As I said, I respect others' rights to their own views but cloning suits me just fine, particularly if I can go in and retrieve individual files from a back-up so created. It's a case of horses for courses.

My focus has now shifted to this disturbing situation where my computer insists on booting from the external cloned disk (sdb1) rather than the main hard disk (sda1) despite the initial boot command's assurance that it is about to boot from the latter, as it has always done until now. The only way I can presently stop this is by physically turning the external disk off, prior to booting. Is there a user-amendable boot sequence in which the external disk currently has a higher priority than the main disk? It seems unlikely that the computer would search for a bootable USB device before checking the internal SATA ports but at the moment if there is a bootable disk in the external USB caddy, the computer preferentially boots from it, even if it is not mounted and irrespective of what the initial boot-up command has to say. I also have a nasty suspicion that, if the USB disk is turned off at boot-up, it will not be acknowledged when it is turned on after the computer has booted from the main hard disk. I need to force the machine to obey the initial boot command, as stated in the boot menu, whether or not the external USB disk is switched on. If, however, the USB disk refuses to be recognized if it is not switched on at initial boot-up, but the computer cannot then be prevented from booting from it, that will be another Catch 22 situation well beyond my competence to resolve. Just when I thought it was safe to claim the back-up problem as sorted!

You might double check the clone. If you use volume name/UUID mounting then a clone of a disk will also clone the volumn name and UUID.

Normally the BIOS will specify the boot - and that specifies the /boot partition (or wherever the kernel and initrd reside). Once grub gets loaded, it will then pick what it thinks is the specified drive... and if (for some reason) the USB device happens to show up first with the UUID/volumn then that is the one it will use.

You can fix this by changing the UUID/volume label on the clone.

1 members found this post helpful.