Vagrant Snapshot Restore and Database Migration Rollback Interoperability

Provider-specific snapshot storage does not prevent rollback on the same provider, but it does prevent snapshot-based rollback after you switch virtualization platforms. A VirtualBox snapshot cannot be restored on VMware or Hyper-V, and the same limitation generally applies across provider versions. If you switch platforms, rebuild the VM from your Vagrantfile/provisioning code and roll back the database with a database-native dump or migration down script. The snapshot is not a portable rollback artifact.

This answer assumes the database runs inside the Vagrant VM. If it runs outside the VM or on a shared volume, stop: a VM snapshot cannot roll back the schema. Use database-native backup/restore or migration rollback instead.

Prevent non-idempotent migrations from re-applying

The core control is to separate provisioning from migration and to restore with provisioning disabled. Some Vagrant versions and providers may run provisioners after a snapshot restore; others do not. Treat that as version-sensitive and verify your installed behavior.

1. Keep schema migrations out of always-run provisioners. Run them as a deliberate step, or gate them behind a one-shot trigger.
2. Use a migration tool with a version/history table (Flyway, Liquibase, Alembic, Rails, Django, etc.) so already-applied migrations are skipped when the tool is run normally.
3. Before the migration, take the snapshot and record the expected migration version.
4. Restore with provisioning disabled where supported. Check the flag first:

   vagrant snapshot restore --help
   vagrant snapshot restore pre_migration --no-provision   # only if listed
   

   If your version does not support --no-provision, temporarily disable the migration provisioner or remove it from the restore path before restoring.
5. After restore, do not run vagrant provision or any migration command until you have confirmed the state.

Verification after restore

Confirm three things: the VM state, the database version, and the absence of provisioner re-execution.

• Run the migration tool's status command and confirm the recorded version matches the pre-migration point. Examples: flyway info, alembic current, python manage.py showmigrations, rails db:migrate:status.
• Query the migration history table directly. The new migration row should be absent if the snapshot predates it.
• Dump the schema before and after restore and diff the two dumps. Confirm altered tables, columns, or indexes are gone. For PostgreSQL, for example, pg_dump --schema-only can produce the comparison files.
• Inspect the restore output and provider logs for provisioning steps. Use verbose/debug output if available. If provisioning ran, treat the rollback as suspect and check for duplicate schema objects.
• Check networking, installed packages, and files if they changed after the snapshot. A snapshot restore reverts all VM state after that point, not just the database schema.

Cross-platform rollback

When switching providers, do not plan on snapshot interoperability. Rebuild the VM from code, restore the database from a portable dump, or run the migration tool's down scripts. Verify with the same status and schema-diff checks. If a migration failed midway, a snapshot restore may be safer than a scripted down migration, but only on the same provider and only if the database is inside the VM.

Uncertainty remains around exact Vagrant flags and provisioner behavior across versions and providers. Verify the commands against your installed Vagrant and migration tool versions before relying on them for rollback.