JWZ has some pretty good advice. Ignore the bit for Windows users and get rsync via Cygwin if you're on Windows. Cheap commodity drives and rsync for the win.
Backing up a live operating system can be touchy. Taking a snapshot first is recommended if you have that capability.
I don't consider 250GB to be a large amount of data, but I may be biased. At my day job, we're ordering disk by the petabyte.
How important is it to burn in a hard drive before you start using it?
If you have a good backup, and good high-availability systems, then not very much. Since restoring from a failure should be pretty easy.
How do you implement a burn-in process?
What software do you use to burn in drives?
How much stress is too much for a burn-in process?
I will typically run badblocks against a drive or new system when I get it. I will run it whenever I resurrect a computer from the spares pile. A command like this (badblocks -c 2048 -sw /dev/sde) will actually write to every block 4 times each time with a different pattern (0xaa, 0x55, 0xff, 0x00). This test does not do anything to test lots of random reads/writes, but it should prove that every block can be written too and read.
You could also run bonnie++, or iometer which are benchmarking tools. These should try to stress your drives a bit. Drives shouldn't fail even if you try to max them out. So you might as well try to see what they can do. I do not do this though. Getting an I/O benchmark of your storage system right at install/setup time may be very useful in the future when you are looking at performance issues.
How long do you burn in a hard drive?
A single run of badblocks is enough in my opinion, but I believe I have a very strong backup system, and my HA needs are not that high. I can afford some downtime to restore service on most of the systems I support. If you are so worried, that you think a multi-pass setup may be required, then you probably should have RAID, good backups, and a good HA setup anyway.
If I am in a rush, I may skip a burn-in. My backups, and RAID should be fine.
Best Answer
I wouldn't trust important backups to any single device for any significant length of time.
I've had plenty of CDs that couldn't be read after a while. (Cheap ones, admittedly, but I'm leary of the longevity claims made.)
I've had hard disks silently corrupt data.
I seem to remember I've even had SSD failures, although with a low number of writes I'd expect them to be pretty reliable.
Aside from all of these things, using a single copy means you've got no protection against physical disasters: fire etc. If you have multiple copies, you can separate them physically. Ideally I'd take some number (e.g. 3) of copies and run a checksum (I usually use MD5) periodically over everything. If one of the copies becomes corrupt in some way, if you've got multiple other copies you should be able to trust the majority, and create a new backup to replace the corrupted one. (Of course, if you keep the correct checksums in a separate place, you could trust even a single backup which still gives the right checksums, as the canonical source for replacements.)
Of course, how much trouble you go to depends on the value of the data. My personal home data is only backed up on a RAIDed NAS. My work data is in Google datacenters, which I trust fairly strongly :)