Comments (12)

  1. Very interesting Robert. Finally, a use for a dacpac that a DBA can get behind! :)

    1. Thanks Wayne. My thoughts exactly when I first realized this.

    1. Great article, Dan. I had run into some of those problems with one database and had planned to follow up later.

  2. Hi Robert,

    Be careful with the DAC PowerShell Samples. They were written over DACFx 2.0 which doesn’t support all the database objects and has been superseded by DACFx 3.0 which does support all objects but has a completely different programming model.


    Cheers, Bob

    1. Thank you, Bob. That’s good to know. We do have some PowerShell jobs running in production to export dacpacs weekly for our dev teams to use for script generation and such. I’ll verify which version we’re using and plan to update it if using the older version.

  3. […] Schema-only Backups and Restores – Robert L. Davis(Blog|Twitter) […]

  4. Robert, this is exactly how I have been using DACPAC’s for schema backups. The only part that’s been hard has been schema compare between two DACPAC’s, but I’m automating it all into our version control system, so that helps a lot.

    1. We have them automated, but only to the point that we export them to a share for the developers to use.

  5. […] L. Soldier’s Schema-only Backups and Restores shows how a backup and restore of a database schema can be done using a […]

  6. Some interesting comments.

    I have indeed worked on DW projects with no backups, where we kept all the files we loaded from the source system available so that we can do a reload. Where did we get the schema? From source control of course.

    I would definitely say that source control is a better repository for schema than a dacpac ~ if people are launching changes to the DB into prod without going via some form of source control, you have other issues than just no backups…

    1. I agree completely, Mark. But I also like having something more in case I can’t get a hold of the schema out of source control.

      I’ve worked with excellent dev teams where that would not have been an issue. I’ve also worked with developer teams who with horrible processes and they don’t even trust what was in source control.

Leave a Reply

Your email address will not be published. Required fields are marked *