Mnesia restore :default_op behavior for unlisted tables across OTP versions

Behavior of :default_op in mnesia:restore/2

When performing a restore, the :default_op option determines the fate of tables that exist in the current running schema but are absent from the backup file being restored.

Operational Definitions

• :skip_tables: Preserves the existing table and its data. If a table exists locally but is not present in the backup, Mnesia ignores it and leaves it untouched.
• :clear_tables: Deletes all existing tables in the current database before the restore process begins. This ensures that only the tables contained in the backup file exist after the operation is complete.
• :keep_tables: Similar to :skip_tables, this preserves existing data for tables not listed in the backup, effectively merging the backup state with the current node state.

OTP Version Stability (25, 26, 27)

The semantics of :default_op are stable across OTP 25, 26, and 27. These behaviors are core to the Mnesia restore logic and are documented in the Mnesia User's Guide for these releases. While internal implementation details of the storage engine may evolve, the external API behavior for these flags remains consistent to prevent accidental data loss during cluster recovery.

Verification Steps

To verify the behavior on your specific OTP release, you can use the following scoped test sequence in an Erlang shell:

% 1. Setup: Create two tables, but only backup one
mnesia:start(),
mnesia:create_table(table_a, [disc_copies, [node()]]),
mnesia:create_table(table_b, [disc_copies, [node()]]),
mnesia:backup([table_a], 'backup_a').

% 2. Test :clear_tables
% (Assume a fresh node or manual deletion of table_a)
mnesia:restore('backup_a', [{default_op, clear_tables}]),
% Result: table_b is deleted; only table_a exists.

% 3. Test :skip_tables
% (Re-create table_b first)
mnesia:create_table(table_b, [disc_copies, [node()]]),
mnesia:restore('backup_a', [{default_op, skip_tables}]),
% Result: table_b persists alongside the restored table_a.

Assumptions and Constraints

This behavior assumes the restore is performed on a node where the Mnesia schema is already initialized. If there is a schema mismatch (e.g., the backup contains a table definition that conflicts with a locally existing table of the same name but different attributes), the restore may fail regardless of the :default_op setting. One critical diagnostic detail: Are you restoring to a clean node or a node with an existing schema? If the node is entirely clean, :default_op has no effect as there are no local tables to skip or clear.