Как восстановить iOS-устройство из бэкапа с более новой версией iOS. Невозможно восстановить журнал или разностную резервную копию так как нет файлов готовых к накату

Автоматизация настройки резервного копирования MS SQL с помощью .NET приложения

Я долго созревал, чтобы написать данную статью и выложить свое приложение. Надеюсь вам будет интересно.

О чем данная статья

В ней описан тот способ, как с помощью разработанного мною .NET приложения можно распространять план резервного копирования и проводить все необходимые настройки над БД средствами СУБД с уведомлением администратора о выполнении задач.

По максимум постараюсь описать те нюансы, с которыми мне пришлось столкнуться в ходе разработки приложения и настройки БД. Для описанных ниже задач можно использовать мастер планов обслуживания, но мне больше понравился такой подход. Основное преимущество описанного мною метода, что данный способ можно применять ко всем версиям MS SQL (кроме Express, там немного другой подход). План обслуживания можно переносить, но у вас должна быть соответствующая в версия MS SQL и все равно будет создан Job для запуска плана обслуживания.

Сравнить редакции MS SQL и их функционал вы можете вот здесь. Осторожно: перфекционисты могут испытать жжение и боль при просмотре кода моего приложения, т.к. оно было написано на скорую руку и заточено под решение конкретной задачи.

Кому подойдет данная статья:

• Тем, у кого MS SQL Express и нет возможности запускать с помощью Job задачи
• Тем, кто в ближайшем будущем планирует перейти с MS SQL 2008 на более новую версию и не хочет настраивать зеркалирование БД, а сразу на новой версии настроить AlwaysOn
• Тем, у кого нет средств для поднятия еще резервных серверов и приходится обходиться тем, что есть.
• У кого нет сжатых сроков на время восстановления БД. Главное – это результат
• Кому лень что-то делать
• Просто любопытным людям.

Оглавление:

Теория о резервном копирование

1. Журнал транзакций
2. Разностная копия БД
3. Системные базы данных
4. План бекапирования
5. Общие рекомендации по резервному копированию

Используем приложение

1. Настройка уведомления администратора
2. Дополнительные уведомления для администратора
3. Решение проблем при настройке DatabaseMail
4. Настраиваем резервное копирование с помощью приложения для SQL Standart
5. Настраиваем резервное копирование с помощью приложения для SQL Express
6. Удаление задач из БД
7. Удаление копий БД

Как восстанавливать резервные копии

Список статей хабра, которые я использовал

1. Создание и хранение резервных копий баз данных в MS SQL. Практические советы
2. Построение цепочки восстановлений баз данных MS SQL
3. Настройка Database Mail в MS SQL Server 2005 и старше
4. SQL Server 2008: бэкапим с умом. Часть 1: Теория
5. Всё что вы стеснялись спросить о бэкапах Microsoft SQL Server

Исходники на github для MS SQL Standart и для MS SQL Express Если появится желающие добавить свои мысли в код, принимаю pull request. Готов выслушать конструктивную критику и доработать приложение, если это действительно кому-то нужно будет.

Теория о резервном копирование

Все что описано в теории, вы можете найти самостоятельно. Конфигурации, которые описаны в данном разделе, автоматически будут выполнены моим приложением при настройке резервного копирования. MS SQL Server поддерживает 3 модели резервного копирования.

1. Простую
2. Модель полного восстановление
3. Модель полного восстановления с неполным протоколированием

Я выбрал для приложения модель полного восстановления, т.к. мне необходимо было иметь возможность всегда восстановить последнюю версию БД после любой операции и у меня не было одномоментных массовых операций по вставке данных. Если вы только начинаете и не знаете, как правильно выбрать, вам может помочь вот эта статья Microsoft. Для включения данного режима, необходимо выполнить следующий скрипт ALTER DATABASE [Имя базы данных] SET RECOVERY FULL;

При переключении модели восстановления на полную у нас появится следующие возможности:

1. СУБД перестанет автоматически очищать журнал транзакций . Журнал будет расти до тех пор, пока не будет сделана его резервная копия. Это важный момент, администратору БД необходимо продумать вопрос о плане резервного копирования и очистки журнала. UPD: спасибо за помощь Yggaz
2. Создание разностной резервной копии
3. Создание полной резервной копии

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

1. Журнал транзакций

Журнал транзакций является критическим компонентом базы данных и в случае системного сбоя может потребоваться для приведения базы данных в согласованное состояние.

Преимущества при восстановлении БД с помощью журнала транзакций:

1. восстановление отдельных транзакций;
2. восстановление всех незавершенных транзакций при запуске SQL Server;
3. накат восстановленной базы данных, файла, файловой группы или страницы до момента сбоя и т.д

Рекомендации

1. Вынести на быстрый жесткий диск, чтобы при большом потоке операций не было задержек при записи.
2. Необходимо делать резервные копии журнала транзакций не реже чем каждый час.
3. После создания полной (разностной) копии базы данных, все старые журналы можно удалять, т.к. они теряют свою актуальность.
4. Внимательно следите за размером диска на котором хранятся журналы транзакций, если оно закончится, то записать новые данные в БД будет невозможно, пока не произойдет уменьшение размеров журнала транзакций или не добавиться новый дополнительный файл транзакций.
5. Журнал транзакций необходимо регулярно усекать, чтобы избежать его переполнения. UPD: Как сказал kolu4iy данная операция по усечению слегка сомнительна в плане производительности, т.к. при бэкапирование журнал транзакции очищается внутри и СУБД начинает писать в нем по новой. Однако у вас может возникнуть ситуация, которую описал я в своем комментарии и тогда это вам может пригодиться.
6. Возможна ситуация, когда невозможно сразу сделать усечение журнала. Они описаны в данной статье
7. Для получения информации о состоянии базы данных можно с помощью следующего запроса: select name,log_reuse_wait, log_reuse_wait_desc from sys.databases
8. При необходимости можно получить информацию о последних открытых транзакциях DBCC OPENTRAN (Имя базы данных) WITH TABLERESULTS

Пример SQL скрипта для выполнения резервного копирования журнала транзакции с последующим усечением файла.BACKUP LOG [Имя базы данных] TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL\MSSQL\Backup\[Имя файла].bak' WITH NOFORMAT, NOINIT, NAME = N'Журнал транзакций Резервное копирование', SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO USE [Имя базы данных] GO DBCC SHRINKFILE (N'Имя файла лога БД' , 25) GO Эти же операции можно проделать с помощью SSMS

2.Разностная копия БД

Разностное резервное копирование основано на самой последней предыдущей полной резервной копии данных. В разностной резервной копии сохраняются только те изменения, которые были произведены с момента создания последней полной резервной копии. Рекомендации:

1. Используйте разностные копии БД, если создание полной копии БД занимает большой промежуток времени
2. Периодически делайте полную копию БД, чтобы уменьшить объемы создаваемых разностных копий.
3. После создания полной копии БД, все предыдущие разностные копии теряют свою актуальность.

Более подробно о рекомендациях по частоте созданию разностных резервных копий, можно прочитать здесь.

Приведу небольшой пример из практики, почему мы стали использовать разностную копию. Со временем у нашего клиента разрослась база данных до таких размеров, что создание полной резервной копии занимало 8 часов, еще несколько месяцев и возможно к началу рабочего дня не успевало бы завершиться данная операция. После перевода на разностное резервное копирование, мы сократили время с 8 часов до 2-4 минут (в зависимости от дня недели). Раз в неделю мы делали полную копию БД.

Пример SQL для создания резервной разностной копии БД с проверкой копии по завершению (отличается от полного копирования флагом DIFFERENTIAL вместо него нужно использовать NOFORMAT).

declare @pathBackup as varchar(55) set @pathBackup = N'C:\Backup\[Имя файла БД]_' + REPLACE(convert(varchar,GETDATE(), 104),'.','_') + '.bak' BACKUP DATABASE [Имя базы данных] TO DISK = @pathBackup WITH DIFFERENTIAL, NOFORMAT, INIT, NAME = N'Полная База данных Резервное копирование', SKIP, NOREWIND, NOUNLOAD, STATS = 10, CHECKSUM GO declare @backupSetId as int declare @pathBackup as varchar(55) set @pathBackup = N'C:\Backup\[Имя файла БД]_' + REPLACE(convert(varchar,GETDATE(), 104),'.','_') + '.bak' select @backupSetId = position from msdb..backupset where database_name=N'[Имя базы данных]' and backup_set_id=(select max(backup_set_id) from msdb..backupset where database_name=N'[Имя базы данных]') if @backupSetId is null begin raiserror(N'Ошибка верификации. Сведения о резервном копировании для базы данных "[Имя базы данных]" не найдены.', 16, 1) end RESTORE VERIFYONLY FROM DISK = @pathBackup WITH FILE = @backupSetId, NOUNLOAD, NOREWIND GO

3.Системные базы данных

Помимо основной базы и связанных с ней файлов, я настоятельно рекомендую делать копии и системных баз данных. Начнем с того, что рассмотрим какие базы существуют в MS SQL. Их всего 5:

Название	Описание
База данных master	В этой базе данных хранятся все данные системного уровня для экземпляра SQL Server.
База данных msdb	Используется агентом SQL Server для планирования предупреждений и задач.
База данных model	Используется в качестве шаблона для всех баз данных, создаваемых в экземпляре SQL Server. Изменение размера, параметров сортировки, модели восстановления и других параметров базы данных model приводит к изменению соответствующих параметров всех баз данных, создаваемых после изменения.
База данных resource	База данных только для чтения. Содержит системные объекты, которые входят в состав SQL Server. Системные объекты физически хранятся в базе данных Resource, но логически отображаются в схеме sys любой базы данных.
База данных tempdb	Рабочее пространство для временных объектов или взаимодействия результирующих наборов.

Более подробно можете прочитать о них тут и еще вот тут.

Я выбрал резервировать только 2 системные БД:

1. msdb – потому что, там хранятся настроенные задачи и другие
2. master – хранятся все произведенные настройки SQL Server.

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

4. План бекапирования

На основе выше описанного составим наш план резервного копирования данных. Он может отличаться от того, что потребуется вам, все зависит от требований к восстановлению БД. Когда я подготавливал план, мне пришлось учесть, что необходимо восстановить данные максимально и потеря данных составляла не больше одного часа.

Мы будем делать следующие резервные копии:

• Полная копия основной БД, чаще чем раз в неделю нет необходимости
• Разностная копия основной БД, каждый день
• Копии журнала транзакций основной БД, каждый час
• Копия системной БД master, раз в неделю
• Копия системной БД msdb, раз в неделю

В итоге у нас получился следующий план резервного копирования данных:

День недели	Время	Действия	Частота	Описание
Понедельник — Пятница	С 8-00 до 21-00	Резервные копии Журнала транзакций	Каждый час	После выполнения резервной копии БД идет сжатие и усечение журнала транзакций
Суббота — Воскресенье	С 8-00 до 18-00
Понедельник – Воскресенье	22-00	Разностная копия основной БД	1 раз в день	После успешного выполнения разностной копии удаляются все старые копии журнала транзакций
Суббота	12-00	Проверка БД	1 раз в день	Проверка БД Дело на целостность.
Суббота	18-00	Создание полной копии БД	1 раз в день	По завершению данной операции идет уведомление на почту.   Если создание резервной копии прошло удачно, удаляется старая полная резервная копия все старые разностные копии все старые журналы транзакций
Понедельник – Воскресенье	23-30	Создание копии системной базы master	1 раз в день	Хранится всегда только последний экземпляр БД
Воскресенье	12-30	Создание копии системной базы msdb	1 раз в месяц	Хранится всегда только последний экземпляр БД

5. Общие рекомендации по резервному копированию

1. Используйте опцию BACKUP WITH CHECKSUM чтобы убедиться, что все прошло хорошо. Недостатком такого решения является то, что для больших баз данных проверка контрольной суммы может серьезно загрузить систему.
2. Не выполняйте резервное копирование файлов на тот же физический диск, на котором хранится база данных или протокол транзакций.
3. Если вы используете MS SQL 2008 или выше, рекомендую вам использовать сжатие резервных копий средствами SQL. Следующий код включит сжатие по умолчанию: USE master; GO EXEC sp_configure ‘backup compression default’, '1'; RECONFIGURE WITH OVERRIDE;
4. держите резервные копии по нескольку дней на случай, если одна из них будет повреждена – старая резервная копия лучше, чем никакой.
5. Используйте DBCC CHECKDB для проверки каждой базы данных перед копированием, это своевременно предупредит вас о надвигающихся проблемах. DBCC CHECKDB ('Имя базы данных') WITH NO_INFOMSGS, ALL_ERRORMSGS; Примечание: на практики мы использовали данную проверку, только перед выполнением полной резервной копии.
6. Выполняйте периодически обновление статистики и реорганизации индексов БД

Используем приложение

Несколько нюансов по приложению:

• Все тексты и запросы в коде вынесены в ресурсы, мне так было проще
• При вводе параметров соединения и других настроек, они сохраняются в файл. Для Express и Standart используются разные файлы (dbStandart, udExpress) в них хранится класс UserData
• Для выполнения некоторых операций могут потребоваться права администратора
• На данный момент не работает соединение с БД под доменной учетной записью
• Программа не обладает суперкрасивым интерфейсом

1. Настройка уведомления администратора

Мне было лень каждый раз заходить на сервер и проверять, сработала ли задача или произошла какая-то ошибка. Да и хотелось иметь возможность получать другие уведомления, не только о выполнения задач.

Для данной цели используется DatabaseMail MS SQL (для версии Standart и выше) В своем приложение я сделал специальный раздел для автоматизации данной задачи

При нажатии появится форма для заполнения информации необходимой для создания профиля рассылки писем:

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

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

Дальше, с данного ящика от указанного оператора, к нам будут приходить уведомления об успешном выполнении операций. Выполняемые действия на данном этапе:

1. Меняются системные параметры MS SQL.
2. Создается DatabaseMail Profile
3. Активируется в SQL Agente профиль
4. Создается DatabaseMail Account
5. Добавляется DatabaseMail Account к Database Mail Profile
6. Создается DatabaseMail Operator

Более подробно описано в следующей статье и, частично, я брал отсюда. Естественно, данные действия можно выполнить с помощью SSMS.

2.Дополнительные уведомления для администратора

В программе предусмотрены 2 задачи, применяемые к БД:

1. проверка целостности БД. Для проверки базы данных использовалась стандартная процедура DBCC CHECKDB.
2. информирование о свободном месте в файловых группах.
3. Вторая задача была реализована с помощью запроса к системной таблице dbo.sysfiles
4. Вот пример данного запроса, который выполнялся к базе:

Select NAME = left(a.NAME,15), a.FILEID, [FILE_SIZE_MB] = convert(decimal(12,2),round(a.size/128.000,2)), [SPACE_USED_MB] = convert(decimal(12,2),round(fileproperty(a.name,'SpaceUsed')/128.000,2)), [FREE_SPACE_MB] = convert(decimal(12,2),round((a.size-fileproperty(a.name,'SpaceUsed'))/128.000,2)) , FILENAME = a.FILENAME From dbo.sysfiles a Ответ с сервера приходит на почту администратора в виде html разметки. Данный синтаксис возможен благодаря следующей стандартной функции MS SQL FOR XML.

Так же пока я искал, как преобразовать в возвращаемый результат выполнения запросов в html текст, наткнулся на следующую страницу, где человек создал целую процедуру для этих целей Настроить эти операции можно с помощью соответствующего пункта в меню программы:

Появиться окно для указания почтового ящика, на который необходимо высылать html текст отчета:

3.Решение проблем при настройке DatabaseMail

В MS SQL 2008 я столкнулся с проблемой при настройке SQL Server Agent. Симптомы следующие, после настройки невозможно запустить SQL Agent. В основном это решается с помощью установки update на SQL сервер.

Убедитесь, что установлен sp1, а потом можно уже ставить обновление.

Если данные обновления не помогают, необходимо скачать fix. Его можно найти на данном сайте конечную ссылку не могу указать сейчас, для того что бы дойти до пакета фикса, нужно будет ответить на ряд вопросов. Если есть проблемы с модулем DatabaseMail. После настройки данного модуля с помощью приложения, необходимо зайти в SQL Agent и просмотреть журнал событий. Если там будут ошибки «невозможно подключиться к почтовому ящику». Значит есть проблема, даже если через проверку отправляется письмо.

Исправляется это следующими манипуляциями:

1. Management Studio — SQL Server Agent — Properties.
2. Alert System
3. Уберите галочку с Enable mail profile
4. Нажмите OК
5. Зайдите снова и поставьте галочку
6. Перезагрузите SQL Server Agent.

Проверьте учетную запись для SQL Agent service. Если это доменная учетная запись измените ее на системную или наоборот. Все должно заработать.

4.Настраиваем резервное копирование с помощью приложения для SQL Standart:

Выбираем версию Standart. Настраиваем уведомления. (см. раздел, настройки уведомления):

Соединяемся с БД, заполняя данные для соединения и указываем БД, для которой будет применяться Job:

Выбираем настройку резервного копирования:

Указываем пути для сохранения копий БД. Если указанные папки не существует, то программа попытается их создать (нужны соответствующие права).

Нажимаем сохранить и базе настраиваются соответствующие задачи. Желательно настроить для каждого бэкапа разные папки, т.к. при удалении будут удаляться все файлы с расширением bak. (см. раздел удаление копий БД)

5.Настраиваем резервное копирование с помощью приложения для SQL Express:

Так как в SQL Express отсутствует SQL Agent, задачу по автоматизации резервного копирования пришлось решить другим путем. В указанной пользователем папке создается bat файле в котором описан SQL запрос, отвечающий за создание резервной копии. В случае необходимости можно редактировать его напрямую. По мимо этого должен работать стандартный планировщик Windows, в нем создается задача, которая будет запускать раз в сутки в указанное время.

Для этого запускаем приложение. Выбираем пункт MS SQL Express:

Появляется форма для заполнения параметров:

Указываем где будет сохраняться наша копия, а также где будет лежать bat файл для создания копии базы (имя файла указывать не надо, оно будет задано автоматически). Далее указываем настройки соединение и время, когда необходимо запускать задачу.

Единственный минус данного подхода в том, что приходится храниться в открытом виде пароль для соединения с БД.

6.Удаление задач из БД.

Если необходимо удалить все задачи из БД (например, захотели изменить пути сохранения БД). Для этого используем соответствующий пункт в меню программы. Из SQL Agent будут удалены все задачи с определенным начальным префиксом (в моем случае King):

7.Удаление копий БД

В некоторых задачах, настроено удаление старых копий БД. Для этого я использую процедуру master.dbo.xp_delete_file. Пример использования: Удалит все файлы с расширением bak из указанной папки, дата создания которых превышает 14 дней. EXECUTE master.dbo.xp_delete_file 0,"E:\backups",N'bak',dateadd(d,-14,getdate()),0; И вот еще один более подробный пример и информация о том, какие параметры принимает данная функция.

Как восстанавливать резервные копии

Из-за нехватки времени модуль восстановления еще не реализован, возможно в будущем я его добавлю, а пока просто кратко опишу как можно будет восстановить базу.

С помощью SQL скрипта. Для восстановления базы данных используется команда RESTORE.

Если необходимо восстановить просто базу из полной копии, то достаточно выполнить следующий скрипт:

RESTORE DATABASE [Имя базы данных] FROM DISK = 'Z:\SQLServerBackups\back.bak' WITH REPLACE В случае, если необходимо восстановить последовательно сначала полную копию, разностные копии и журналы транзакций, тогда необходимо написать следующий SQL скрипт.RESTORE DATABASE TEST_DB –восстанавливаем полную копию FROM test_db_full WITH NORECOVERY; GO RESTORE DATABASE TEST_DB –восстанавливаем разностную копию FROM test_db_diff WITH FILE = 1, NORECOVERY; GO RESTORE LOG TEST_DB –восстанавливаем журнал транзакций №1 FROM test_db_tran_1 WITH FILE = 1, WITH NORECOVERY; GO RESTORE LOG TEST_DB –восстанавливаем журнал транзакций №2 FROM test_db_tran_2 WITH FILE = 1, WITH NORECOVERY; GO RESTORE DATABASE TEST_DB WITH RECOVERY; GO Для восстановления БД можно использовать так же и SSMS.

habr.com

MS SQL восстановление разностного бэкапа

Вопрос: Win 7 восстановление после 0x000006F и 0xc00000225

Всем привет. Имеется компьютер с слетевшей win7 домашняя расширенная 32бит. После неких неизвестных манипуляций с машиной при загрузке выдавал ошибку 0x000006F. При этом не грузился в безопасном режиме и показывал "insert disk..." Железо в норме. При заходе с флешки в режиме восстановления, при сканировании проблем запуска показывал ошибки, пытался восстановить (или писал, система загружается нормально), но при перезагрузке также писал 0x000006F.

Необходимо восстановить работоспособность системы. Сложность еще в том, что пользователь устанавливал программы не на системный диск, а на диск "D" с данными.

Что было сделано: 1. Пытался восстановить средствами восстановления msdart, но сканирование системных файлов прерывается с ошибкой в самом начале. 2. sfc /scannow пишет, что необходимо перезагрузить компьютер для продолжения сканирования и продолжить, однако после перезагрузки пишет тоже самое. 3. Пытался подставлять boot.cache (его нет в папке). 4. Поставил на свободное место вторую win7 (все нормально ставится, грузится и работает), с нее, с помощью easyBCD переписывал загрузчик. 6. Обратил внимание на то, что новая система встала на диск С, не смотря на то, что диск С был под старой системой. К сожалению, не могу сказать, какая буква была изначально на системе, которую необходимо восстановить, потому - попытался поменять буквы так, чтобы "С" была на системе, которую нужно восстановить, а "D" на диске с данными (с помощью diskpart и копания в реестре), после этой манипуляции не загружалось НИЧЕГО. Заново установил новую систему, и она снова прописала себя на "С".

В данный момент в "управлении дисками" показывает 4 диска: recovery backup(буква на него меняется, емкость около 10гб, но занято около 100мб), "С"- стоит новая работающая система, "D"-старая система, которую нужно восстановить, "E"-диск с данными.

Очень важно восстановить работоспособность старой системы с работающими программами.

Мне кажется, что каким-то образом нужно восстановить системные файлы в старой системе (возможно - нарыть где-то бэкап и поменять с помощью проводника mcdart, или sfc), затем переписать загрузчик. Но предварительно, нужно поменять буквы диска"D" и "Е" на то, как они были раньше (возможно есть способ узнать, какие буквы были?) на "С" и "D".

Заранее спасибо за помощь.

Ответ: Восстановление может помочь, если буквы дисков изменились? Там же масса программ прописаны на старом диске "D". Есть какой-либо способ изменить идентификаторы\буквы дисков, чтобы подсунуть их потом в загрузчик?

forundex.ru

проблема с восстановлением из резервной копии

Вопрос: Проблемы восстановления после переназначения папки бэкапов

День добрый!

Неожиданно обнаружилась проблема при попытке восстановления БД с полной моделью.

Преамбула:

1. Используется MS SQL 2014.2. Для некоторых БД используется полная модель восстановления.3. В самом начале (и самая первая БД) бэкапилась в папку "E:\MSSQL\Backup\", но по мере подключения новых БД было принято решение перенести хранилище бэкапов на другой физический диск и для каждой БД использовать свою папку вида "F:\MSSQL\Backup\Имя_БД\".4. Для этого в операциях резервного копирования планов обслуживания были изменены расположения целевых объектов (для бэкапов самих баз) и папки (для бэкапов журналов). Так же в свойствах сервера (Параметры баз данных) было изменено дефолтное имя папки бекапов на "F:\MSSQL\Backup\", хотя это больше косметическое изменение.

А вот теперь амбула:

Вчера потребовалось сделать откат одной БД. Жму на БД "ПКМ|Задачи|Восстановить|База данных ...". Источник - база данных.MSSQL сам находит все последние сохранения - полные, разностные, журналов транзакций. Остается только поснимать ненужные галочки.Сделав это, жму на "Проверка носителя резервной копии". После чего выскакивает ошибка "Ошибка проверки носителя резервной копии (ВНИМАНИЕ!!!) E:\MSSQL\Backup\Backup_Thu-Sat.bak", хотя резервные копии находятся давно уже на другом диске и в другой папке (F:\MSSQL\Backup\Zarplata\Backup_Thu-Sat.bak). БД, соответственно, восстановить из-за этой ошибки невозможно.

Делаю по другому. Выбираю в качестве источника "Устройство", нахожу и добавляю вручную файл бэкапа. Возникает список точек восстановления - полной и разностных, хранящихся в этом файле, но уже без сохранений журнала транзакций (не добавлять же еще вручную и их - нудно).В этом случае восстановление происходит нормально.

Хорошо, что мне пришлось откатываться более, чем на двое суток через несколько разностных копий. В этом случае восстановление по транзакциям все равно не работает.А если бы мне понадобилось восстановится на полчаса-час назад, а не до ближайшей точки разностного (полного) копирования? Может быть каким-то шаманством это и получилось бы сделать, но весьма муторошно. Например, скопировать файлы резервных копий БД и журнала транзакций на старое место. Или загружать вручную файлы копий не только БД, но и всех сохранений журнала.Короче, ситуация исключает быстрое, простое и оперативное решение.

Почему БД пытается искать резервные копии по старому адресу - так и не понял. Посему вопросы:

1. Где БД хранит расположение резервных копий в, якобы, котором они должны находиться?2. Почему бэкапы давным-давно создаются в другом месте, а БД до сих пор ищет их по старому адресу (хотя сам список последних бэкапов данных и журнала помнит правильно)?3. Как это лечить, в конце-концов? Предложение "снести БД напрочь, воссоздать из дампа 1С, и настроить все планы обслуживания и копирования заново" рассматриваются, но не принимаются всерьёз.

forundex.ru

Ошибки при бэкапе

Вопрос: Непреодолимая проблема с бэкапом скуля в сеть

Вопрос простой,однако попытка решения этого вопроса заняла у меня 12 часов без передышки,и решить его я так и не смог.Прошу помощи.Итак ,краткое описание инфраструктуры:Имеется 5 серверов - Терминальный,файловый,баз данных,прокси,ну и само собой бэкап (небольшое предприятие,админю управление состоящее из ~50 сотрудников,так что домена нету,и я думаю он не нужен) Сервера полностью собирал и настраивал сам,недавно перевел все на 2016 Windows server и 2016 SQL Server (в случае с сервером баз данных)Сервера полностью исправны и работоспособны,мониторинг журналов делается каждый день,ошибки если есть то фиксятся сразу.Собственно суть:Решил делать бэкап баз скуля встроенными средствами обслуживания SQL,дабы не изобретать костылей и добавлять дополнительные уязвимости в работе (делаю все всегда максимально просто,но при этом надежно)Задача казалась бы простая,расшарь папку,дай права доступа,и заливай бэкапы.Ну собственно на сервере обслуживания была создана и расшарена папка с полными правами для всех (на момент обкатки само собой)Был составлен план обслуживания,заданы параметры,прописан путь до сервера и расшаренной папки,и казалось бы,все должно работать но нет - при выполнении бэкапа сразу же вкидывается эррор - ошибка операционной системы 5 отказано в доступе.Подумав 2 секунды,решил загуглить,ответы нашлись,однако ничего нового я для себя не узнал,везде пишут черным по белому-дай права на папку для учетки сервиса скуля (естественно права то были полные для всех на папку,так что это не актуально для меня)Поискав еще немного,нашел предложение создать устройство бэкапа,и сливать на него,но и тут выдается та же самая ошибкаБыли так же предложены варианты дать сервисам скуля вход в систему с системной учетной записью ,или с учетной записью сетевой службы,варианты эти я тут же обкатал,задавал параметры учетной записи и давал права на вышеуказанные учетки,сути как оказалось это не меняет-ошибка операционной системы 5 и все тут.Вобщем извозившись вдоль и поперек,понял что ,что то я видимо упускаю,и решил обратиться за помощью на форум.Помогите пожалуйста разобраться с этим вопросом ,что я делаю не так,что я упускаю.

К сообщению приложен файл. Размер - 131Kb

forundex.ru

Как восстановить iOS-устройство из бэкапа с более новой версией iOS – Проект AppStudio

iTunes полон различных ограничений, среди которых встречаются как оправданные здравым смыслом, так и совершенно маразматические. Одно из наиболее неприятных ограничений iTunes, с которым периодически сталкиваются многие пользователи – невозможность восстановить iPhone или другое iOS-устройство из резервной копии, сделанной на более новой версии iOS. Иными словами, если ваш старый iPhone был с iOS 7.0.4, а новый – с iOS 7.0.3, то восстановить его из резервной копии от свежей прошивки не выйдет, iTunes заблокирует восстановление в самом начале.

Но немногие пользователи знают, что это ограничение легко обойти. Проблема решается за пару минут.

iTunes не слишком пристально контролирует соответствие версий. Внутри каждой резервной копии есть файл с описанием бэкапа, в котором отдельной строкой прописывается версия iOS, с которой делалась копия. iTunes смотрит только на эти цифры и сверяет их с версией iOS на устройстве, которое вы собираетесь восстановить из резервной копии. Догадываетесь, что будет, если в этом файле описания бэкапа исправить версию iOS на ту, что вам нужна? :)

Рассмотрим практический пример. У нас есть новенький iPhone 5s с iOS 7.0.4 на борту и резервная копия, сделанная на iPhone 5 с iOS 7.1 beta 2. Пытаться восстановить данные из этой копии бесполезно, iTunes начнёт ругаться на несоответствие версий и выдаст ошибку «Не удается восстановить резервную копию на этот iPhone, так как ПО на iPhone устарело». Что ж, обдурим iTunes.

На Маке в любом окне Finder нужно нажать клавиатурную комбинацию Cmd+Shift+G и ввести путь ~/Library/Application Support/MobileSync/Backup

Вы окажетесь внутри папки с бэкапами. Вы увидите столько папок, сколько у вас бэкапов, причём каждый будет называться по имени UDID соответствующего устройства. Чтобы разобраться в том, где нужный бэкап, проще заглянуть в свойства каждой из этих папок и посмотрев на дату изменения. Затем зайдите в настройки iTunes на вкладку «Устройства» и посмотрите, какой бэкап соответствует этой дате:

После того, как вы найдете нужный бэкап, пора заглянуть внутрь его папки. Там вам понадобится файл Info.plist. Откройте его в любом текстовом редакторе и запустите текстовый поиск по словам «Product Version». В строке ниже исправьте версию iOS на ту, что сейчас установлена на устройстве, которое вы собираетесь восстанавливать из этой резервной копии:

Сохраните файл. Теперь iTunes без проблем согласится на восстановление из отредактированной вами резервной копии.

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

P.S. В Windows бэкапы iTunes лежат в папке C:\Users\Username\AppData\Roaming\Apple Computer\MobileSync\Backup.

appstudio.org

Восстановление бэкапа

31.08.2016 16:05:56Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %utilsda 0,00 4,20 0,00 1,00 0,00 0,02 41,60 0,01 10,00 0,00 10,00 10,00 1,00sdc 0,00 13,20 0,00 197,80 0,00 3,82 39,58 0,44 2,21 0,00 2,21 1,67 33,10sdb 0,00 13,20 0,00 197,60 0,00 3,78 39,14 0,38 1,91 0,00 1,91 1,56 30,76sdd 0,00 14,60 0,00 199,80 0,00 3,80 38,91 0,48 2,38 0,00 2,38 1,82 36,38sdf 0,00 13,60 0,00 196,40 0,00 3,78 39,46 0,42 2,16 0,00 2,16 1,69 33,24sde 0,00 12,80 0,00 200,40 0,00 3,85 39,37 0,49 2,45 0,00 2,45 1,82 36,50md126 0,00 0,00 0,00 449,60 0,00 19,03 86,69 0,00 0,00 0,00 0,00 0,00 0,00 31.08.2016 16:06:01Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %utilsda 2,60 1,40 0,40 17,20 0,01 0,03 4,82 0,05 2,59 19,00 2,21 2,52 4,44sdc 0,00 11,80 0,20 204,20 0,00 3,77 37,74 0,44 2,18 7,00 2,17 1,73 35,28sdb 0,00 13,20 0,00 200,40 0,00 3,76 38,45 0,40 1,97 0,00 1,97 1,58 31,58sdd 0,00 13,60 0,20 206,80 0,00 3,84 38,01 0,43 2,08 9,00 2,07 1,69 34,90sdf 0,00 12,00 0,00 201,60 0,00 3,73 37,94 0,40 1,98 0,00 1,98 1,58 31,90sde 0,00 13,00 0,00 201,20 0,00 3,77 38,41 0,44 2,18 0,00 2,18 1,67 33,54md126 0,00 0,00 0,40 452,80 0,00 18,88 85,31 0,00 0,00 0,00 0,00 0,00 0,00 31.08.2016 16:06:06Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %utilsda 0,00 0,80 0,00 5,80 0,00 0,02 5,79 0,04 7,34 0,00 7,34 4,34 2,52sdc 0,00 14,80 0,00 200,20 0,00 4,42 45,23 0,46 2,29 0,00 2,29 1,77 35,52sdb 0,00 15,40 0,00 197,80 0,00 4,40 45,59 0,50 2,55 0,00 2,55 1,93 38,12sdd 0,00 15,40 0,00 199,60 0,00 4,44 45,60 0,45 2,25 0,00 2,25 1,75 34,94sdf 0,00 15,80 0,00 201,00 0,00 4,47 45,50 0,44 2,20 0,00 2,20 1,81 36,48sde 0,00 16,80 0,00 198,00 0,00 4,43 45,85 0,46 2,30 0,00 2,30 1,72 34,04md126 0,00 0,00 0,00 472,20 0,00 22,17 96,14 0,00 0,00 0,00 0,00 0,00 0,00

forundex.ru

Типичные ошибки бэкапа и как их избежать / Блог компании AflexDistribution / Хабр

О работе с резервными копиями написано много статей. Казалось бы, основные принципы бэкапа не меняются уже много лет, но всё дело в деталях этого процесса. На практике даже у опытных админов встречаются ошибки, которые они считают «не багом, а фичей» и продолжают повторять. В айтишном фольклоре есть хорошая поговорка: «Админы делятся на тех, кто не делает бэкапы, и тех, кто уже делает». Однако сегодня компания любого профиля активно использует десятки программ и онлайновых служб, поэтому просто создавать резервные копии уже недостаточно. Длительная недоступность общей базы, привычных средств связи и клиентских сервисов может привести к нарушению работы всей системы корпоративных коммуникаций и большим убыткам. В этой статье мы рассмотрим типичные ошибки при создании резервных копий и способы свести вероятность их появления к минимуму.

1. Создание бэкапов вручную

Этот метод широко использовался в девяностых и соответствовал задачам своего времени. Суть его проста: админ делает бэкап когда сможет, стараясь по возможности придерживаться намеченного графика. Все или почти все задачи резервного копирования при этом производятся вручную. Сначала подключается хранилище бэкапов или проверяется его доступность по сети. Затем запускается программа для создания резервных копий. В ней задаются нужные каталоги на источнике и параметры операции. Продвинутые админы используют частичную автоматизацию (шаблоны, скрипты, пакетные файлы), но даже с ними многое требуется выполнять и контролировать вручную.

Сегодня практика ручного создания бэкапов приводит к низкой надёжности системы резервного копирования. Один из её ключевых показателей – RPO (Recovery Point Objective), становится недопустимо высоким. Он отображает период, за который может произойти невосстановимая потеря данных. Со времени последнего бэкапа до возникновения сбоя оказываются утрачены самые новые и актуальные для текущей работы файлы. Единственный способ снизить потери – делать бэкапы чаще (несколько раз в день), но создавать их так часто вручную просто невозможно.

2. Сохранение бэкапов без их проверки

Наличие резервной копии ещё не гарантирует возможность восстановления из неё. Процедура создания бэкапов обычно длится долго, и админы не хотят тратить дополнительное время на их проверку. Пренебрежение валидацией резервных копий часто приводит к тому, что последний бэкап по какой-то причине оказывается повреждённым. Тогда показатель RPO ухудшается вдвое, поскольку приходится использовать предыдущий (более старый) бэкап, и хорошо, если он вообще есть.

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

3. Перезапись существующих данных при восстановлении из повреждённого бэкапа

Бэкапы записываются блоками. Если контрольные суммы этих блоков совпадают, то резервная копия считается созданной успешно. При этом сами данные в бэкапе не проверяются. Они могут изначально считываться повреждёнными и сохранятся в таком виде. При попытке восстановления из бэкапа происходит перезапись оригинальных файлов, что усугубляет проблему. Исходные файлы больше не восстановить, поскольку новые имеют те же самые имена и оказались повреждены. Поэтому есть смысл делать промежуточный бэкап уже после сбоя и до начала процедуры восстановления из резервной копии. Так сохраняется возможность откатится и при необходимости выполнить частичное восстановление файлов из разных бэкапов.

4. Отсутствие контроля за свободным местом для бэкапа

Эта проблема особенно характерна для ручного создания резервных копий. По мере роста объёма исходных данных для их полного бэкапа требуется всё больше места. В какой-то момент следующая копия не умещается в оставшийся объём, и длительный процесс её создания завершается с ошибкой. Часто такая ситуация вызывает целый каскад новых ошибок. Например, для увеличения свободного места админ может удалить один из прежних бэкапов и по ошибке выбрать не тот. Во избежание подобных ситуаций, в Acronis Backup (Advanced) можно создавать планы резервного копирования и указывать время жизни каждого бэкапа. Старые будут автоматически удаляться после того, как потеряют актуальность.

5. Удаление предыдущей копии бэкапа до того, как будет создана новая

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

Какие из всего сказанного выше можно сделать выводы?

Самые распространённые ошибки бэкапа возникают под влиянием человеческого фактора. Поэтому современные программы для резервного копирования развиваются по пути всё более глубокой автоматизации рутинных действий. Они учитывают особенности современных практических задач и позволяют свести вероятность ошибки к минимуму. Более подробно выводы я сформулирую в своей следующей статье.

Полезные ссылки: » Вебинары по бэкапу и защите данных » Демоверсия для бэкапа корпоративных серверов Acronis Backup Advanced » Сравнение Acronis и Veeam

Не забывайте бэкапиться вовремя, Друзья!

habr.com

---

• 
  Какой роман булгакова увидел свет в начале 60 годов в журнале новый мир
• 
  Журнал бурда моден модели в стиле бохо из льна с выкройками на русском
• 
  Журнал для детей от 5 до 10 лет шляпа speak out for kids
• 
  Ложись в больницу с детьми в двухстах журналах наиболее точно подскользнуться на льду
• 
  Журналы по вязанию спицами для детей от 0 до 3 лет с описанием
• 
  Самый лучший радар детектор 2016 года с gps от журнала за рулем
• 
  Рейтинг топ 25 самых значимых книг по менеджменту по версии журнала time
• 
  Британский журнал times higher education the опубликовал рейтинг 1000 лучших вузов мира
• 
  Сценки ко дню пожилых людей для детей из журнала как развлечь гостей
• 
  Мой старший брат когда учился в институте стал печататься в журнале юность
• 
  Журнал учета мероприятий по улучшению условий по охране труда с суммами затрат