I fully agree with Morgan's An argument for not using mysqldump. This post does not come to contradict it, but rather shed a positive light on mysqldump.
I usually prefer an LVM snapshot based backup, or using XtraBackup. And, with databases as large as dozens of GB and above, I consider mysqldump to be a poor alternative. Poor in runtime, poor in overhead while taking the backup.
However once in a while I get to be reminded that mysqldump just works.
As a recent example, I had a server which was killed after an ALTER TABLE statement hanged forever (table already ALTERed, but old scheme never dropped). The old table data still hanged around the file system, but was not recognized by InnoDB. Trying out DISCARD TABLESPACE did not do the job, and eventually file was dropped.
So far, reasonable. InnoDB would complain about some table it never recognized in the first place, but all would work. That is, until backup was concerned. With innobackup or XtraBackup the restore would fail on some internal problem. LVM would work, but would only copy+paste the problem: innobackup would never again be able to be used on this database.
It turned out a 120GB InnoDB compressed data (roughly 250GB uncompressed) would dump in --single-transaction in a matter of 4 hours and would restore in a matter of some 20 hours. A whole lot more than the 3 hours total it would take for an LVM backup for that database. But the data would load well; no missing tablespaces.
I've had similar incidents in the past. Not to mention the issue of compressing shared tablespace file.
There's something about being able to say "I'm not sure how long this is going to take; maybe a day or two. But in the end, we will have problems P1, P2 & P3 resolved".
I like the clean state you get from a mysqldump restore.