Restore headeronly прервано с ошибкой 3241

Проблемы

В Microsoft SQL Server 2019 восстановление сжатых резервных копий баз данных или резервных копий журналов баз данных с включенным прозрачным шифрованием данных (TDE) может привести к следующей ошибке:

Msg 3241, уровень 16, состояние 18, строка <номер строки>

Семейство носителей на устройстве «<имени файла резервной копии>» имеет неправильный формат. SQL Server не может обработать это семейство носителей.

Обходное решение

Чтобы обойти эту проблему, не сжимайте резервные копии баз данных с поддержкой TDE одним из следующих методов:

• Используйте WITH COMPRESSION, как описано в инструкции BACKUP (Transact-SQL).

• Используйте сжатие резервных копий по умолчанию, как описано в разделе «Просмотр» или «Настройка параметра конфигурации сервера для сжатия резервных копий по умолчанию».

Решение

Сведения о накопительном пакете обновления

Эта проблема устранена в следующем накопительном обновлении для SQL Server:

Накопительный пакет обновления 16 для SQL Server 2019

Примечание. Чтобы избежать этой проблемы, необходимо создать резервные копии вместе с этим исправлением. Установка фиксированного накопительного пакета обновления на целевом экземпляре и попытка восстановить ту же резервную копию, созданную без исправления, не будет работать.

Дополнительная информация

Важно: Начиная с SQL Server 2019 с накопительным пакетом обновления 16 (CU16), при создании сжатых резервных копий (базы данных или журнала) баз данных с поддержкой TDE будет использоваться новый формат резервного копирования, который можно восстановить только в экземпляре с установленным накопительным пакетом обновления 16 (CU16) или более поздней версии.

Восстановление сжатой резервной копии базы данных с поддержкой TDE, созданной в накопительном пакете обновления 16 или более поздней версии на экземпляре SQL Server 2019 версии CU15 или более ранней версии, завершается сбоем и вызывает следующие ошибки:

• RESTORE DATABASE

  Msg 3013, level 16, State 1, Line <LineNumber>

  Инструкция RESTORE DATABASE завершается аномально.

  Msg 9004, level 21, State 1, Line <LineNumber>

  При обработке журнала для базы данных «TDE_DB» произошла ошибка. По возможности выполните восстановление из резервной копии. Если резервная копия недоступна, может потребоваться перестроить журнал.

• RESTORE LOG

  Расположение: mediaRead.cpp:1018

  Выражение: readSize <= m_Demand

  SPID: 84

  Идентификатор процесса: ProcessID

  Msg 3013, level 16, State 1, Line <LineNumber>

  Инструкция RESTORE LOG завершается аномально.

  Msg 3624, level 20, State 1, Line <LineNumber>

  Сбой проверки системного утверждения. Дополнительные сведения см. в журнале ошибок SQL Server. Как правило, сбой утверждения вызван ошибкой программного обеспечения или повреждением данных. Чтобы проверить наличие повреждения базы данных, попробуйте выполнить инструкцию DBCC CHECKDB. Если вы согласились отправлять дампы в корпорацию Майкрософт во время установки, мини-дамп будет отправлен в корпорацию Майкрософт. Обновление может быть доступно корпорацией Майкрософт в последнем пакете обновления или в исправлении из службы технической поддержки.

Примечание. Инструкции RESTORE HEADERONLY и RESTORE FILELISTONLY не затрагиваются проблемой и будут работать во всех случаях.

Инструкция RESTORE VERIFYONLY может успешно вернуться для полной резервной копии, которая является недопустимой в соответствии с описанным выше сценарием: не следует полагаться на инструкцию RESTORE VERIFYONLY, чтобы убедиться, что резервную копию можно восстановить, не нажав указанную выше проблему. Инструкция RESTORE VERIFYONLY для резервной копии журнала обычно завершается сбоем с той же ошибкой, что и в фактическом журнале RESTORE, описанном выше.

Поэтому важно убедиться, что в контексте, где может быть включено Сжатие TDE и резервного копирования, все экземпляры SQL Server 2019, использующие резервные копии из других экземпляров SQL Server 2019, получают накопительный пакет обновления 16 (или более поздней версии) до экземпляров, создающих резервный материал. Архитектура доставки журналов будет простым примером такой ситуации: сначала обновите вторичные экземпляры.

После создания резервной копии журнала транзакций со сжатием ее обычно невозможно воссоздать без сжатия. Таким образом, обновление сервера-источника доставки журналов до SQL Server 2019 с накопительным пакетом обновления 16 (CU16) или более поздней версии в таком контексте приведет к разрыву заданий восстановления до обновления сервера-получателя.

Несжатая резервная копия базы данных с поддержкой TDE, сжатая резервная копия базы данных, которая не включена для TDE, или несжатая резервная копия базы данных, которая не включена для TDE, не будет использовать новый формат резервной копии, представленный в накопительном пакете обновления 16, и может быть восстановлен в экземпляре SQL Server 2019 любых версий.

Поэтому необходимо отключить сжатие резервных копий, если вы планируете восстановить материал базы данных с поддержкой TDE (полное резервное копирование или резервное копирование журнала транзакций) на любые экземпляры SQL Server более ранних версий до SQL Server 2019 CU16.

Статус

Корпорация Майкрософт подтверждает наличие этой проблемы в своих продуктах, которые перечислены в разделе «Применяется к».

Ссылки

Сведения о терминологии, используемой корпорацией Майкрософт для описания обновлений программного обеспечения.

   Arik777

12.11.15 — 22:54

   Arik777

1 — 12.11.15 — 22:55

Прошу местных гуру помочь мне! Заранее спасибо.

   Господин ПЖ

2 — 12.11.15 — 22:57

   Господин ПЖ

3 — 12.11.15 — 22:58

ЗЫ за бэкапирование «сразу по сети» надо одмину в голову гвоздь забить — это я на всякой…

   Arik777

4 — 12.11.15 — 23:01

в том то и дело этих архивов у меня куча на каждый день, только вот неверится что они все битые. со скулем все норм. если создать пустую базу допустим «test» и сделать архив, а потом восстановить из этого архива то все норм. А вот другие бэкапы другой базы ну никак нехотят восстанавливаться.

   Arik777

5 — 12.11.15 — 23:06

Согласен за гвоздь можно и вбить, но вот поверить немогу что все бэкапы битые.

   trad

6 — 12.11.15 — 23:13

Иногда вот думаешь, что ресторишь в 2008, а на самом деле 2005

инстанс точно один — 2008?

   oleg_km

7 — 12.11.15 — 23:15

Может проверить исходную базу? Типа DBCC CHECKDB

   Arik777

8 — 12.11.15 — 23:17

Ставил точно один 2008. Запускаю SQL Managment 2008.

   Господин ПЖ

9 — 12.11.15 — 23:19

   Arik777

10 — 12.11.15 — 23:20

DBCC CHECKDB немогу сделать у меня только бэкапы. Исходная база была удалена по просьбе заказчика. Я и не переживал что удаляю так как был уверен что восстановлю при необходимости.

   Arik777

11 — 12.11.15 — 23:21

Нет бэкапы не по сети а на логический диск.

   Господин ПЖ

12 — 12.11.15 — 23:22

тогда странно если прямо «все»… с диском все нормально?

   Arik777

13 — 12.11.15 — 23:27

На счет диска тоже грешил. Ему блин полгода, проверял разными средствами. Единственное на что могу хоть как грешить так это на обновления винды что ставились дня 3 назад. Но вот причем тут SQL непойму.

   Arik777

14 — 12.11.15 — 23:29

Я вот пробую создать новую базу залить туда 1с, затем делаю бэкап, затем востанавливаю и блин все норм.

   trad

15 — 12.11.15 — 23:29

Sms2008 может и с 2005 сервером работать. Посмотри в свойствах сервера

   Arik777

16 — 12.11.15 — 23:33

Прошу прощения где смотреть свойства сервера. SQL SERVER 10.0.1600

   Господин ПЖ

17 — 12.11.15 — 23:35

SQL Server 2008

   Господин ПЖ

18 — 12.11.15 — 23:38

   Arik777

19 — 12.11.15 — 23:40

Согласен что это разные вещи, но ставил я только один и один раз…

   Arik777

20 — 12.11.15 — 23:42

Я понимаю все это, поэтому и решил обратиться сюда. Я уже две сутки пытаюсь понять в чем дело. уже на др. компе ставил разные версии SQL и ничего, ставил и SQL 2012 и таже беда.

   Господин ПЖ

21 — 12.11.15 — 23:44

в sql 2000 была подобная ошибка… лечилось sp1

   Arik777

22 — 12.11.15 — 23:50

лечилось sp1.

да но на другм компе стоит вин сервер 2012 и Скуль 2012.

   Arik777

23 — 12.11.15 — 23:51

Я так понимаю что эти бэкапы уже невосстановить…

   Йохохо

24 — 12.11.15 — 23:53

не заливай в пустую, сделай ресторе в новую

   Йохохо

25 — 12.11.15 — 23:55

(19) ничего разного нет, 2008р2 последний кто помнит старые форматы

   Arik777

26 — 12.11.15 — 23:57

А как узнать скуль р2 или нет?

   trad

27 — 12.11.15 — 23:58

10.0 — 2008

10.50 — 2008r2

   trad

28 — 12.11.15 — 23:59

посмотри еще колонки softwareversion после этих команд

RESTORE HEADERONLY FROM DISK = ‘d:backupsБекапКоторыйВосстанавливается.bak’

RESTORE HEADERONLY FROM DISK = ‘d:backupsБекапКоторыйНеВосстанавливается.bak’

   Йохохо

29 — 13.11.15 — 00:01

(28) в 2008 уже можно манипулятором типа мышь

   trad

30 — 13.11.15 — 00:04

(29) научишь?

   Arik777

31 — 13.11.15 — 00:09

   Arik777

32 — 13.11.15 — 00:10

Видимо архив точно какойто битый. Может обновить скуль до р2?

   trad

33 — 13.11.15 — 00:48

(31) попробуй выполнить эту команду со стороны 2012

   Tateossian

34 — 13.11.15 — 01:09

Если не большой .bak могу у себя на серваке попробовать восстановить.

   Tateossian

35 — 13.11.15 — 01:09

(34) Скажем, до 10 Гб

   Arik777

36 — 13.11.15 — 01:48

бак 6 мб

   Arik777

37 — 13.11.15 — 01:48

базе 1 месяц

Если можешь проверь. Буду очень благодарен…

At times, when restoring a SQL Server database from a backup, you might encounter the 3241 error along with an error message ‘RESTORE HEADERONLY is terminating abnormally’.

What Causes SQL Database Error 3241, ‘RESTORE HEADERONLY is Terminating Abnormally’?

The error is caused when a backup file you are trying to restore gets corrupt due to an issue with the hardware (i.e., hard disks, network storage, etc.) or because of a malware attack. Also, you may encounter the error if you restore a backup from a recent version of SQL Server to an earlier version of SQL Server.

Note: If you get error 3241 when executing the ‘RESTORE FILELISTONLY’ statement, the error is caused due to a bug in SQL Server. To resolve the issue, install the cumulative updates released by Microsoft. For more information, read this KB.

Before We Proceed

Before attempting the solutions to troubleshoot the error, ensure the backup is readable by running the following T-SQL statement:

RESTORE VERIFYONLY FROM DISK=’ <path_to_your_backup>.BAK’

This command will check the backup file and returns a message stating whether the backup is useable or not.

If there is no problem with the backup, check your Windows System event logs for any hardware-related or networking issues. Also, ensure that you’re not restoring a database from a backup created on a higher version of SQL Server to a lower version.

If there is some issue with the backup file, proceed with implementing the following solutions.

Solutions to Resolve SQL Database Error 3241

Here’s what you can do to fix the error 3241 – that occurs due to corruption in the backup set:

• Locate another valid backup file to restore the database
• Create a new backup if the database is accessible

Alternative Solution to Restore Database from Backup

If you fail to restore the backup correctly, try to extract data from the corrupted backup (BAK) file using Stellar Repair for MS SQL Technician. The software provides a backup extractor tool to help the users recover data from a corrupt BAK file easily and quickly. After extracting the backup data, the software saves the data in a new or an existing database. You can evaluate the software functionality by downloading the demo version from the link below.

For detailed steps on using the backup extractor tool for data recovery, read this: How to Recover SQL Server Database from a Corrupt Backup File?

Stellar Repair for MS SQL Technician also comprises tools to repair a corrupt SQL database MDF, NDF files. Also, it provides a utility to reset the lost or forgotten password of master.mdf file.

End Note

You might fail to perform a backup and restore operation on a SQL Server database. And, get an error message that reads: ‘Restore HEADERONLY is terminating abnormally, Microsoft SQL Server error 3241’.  It happens when the backup you’re trying to restore is corrupt. In that case, check if you have any other backup copy you can use to restore the database or create a new backup set. If the issue persists, use Stellar Backup Extractor for MS SQL to retrieve data from a backup file.

Once you’ve retrieved your backup data and restored the database, you must prevent the 3241 media error from reoccurring. For this, do the following:

• To avoid backing up a corrupt database, ensure that the Backup CHECKSUM option is enabled. For more information, see Possible Media Errors During Backup and Restore (SQL Server).
• Use trace flag 3023 to enable CHECKSUM option when using backup utilities to perform a backup; this will ensure that the data is backed up in a healthy state. Besides, generation of backup checksum during a restore process ensures that the backup media is not damaged when transferring a copy of the SQL database.