Using a master-slave configuration, and taking backups off the slave is a fairly standard strategy with MySQL database. The process of protecting the data from over-writing is addressed during the recovery phase of failover and failback.
Typically you would use the slave server B to do a full or incremental backup of the database (
mysqldump -h serverB --all-databases --lock-tables --other-options), in a consistent fashion without effecting the master database with locks during dumps. This is useful because the slave is an identical replica of the master.
First the master A is configured with the mysql bin-log directive to make replication available to slaves B .. and potentially C,D etc.
But also slave B is configured to keep a bin-log of transactions. (which would normally be empty, as it shouldn't log replication updates, unless you are chaining slaves)
Once serverA has failed, the master role is moved to serverB, and B now starts to log to its own bin-log file. At this point of the failover operation, you would manually disable replication from A to B, (
mysql -h serverB -e 'stop slave' ) because as you mention, you want to protect B from the failed server A.
What I mean by the "master role is moved from server A to server B" is that you would change your application to write CRUD operations (create, replace, updates, deletes) to the server B address. e.g.
mysql -h serverB -e 'INSERT INTO table X'. In a 2-node setup, you would also migrate the SELECT queries as well, because you have no clustered read-only role distinct from the master-role.
Now is the sys-admin task to bring A back online as a slave of B.
If it was a clean failure, A is now some number of events behind B, but the binlog on B contains a record of those events. Hence you can replay the masterB binlog onto slaveA (it contains basic SQL statements)
If server A was completely destroyed you may opt to restore the mysql to A using an full-backup taken from B using either a recent dump, or using a tool like percona innobackex script from the xtrabackup package.
You should now configure replication in the opposite direction, to allow slaveA to replicate from masterB.
Now A and B should be identical. If you have a good reason, such as that slaveA is a much higher spec machine, then you can now switch about the replication direction to restore the masterA-slaveB configuration.
Other strategies to deal with this scenario (of failover, and failback) include MMM, multi-master replication, or the percona replication manager tool (which I have not tried in production)