Restore points & rollback

A push to a published model can delete things, and a live delete is permanent. So every committed push writes a restore point first. If the push later turns out wrong, you can put the model back. This is the safety net that makes a live write honestly reversible, and it is free at both tiers.

#Why a push needs a safety net

When you deploy metadata back to a published Power BI or Fabric model, most changes are recoverable by redeploying: a redeploy can re-create measures, calculated columns, calculated tables and named expressions. But some object kinds are not. A relationship, a role (and its row-level security), a perspective, a hierarchy, a partition, a culture, a data source or a data table, once removed from a published model, is otherwise gone for good. There is no redeploy that brings it back.

That is the gap a restore point closes. Before Semanticus commits a push to an XMLA endpoint, it reads the target's current state and keeps a copy. That copy is the same snapshot the drift guard already takes to check nothing changed under you, so the restore point costs a push nothing extra. Instead of discarding it after the write, Semanticus keeps it.

#What a restore point holds

A restore point is the target's full model metadata as it stood immediately before the push: measure and column definitions, M queries, role filters, relationships, connection strings, and so on. It never holds a single row of your data. Restore points live in ~/.semanticus/restore as files you are meant to be able to find and prune, not in a hidden temporary folder.

• Local to your machine. They are written on the machine that ran the push.
• Newest ten per target. Semanticus keeps the ten most recent restore points for each endpoint and dataset, newest first, and ages the rest out.
• Model metadata, in clear text. Because a restore point contains definitions such as M queries, role filters and connection strings, treat the folder like any other copy of your model metadata. purge_restore_points removes them when you no longer need the ability to roll a push back.

#Rolling a push back

rollback_push restores a published model to one of its restore points. It is a dry run by default, and the dry run is the whole point: rather than trust a stored fingerprint, it diffs the restore point against the model as it stands live right now and tells you two things before you commit:

• What it would restore. The objects that would come back or change to match the snapshot.
• What it would remove. Every object that exists on the target now but was not in the snapshot. That includes anything the push you are undoing added, and anything a colleague added since. Read this list first. Rolling back is not only an undo of your push, it is a return to a point in time, so a teammate's later work sits in the removal list too.

Only when you pass commit=true does it write. Rollback resolves each object by its lineage identity, so if something was republished under you (a different object now wears the same name), it is refused rather than overwritten. A rollback is itself a push: it is recorded in the audit trail like any other live write. See Edit History for that trail.

#Over MCP

The restore-point operations are dual-drive, so your AI assistant can find, preview and run a rollback exactly as the Studio does. All of them are free.

• list_restore_points lists the snapshots a published model can be rolled back to, newest first. Filter by endpoint and database, or omit both to see every target. Read-only.
• rollback_push previews a restore by default (commit=false), reporting what would be restored and what would be removed; commit=true writes it.
• purge_restore_points deletes snapshots by id, or everything older than a cutoff you pass. Once a restore point is gone, the push it guarded can no longer be rolled back, so a live delete it covered becomes permanent.

list_restore_points                        # newest first, per target
rollback_push  id=<id>                      # DRY RUN: what would be restored + REMOVED
rollback_push  id=<id>  commit=true         # write the restore (audited)
purge_restore_points  olderThanDays=30      # prune snapshots you no longer need