---
title: "Troubleshooting restoration SQL database back-up"
canonical: "https://servicedesk.maxgeo.com/space/LC/1263632591/Troubleshooting%20restoration%20SQL%20database%20back-up"
format: markdown
---
<u>**Objective**</u>:

To determine:

- Why I can't open the .zip file supplied to me**.**
- Why I can't restore the .bak file supplied to me.

<u>**Troubleshooting:**</u>

<span style="color: #bf2600">*Much of this requires access to the SQL database, and therefore should only be conducted by appropriately trained and experienced SQL professionals.  If such a professional is unavailable, please contact servicedesk.maxgeo.com for assistance.*</span>

1. Check the extension on the file to determine the file type (e.g. .bak or .zip).  If the extension is not in the filename, ask the sender and refer **Cause 2**, additionally:
  - If it is a .zip file you should be 'un.zip'ping' the file to get to the .bak.
  - If it is a .bak file you should be restoring it to the SQL Server.
2. Contact the sender to determine how the file was transferred (ASCII or binary).
  - If is was transferred as ASCII, refer **Cause 1**.
3. Run the script to determine file properties (refer "Additional Information" below) in SQL Management Studio to determine if the supplied backup is valid/complete.
  - If an error is returned, to this script on a backup that you know can be restored.  If the script fails again, refer **Cause 3**.  If the script works on this other database, refer **Cause 4**.
4. Ask the send for the following information:
  - What program and program version is being used to create the backup.
    - If it is not SQL Management Studio, refer **Cause 5**.
    - If it is automated (perhaps periodic) backup, refer **Cause 7**.
  - Ask if it is a complete backup, or a partial backup (e.g. stores information on changes the database only).
    - If it is a partial backup, refer **Cause 7**.
  - The methods used to compress (if applicable) and transfer the backup.
    - If it is not transferred via Filezilla, refer **Cause 6**, noting that **Cause 1** may also apply.
    - If it is not compressed via winzip or 7zip, refer **Cause 6**.

<u>**Cause:**</u>

1. Although instructions may be issued in ASCII, the execution of instructions (e.g. transfer of the .zip file) must be done in binary.  Refer **Solution 1**.
2. The filetype is not in the file name, so the computer doesn't know what to do with it.  Refer **Solution 2**.
3. The script is not been used as intended.  Refer **Solution 3**.
4. It is possible the file has been corrupted either in the creation, compression or transfer stage.  Refer **Solution 4**, or (if this is not the first time you have arrived at this **Cause 4**,** **keep troubleshooting).
5. The method used is possibly not compatible with SQL Management Studio without additional steps being undertaken.  Refer **Solution 5**.
6. The method used is possibly not compatible with .bak's, and may be unintentionally corrupting the file.  Refer **Solution 6**.
7. The method used is possibly not producing a full backup.  In such instance, there is insufficient data for the database to be restored.  Refer **Solution 5**.

<u>**Solution:**</u>

1. Ask the sender to resupply, noting that the transfer process must be done in binary.
2. Add the filetype (.e.g .zip or .bak) to the file name, and try again.
3. Re-read the instructions and try again, noting you can request assistance from servicedesk.maxgeo.com if required.
4. Ask the sender to resend.
5. Request the sender re-creates the backup manually using SQL Management Studio.
6. Request the sender re-supplies the backup via upload to the SFTP using Filezilla, after compressing it via winzip or 7zip.