This is not a silly question. You should take backups seriously.
Let's look at your three options:
1) Use mysqlbackup (physical backup) instead of mysqldump.
MySQL's Enterprise Backup is mentioned in Baron Schwartz's so I won't rehash.
2) increase key_buffer_size to 20% of RAM (not just for backup extremely helpful option).
The key_buffer_size governs the size of the MyISAM Key Buffer, which is for caching index pages of MyISAM tables. They do not play a factor in backups. For example, if you use mysqldump and do SHOW PROCESSLIST;
, you will see something like
SELECT /* SQL_NO_CACHE */ FROM tblname
This prevents thrashing caches. Otherwise, needed data will be needlessly pushed out of MySQL's caches during a backup.
3) take a look at tools of maatkit there are few for backup.
Percona featured mk-parallel-dump and mk-parallel-restore. Percona recently declared these tools as deprecated. Some still use them at their own risk.
I actually wrote my own version of parallel dumping for databases and tables and posted the algorithms in the DBA StackExchange.
Percona now has Percona Tools. It does not include any backup tools. That is marketed separately as XtraBackup. IMHO it has pros and cons but it is definitely ideal for large installations
It is not ideal if you are looking for point-in-time recovery because the point-in-time of the backup data from XtraBackup is based on when XtraBackup has completed rather than when XtraBackup started. This becomes quickly apparent if the rate of incoming data is almost as fast as the backup process itself. Theorectically, if the rate of incoming data is as fast or faster that backup process, the backup process will never finish. That was said on stage LIVE at the Percona Live Conference back in May 2011. As long as you can live with this and your current rate of incoming data, then XtraBackup is the solution for you.