Real bad sectors could/would have already been mapped-out by the
drive itself (modern disks have a lot of onboard intelligence).

Note also it's inadvisable to do low-level checks on a live filesystem
because things could be changing and corruption is inevitable.

IIRC, Windows' defrag and checkdisk "lock" areas of the disk when
they're doing their thing; I'm unaware of something similar for Linux.

Best way to check a disk is boot a Live CD to check the unmounted raw
disk(s). There's even a way to do that in Windows.

> Note also it's inadvisable to do low-level checks on a live filesystem
> because things could be changing and corruption is inevitable.

I was checking a remote hard drive that had just been formatted and
thus thought worthwhile before actually copying data to it.

> Best way to check a disk is boot a Live CD to check the unmounted raw
> disk(s). There's even a way to do that in Windows.

If one is doing it that way does one in fact need to use a liveCD. If one does
System--Administration--Partition editor (Gparted)[select
drive]--Partition--Information

In this case one is only looking at information.

And that's safe and OK. I had the impression the goal was to do a
"real" check of the disk which requires reading-writing-reading
(or letting the disk itself report any error(s) if one's doing
reading only) to assure data integrity in each sector.

Modern disk surfaces are extremely tough and I haven't seen a
head crash or sector data failure in at least over a decade. What
usually fails after 3-5 years nowadays is the flexible wiring from
the head/arm assembly to the disk's internal controller from being
flexed too many times (e.g., arm motion).

Some OSs actually track arm motion and power-on hours and gradually
downgrade the rating of a disk over time and proactively suggest a
replacement disk when the values exceeds a certain threshold. The
point being to replace a disk _just_ before its projected failure,
and the algorithms are extremely good in that regards.

You really don't want to be in a situation requiring the use of a
disk recovery service -- the pricing is astronomical. Backup, backup
and backup your data.

Some more thoughts about this --

Earlier this week someone posted a reference to a program named
sbackup and unless I'm going blind reading its docs and missed
something, it backups to another partition (or directory) on the
same disk.

If that (single) disk goes belly-up, so does the backup.

What I have for my main web/ftp server (since it's in a colo center)
is a second disk that mirrors the primary disk's root and /usr
filesystems per:

thadlabs bash 22576/22609> df
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/aacd0a 492863 40244 413189 9% /
/dev/aacd0e 273417193 167097358 89914803 65% /usr
procfs 4 4 0 100% /proc
/dev/aacd1a 492863 40244 413190 9% /backup
/dev/aacd1e 265365585 167008098 77128240 68% /backup/usr

That's a FreeBSD system in case the disk names seem "odd". :-)

That's worked well for years and it's easy to recover something.

My knowledge extends to just backup and backup - CD for a longer term
archive. Whenever i formatted a disk i used to do a thorough
checkdisk. Out of habit i wanted to do the same on ubuntu.

You can configure sbackup to backup to
another disk or alternately copy the backup to a disk on key. It's a
very simple efficient backup program that can be set up to do full
backups, incremental ones etc. It can also be set up to back up the
whole hard drive or just certain parts of it (only certain volumes or
directories).