You could always write a couple of migration classes with the Migrate module, and hook up Site B as the datasource (the module would live in Site A).
You can do this by adding Site B's database credentials to the settings.php as another configuration, then calling on that in your script.
Here is an example of what a Migration class might look like:
class YourMigration extends Migration {
public function __construct($arguments) {
parent::__construct($arguments);
$query = Database::getConnection('connection_name', 'connection_key');
// other query arguments to execute
}
}
Where the Database::getConnection arguments are the names of the items in your $databases array in settings.php. With a working script, you can then write other scripts (or a cron job) to periodically run the migrate job.
Others will say to use Feeds, but I've always been a big Migrate fan (not Drupal2Drupal migrate module, the main Migrate module itself).
I've noticed that backup migrate can have manual selection of what to
export, but it will overwrite destination right?
Pretty much. Site A would get wiped out. It also isn't as simple as moving MySQL data around, unless every data model in Site B is identical or exists in Site A even then its a fairly large technical challenge not to screw anything up. I would not do anything with SQL at this level - it needs to go through the API.
