A backup of the entire server will be inclusive of the SQL Server instance and the database files as a snapshot in time at that moment. This is assuming that the database files live on the server itself that you're taking a backup of, as it is possible to setup the database's such that their files live on remote shares. You can verify the location of your databases' files in **SQL Server Management Studio**, by right clicking on a specific database, clicking **Properties**, and then navigating to the **Files** page, then looking at the **Path** and **File Name** properties. For example: [![Database File Properties Example][1]][1] In the above, my `Test` database's files are stored in the default SQL instance folder. Please ensure the drives that your database files live on are part of the server / snapshot being taken of it, as even mapped drives can have drive letters but point to remote shares. There shouldn't be any additional work on the destination server, but you may want to make sure the appropriate SQL services (in the Windows Services) are started and running just the same as on the source server. For example: [![Windows SQL Services][2]][2] The above is my test instance which probably has a lot more components of SQL Server installed than yours will, so don't take this as a definitive list, rather it's an example. Compare against your source server to the destination server. The only other thing I can think of is to ensure all the same Windows permissions are setup to the correct accounts on your destination server as its respective source server. For example, if you're using the **SQL Agent**, or a feature like **Replication**, those might leverage Windows accounts that currently have special permissions setup on your source server which need to be replicated on your destination server. (This is a little outside the scope of DBA.StackExchange though, and might be more of a ServerFault question, if you need help with that.) [1]: https://i.sstatic.net/6pNBd.png [2]: https://i.sstatic.net/1GcZF.png