l'atomicità delle tabelle è giusta.
Banalizzo con un esempio:
un signore acquista all'ikea articoli per arredo, è disponibile solo 1 determinato armadio, 100 sedie delle quali ne sceglie 4 e svariati altri articoli.
Comincia l'operazione alla cassa, vengono atomizzate le tabelle (magazzino, uscite ecc...) che riguardano l'armadio fino a che l'operazione non va a buon fine (potrebbero esserci problemi con carte di credito) e che mettono in attesa (solo su quell'articolo) le altre casse.
Non può accadere che ad un'altra cassa un altro signore cominci ad acquistare 30 secondi dopo lo stesso armadio (e solo quello) e pagando in contanti termina prima l'operazione.
La morale sarebbe che il primo signore acquista varie cose, paga tutto, ma l'armadio l'ha perso.

Questi dovrebbero essere problemi di amministratori di DB.
Un backup coerente esegue LOCK TABLES, sulle tabelle interessate, eseguito da FLUSH TABLES per le tabelle.
Questa istruzione è necessaria per garantire che tutte le pagine degli indici attivi siano scritte sul disco prima di avviare il backup.
Si può utilizzare SELECT INTO ... OUTFILE . Il file di uscita (da backup) non può esistere già perchè il rischio di sovrascrivere i file esistenti, corrompendo la referenzialità delle tabelle di join, sarebbe concreto.
Una tecnica per eseguire il backup è l'uso del programma mysqldump, oppure mysqlhotcopy.
Le modalità dipendono pure dal type di tabelle.

Mi sono ricordato dell'acronimo ACID ed ecco cosa spunta di wikipedia
http://it.wikipedia.org/wiki/ACID
Comunque non sono un amministratore di DB.
ciao