When master is lost and no usable backup remains, normal SQL Server startup cannot finish. Rebuilding system databases through Setup recreates master, model, msdb, and tempdb in a clean state. Recovery then depends on saved configuration, scripts, keys, and backups.
Confirm the Recovery Path
First verify that master truly cannot be restored from a usable backup and that the failure is not a service account, file path, storage, or startup-parameter issue. Review SQL Server error logs and recent infrastructure changes. A rebuild replaces all four system databases: master, model, msdb, and tempdb. You cannot use this Setup action to select only master.
I keep the last backups and damaged files protected until the recovery plan is approved. A rushed rebuild can discard the easiest evidence for diagnosis. What was the instance version, collation, authentication mode, and system database file location before it failed? Gather those details from saved inventory if the engine cannot start.
Know What Rebuilding System Databases Removes
The new master loses server logins, endpoints, linked servers, server configuration, and entries describing user databases unless restored or recreated. The new msdb loses Agent jobs, alerts, operators, Database Mail, backup history, maintenance plans, and other stored objects unless a usable msdb backup can be restored. Model customizations and tempdb file settings can also be reset.
User database files are not the same as system database metadata. Preserve their files and backups, then bring them back into the instance by the supported restore or attach path after master is available. Keep their encryption keys and certificates in the recovery plan; a database can exist on disk yet remain inaccessible without them. I inventory these dependencies before a failure rather than discovering them during one.
Keep Recovery Scripts Outside the Instance
Export CREATE LOGIN scripts with SID and password-hash handling through an approved, secure process; also script server roles and permissions, linked servers, credentials, endpoints, and configuration. Export Agent jobs, schedules, operators, alerts, Database Mail settings, and maintenance plans from msdb. Protect secrets and encrypt backups. A script kept only inside the damaged instance is not a recovery asset.
SELECT name,type_desc,sid,is_disabled
FROM sys.server_principals
WHERE type IN ('S','U','G');
SELECT name,value_in_use
FROM sys.configurations;
SELECT name,physical_name
FROM sys.master_files
WHERE database_id IN (1,3,4);These queries are inventory starters while the instance is healthy; they do not recreate logins or expose password hashes. Keep tested creation scripts separately, with the right access controls. Record SQL Server build, cumulative update, collation, file paths, and startup parameters too. I rehearse the inventory export so the recovery team knows whether it is complete.
Run Setup From the Matching Installation
Use SQL Server installation media or the local setup bootstrap that matches the installed instance. Open an elevated Windows Command Prompt in the setup directory. For a default instance, MSSQLSERVER is the instance name. Supply a Windows account or group to become sysadmin, and preserve the intended collation. Mixed Authentication requires a strong sa password parameter; handle that secret through your approved process, not a shared note.
REM Command line
setup.exe /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS="CONTOSO\SqlAdmins"This is an example for Windows Authentication and a placeholder account. Replace it with the actual instance and authorized group. For a named instance, use its instance name. Do not paste a password into a saved script or ticket. Read the Setup documentation for your SQL Server version and confirm clustered-instance steps before execution. The action is destructive to system database contents.
Verify Patch Level After Rebuilding System Databases
Quiet Setup can return to a prompt without a reassuring success dialog. Read the Setup Summary.txt and detailed logs for the RebuildDatabase operation, then check that the SQL Server service starts. Confirm version, collation, database list, and file paths. Microsoft documents that hotfixes or cumulative updates can need reapplication after rebuilding system databases, so compare with the recorded build.
SELECT SERVERPROPERTY('ProductVersion') AS product_version,
SERVERPROPERTY('ProductLevel') AS product_level,
SERVERPROPERTY('Collation') AS collation_name;
SELECT name,state_desc FROM sys.databases ORDER BY database_id;Do not declare recovery complete because the service starts. The clean master can show only system databases while user database files remain elsewhere. I capture setup log location and result in the incident record before restoring metadata, so later failures can be traced to a specific stage.
Restore What Has a Good Backup
If usable, current backups of master, model, and msdb exist, follow the supported restore sequence for the version and instance. In this scenario master has no usable backup, so recreate its missing entries from saved scripts. A usable msdb backup can still recover jobs and related content; if not, run the exported creation scripts. Do not restore old system databases after intentionally changing server collation, because the restore can put the old collation back.
Recreate or attach user database entries carefully, validate file paths and permissions, and repair orphaned users only after restoring the matching logins and SIDs where possible. If replication or availability features were configured, use their specific recovery procedures. I bring the instance back in layers, validating each dependency before enabling scheduled jobs that act on user data.
Verify Jobs, Security and Applications
Compare the post-rebuild inventory with the saved one. Test a login from a remote client, a linked server, a critical Agent job, Database Mail, backups, and a representative application transaction. Check that jobs do not run twice or point at old paths. Move system database files back to recorded locations when the recovery plan requires it, and verify tempdb configuration.
SELECT name,enabled FROM msdb.dbo.sysjobs ORDER BY name;
SELECT name,data_source FROM sys.servers WHERE server_id <> 0;
SELECT name,state_desc FROM sys.databases ORDER BY name;An empty job list is expected on a fresh msdb, but it is not an acceptable final state for an instance that depended on scheduled backups. I verify the next backup job and restore test, not just the job definition. New system database backups belong at the end of recovery, once configuration is stable.
Rehearse Rebuilding System Databases Before an Emergency
A periodic recovery exercise should confirm that installation media, backups, keys, scripts, service-account details, and owners are available. Time the rebuild and the metadata restoration separately. The technical Setup command is short; reconstructing instance identity and scheduled operations is what determines the outage length.
I keep a printed or offline copy of the recovery sequence and a secure digital inventory. When master is missing, querying the instance for its old settings is no longer an option. The strongest recovery plan is one that was tested while the server was still healthy and can be followed without guessing at names or secrets.
Related reading on this blog: Full, Differential and Log Backups: A Practical Guide and How to Migrate Master Database to New Location?.
A Setup rebuild is not full recovery, it is the first step toward restoring the instance people use.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
