External hard drive does not eject

It's one of the major flaws with newer seagate drives (alongside no on/off switch so you have to pull the power cord out the back and risk damaging the disk). They are just not compatible with Macs unfortunately. They go to sleep and there's no way for the Mac to reconnect to them. I've contacted Seagate about this and they said "Sorry there's nothing they can do about it, perhaps I can contact Apple and they can do something about it". Great..!

I basically don't buy Seagate any more and don't recommend Seagate to any friends or family with Macs. They just cause too many issues.

I'm using 10.6.8, I've not tried 10.8.3 as poster above suggests.

Aside from restarting the system, there are probably a half-dozen straightforward, reliable and perfectly appropriate ways to go about completing the process of fully detatching a drive which unexpectedly stopped prematurely at the point of unmounting. I had two terminal commands which would get the job done come to mind immediately, and I know them both well enough to feel no need to double-check the man pages before typing away. That said, my advice is to deal with the situation by... restarting the system. Let the OS run the myriad of shutdown and startup integrity checks and multi-step boot-time safety procedures and recovery functions we have no idea even exist. While I'm adventurous enough to mount shadow-file disk images in the kernel [/usr/sbin/hdik], I defer to the authority of the local filesystem structure when it comes to keeping an eye on the integrity of my backup drives.

I further suggest that before engaging in any direct action on the drive, you check SuperDuper's log. Had something gone Terribly, Terribly Wrong, SuperDuper would have announced it at the time, so that's not the reason for taking a look. I suggest it on the odd chance of encountering a hint about the source of the glitch.

Likewise, consider checking /var/log/diskarbitrationd.log for its take on recent events and the opportunity of greater enlightenment. (Naturally, I won't mention taking a passing glance at the content of /etc/fstab.)

edit :: supplemental information

The two commands which occurred to me were umount﹡ and diskutil.

I looked over the documentation for umount to ensure my memory of its usage was reasonably accurate. I was confronted with the revelation that for, oh, twenty years or so, I had overlooked the man pages' NOTES section, fully quoted herewith:

Due to the complex and interwoven nature of Mac OS X, umount may fail often. It is recommended that diskutil(1) (as in, ``diskutil unmount /mnt'') be used instead.

What can I say? Due to the complex and interwoven nature of my residual cognitive capacity, I may fail often.

As for diskutil, the particular command I would have issued turned out to be a valid one: diskutil unmountDisk force [device]. You'll want to consult the manual pages for full usage options and syntax.

Regarding the non-existence of /var/log/diskarbitrationd.log: apparently, you foolishly neglected to create it… Oh… Wait…

I sometimes [see ¶ four, above] forget that this or that background process I have running is not part of a default OS installation. That was the case here with the disk arbitration server daemon, located at /usr/sbin/diskarbitrationd. No sense in your bothering with it now.

If you care to, and at your convenience, consider using Disk Utility to examine the backup drive's partition scheme and filesystem. If more than one volume exists on the device, which is likely not so for a backup drive, hold down the ⌘-Command key while clicking on the device name along with the indented volume names below it. Then use the Verify Disk option in the First Aid tab to check the drive for errors.

﹡ Not a typo.