Перенос данных бэкапа новой версии ms sql server на более старую версию / хабр

Введение

Логи транзакций растут при выбранной полной модели восстановления в настройках баз данных. Эта модель подразумивает под собой периодическое резервное копирования лога транзакций. Если вы не бэкапите логи транзакций sql вам лучше перевести свою базу данных на простую модел восстановления
и логи транзакций расти не будут, а соответственно отпадает надобность в сжатии (шринке) лога.

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

Просто и сердито. Архивирование (backup) типовых конфигураций 1С 8.2, 8.3

После эксплуатации различных «бесплатных» обработок и скриптов решил написать свой cmd-файл для ежедневного архивирования баз 1С.
Работает на конфигурациях, где есть процедуры «ЗавершитьРаботуПользователей» и «РазрешитьРаботуПользователей» (т.е. во всех типовых, в нетиповые данные модули можно скопировать из типовых).
Сохраняет файлы как локально так и на удаленном файловом сервере. Автоматически удаляет старые архивы и копирует на удалённый сервер отсутствующие.
Расписание задается установкой соответствующего задания (запуска cmd-файла по времени) в планировщике задач Windows.
Для борьбы с зависшими сеансами, рекомендуется настроить в режиме конфигуратора параметры информационной базы: «Время засыпания пассивного сеанса» и «Время завершения спящего сеанса».

Достоинства

1) Возможность создания полной копии базы из программы 1С средставами SQL сервера.

2) Возможность созданий разностной копии базы из программы 1С средставами SQL сервера.

3) Сохранение настроек подключения к SQL серверу для последующих выполнений копий в хранилище настроек пользователя либо в константы(в константы удобно, если в штате несколько программистов)

4) Автоматическая проверка существующих резервных копий баз.

5) Работает на обычных/управляемых формах.

6) Выполняется не зависимо от нахождения серверной и клиентской части (пример: если SQL сервер стоит отдельно от клиентской части).

7) Сжатие архива

«2iS:Администратор» — центр управления инфраструктурой 1С

Без изменения конфигураций инфобаз Вы получаете:
— Из единой точки регистрацию и обслуживание баз, серверов 1С и СУБД
— Мониторинг и контроль любых заданий
— Контроль за аппаратными ресурсами и анализ производительности
— Централизованные контроль за версиями и авто обновления конфигураций
— Отчеты по работе SQL и многое другое…

Как следствие:
— Снижение затрат на ИТ-поддержку
— Снижение влияния “человеческого фактора”
— Улучшение качества обслуживания
— Увеличение производительности Ваших систем

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

20000 руб.

Управление метаданными при восстановлении базы данных на другой экземпляр сервера

Чтобы обеспечить целостность работы пользователей и приложений при восстановлении базы данных на другой экземпляр сервера, на новом экземпляре необходимо повторно создать некоторые или все метаданные, например имена входа и задания. Дополнительные сведения см. в статье Управление метаданными при обеспечении доступности базы данных на другом экземпляре сервера (SQL Server).

Просмотр файлов данных и журналов в резервном наборе данных

RESTORE FILELISTONLY (Transact-SQL)

Восстановление файлов и файловых групп в новом расположении

Восстановление файлов и файловых групп поверх существующих файлов

Восстановление файлов и файловых групп поверх существующих файлов (SQL Server)

Восстановление базы данных с новым именем

Restore a Database Backup Using SSMS

Перезапуск прерванной операции восстановления

Перезапуск прерванной операции восстановления (Transact-SQL)

Изменение владельца базы данных

sp_changedbowner (Transact-SQL)

Копирование базы данных с помощью управляющих объектов SQL Server (SMO)

«Что? Где? Когда?» или журнал изменений с восстановлением состояния реквизитов ссылочных объектов (для платформ выше 8.2.16+, любой конфигурации, управляемые формы)

База данных «сама» меняет данные в документах/справочниках? Тогда данный журнал изменений для Вас! Практически не влияет на скорость записи объектов за счет быстрого алгоритма! Скорость записи на 10-15% выше типового механизма «История изменений»! Позволяет следить за изменениями в любых ссылочных объектах конфигурации, с возможностью архивации, свертки данных в другой базе. А так же, может восстановить состояние реквизитов (значения) до момента изменения или удаления объекта из базы. Ну и конечно – подробная бесплатная справка! Работает на любых платформах выше 8.2.16+ и любых конфигурациях! Версия 1.04 от 29.10.2019

12990 руб.

Как сделать Бэкап файловой базы 1С

В файловой базе вся информация хранится в своем закрытом формате — в файле 1CD, который и нужно backup’ить, а лучше всю папку, где он расположен.

Чтобы сделать резервную копию файловой базы 1С вам необходимо в Exiland Backup создать новое задание, нажав соответствующую кнопку на верхней панели, и выполнить некоторые настройки:

введите наименование задания, например, «Бухгалтерские базы 1C»
выберите тип (рекомендуется Full Backup)
укажите исходную папку с БД, например, «\\server\1C\bases»
укажите сжатие ZIP, шифрование AES-256
укажите папку для сохранения резервных копий (рекомендуется сохранять в разные места: на сетевой диск, NAS, FTP-сервер, внешний жесткий диск или даже облако Яндекс.Диск)

Готово! Запустите задание по кнопке «Выполнить». По завершении процесса вы получите резервную копию, из которой сможете восстановить данные в случае их потери или порчи.

Утилита Exiland — главное окно

Если вы хотите, чтобы резервное копирование 1С базы происходило только в тот момент, когда с ней никто не работает, то в настройках задания укажите условие выполнения задания – выполнять только если file *.lck в папке с БД отсутствует. Хотя, версия Professional умеет делать теневые копии заблокированных (открытых) файлов, используя Volume Shadow Copy. Таким образом, Нет необходимости всем закрывать программу бухгалтерии, чтобы создать копию БД.

Тонкая настройка ежедневного резервного копирования базы данных 1С средствами SQL ver. 2014 (SP3) — 12.0.6024.0 (X64)

Хочу вам предложить небольшой пример, как можно реализовать резервное копирование 1С-ых баз данных средствами SQL. Данный материал не претендует на пулитцеровскую премию. Но возможно кому-то будет интересно узнать, что-то новенькое.
Данный материал для резервного копирования только одной базы данных. А именно, если у вас 20-ть баз, то вам придется создавать 20-ть планов обслуживания для каждой базы индивидуально.
(Слава разработчикам SQL, они разрешили копировать блоки из одного плана в другой, вам остается только произвести небольшую настройку для каждого скопированного блока — некоторые настройки блоков сбрасываются и выставляются значением по умолчанию и остаются неактивными)

Просто и сердито. Архивирование (backup) типовых конфигураций 1С 8.2, 8.3

Обновление базы данных с помощью восстановления

При восстановлении резервных копий из предыдущей версии желательно заранее знать, существует ли на целевом компьютере путь (диск и каталог) для каждого полнотекстового каталога резервной копии. Чтобы получить список всех логических и физических имен — пути и имени файла — всех файлов резервной копии, включая файлы каталогов, выполните инструкцию RESTORE FILELISTONLY FROM <устройство_резервного копирования> Дополнительные сведения см. в разделе Инструкция RESTORE FILELISTONLY (Transact-SQL).

Если нужный путь на целевом компьютере не существует, есть два варианта.

Создать нужное сопоставление дисков или структуру каталогов на целевом компьютере.
Переместить файлы каталогов на новое место назначения во время операции восстановления с помощью предложения WITH MOVE инструкции RESTORE DATABASE. Дополнительные сведения см. в разделе RESTORE (Transact-SQL)невозможно.

Дополнительные сведения об альтернативных параметров обновления полнотекстовых индексов см. в разделе Обновление полнотекстового поиска.

Общие сведения о резервных копиях файлов

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

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

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

Примечание

Отдельные файлы могут быть восстановлены из резервной копии базы данных, однако поиск и восстановление файла из резервной копии базы данных займет больше времени, чем из резервной копии файла.

Резервные копии файлов и простая модель восстановления

В простой модели восстановления резервные копии файлов для чтения и записи должны создаваться вместе. Это гарантирует восстановление базы данных до согласованного момента времени. Вместо того чтобы указывать каждый файл или файловую группу для чтения и записи, воспользуйтесь параметром READ_WRITE_FILEGROUPS. Этот параметр создает резервные копии всех файловых групп, доступных для чтения и записи, в базе данных. С помощью параметра READ_WRITE_FILEGROUPS создаются так называемой частичной резервной копией. Дополнительные сведения см. в разделе Частичные резервные копии (SQL Server).

Резервные копии файлов и модель полного восстановления

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

Восстановить базу данных лишь из файла и резервных копий журналов может оказаться сложно. Поэтому лучше выполнить полное резервное копирование базы данных, а затем начать резервное копирование журнала, чем сразу создавать резервную копию файлов. На следующем рисунке показана стратегия, согласно которой создается полная резервная копия базы данных (за время t1) вскоре после создания базы данных (за время t0). Эта первая резервная копия базы данных позволяет начать резервное копирование журнала транзакций. Резервное копирование журнала транзакций запланировано через определенные промежутки времени. Резервные копии файлов создаются через некоторый интервал времени, оптимально соответствующий требованиям предприятия. На данном рисунке показана каждая из четырех файловых групп, резервное копирование которых происходит одновременно. Порядок, в котором оно производится (группы A, C, B, A), отражает требования предприятия к базе данных.

Примечание

При использовании модели полного восстановления необходимо выполнить накат всех журналов транзакций во время восстановления резервной копии файла для записи и чтения, чтобы обеспечить согласованность состояния файла с остальной частью базы данных. Чтобы избежать необходимости наката большого количества резервных копий журналов транзакций, следует чаще создавать разностные резервные копии файлов. Дополнительные сведения см. в разделе Разностные резервные копии (SQL Server).

безопасность

Далее описаны вопросы безопасности и требования к резервному копированию и восстановлению с помощью службы хранилища BLOB-объектов Microsoft Azure.

При создании контейнера для службы хранилища BLOB-объектов Microsoft Azure рекомендуется установить для него закрытые права доступа

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

Важно!
SQL Server требует, чтобы либо имя учетной записи Azure и значение ключа доступа для проверки подлинности, либо подписанный URL-адрес и маркер доступа хранились в учетных данных SQL Server. Эти сведения используются для проверки подлинности учетной записи Azure при резервном копировании или восстановлении.

Предупреждение
Служба хранилища Azure поддерживает отключение авторизации с общим ключом для учетной записи хранения

Если авторизация с общим ключом отключена, операция SQL Server «Резервное копирование по URL-адресу» не будет работать.

Учетная запись пользователя, применяемая для выдачи команды BACKUP или RESTORE, должна находиться в роли базы данных db_backup operator с разрешениями Alter any credential .

Резервные копии заключительного фрагмента журнала с неполными метаданными

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

Если резервная копия заключительного фрагмента журнала содержит неполные метаданные, то параметр has_incomplete_metadata в таблице backupset принимает значение 1. Кроме того, выходной аргумент HasIncompleteMetadataинструкции RESTORE HEADERONLY принимает значение 1.

Если метаданные в резервной копии заключительного фрагмента журнала неполные, то в таблице backupfilegroup большая часть сведений о файловых группах того времени в резервной копии заключительного фрагмента журнала будет утеряна. Большинство столбцов таблицы backupfilegroup содержит значение NULL, другие значения имеют следующие столбцы:

backup_set_id
filegroup_id
type
type_desc
is_readonly

Установка

Для того чтобы скрипт заработал снала необходимов включить «xp_cmdshell» (если по-простому — выполнение команды Windows из скрипта SQL Server из командной строки)

Для этого выполните следующие конструкции:

— << CUT START

USE master;GOEXEC sp_configure ‘show advanced option’, ‘1’;RECONFIGUREEXEC sp_configure ‘xp_cmdshell’,1RECONFIGUREEXEC sp_configure ‘SQL Mail XPs’, 1RECONFIGURE— >> CUT END

Далее создать в MaintancePlan план в котором вставить задачу «Execute T-SQL Statement Task» в него вставляем текст, который во вложении, настраиваем расписание работы плана. Все.

Работа последовательности резервных копий журнала

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

Time	Событие
8:00	Резервное копирование базы данных.
Полдень	Резервное копирование журнала транзакций.
16:00	Резервное копирование журнала транзакций.
18:00	Резервное копирование базы данных.
20:00	Резервное копирование журнала транзакций.

Резервная копия журналов транзакций, созданная в 20:00, содержит записи журнала транзакций с 16:00 до 20:00. В этом временном диапазоне, а именно в 18:00, была создана полная резервная копия базы данных. Последовательность резервных копий журнала транзакций продолжается непрерывно с момента создания начальной полной резервной копии базы данных в 8:00 и до создания последней резервной копии журналов транзакций в 20:00. Сведения о применении этих резервных копий журналов приводятся в примере в статье Применение резервных копий журналов транзакций (SQL Server).

Резервное копирование базы данных

Все что вам нужно для резервного копирования MySQL — это доступ к серверу с операционной системой Linux, на котором установлен сервер баз данных, а также имя базы данных и параметры доступа к ней.

Для экспорта информации из базы данных в формате SQL можно использовать утилиту mysqldump. Вот ее синтаксис:

$ mysqldump опции имя_базы > файл.sql

По умолчанию утилита будет выводить все в стандартный вывод, поэтому нам нужно перенаправить эти данные в файл, что мы и делаем с помощью оператора «>». Опции указывают параметры аутентификации и работы, а имя базы и таблицы — данные которые нужно экспортировать. Теперь рассмотрим кратко опции, которые будем использовать:

-A — копировать все таблицы из всех баз данных;
-i — записывать дополнительную информацию в комментариях;
-c — использовать имена колонок для инструкции INSERT;
-a — включать все возможные опции в инструкцию CREATE TABLE;
-k — отключает первичные ключи на время копирования;
-e — использовать многострочный вариант инструкции INSERT;
-f — продолжить даже после ошибки;
-h — имя хоста, на котором расположен сервер баз данных, по умолчанию localhost;
-n — не писать инструкции для создания базы данных;
-t — не писать инструкции для создания таблиц;
-d — не записывать данные таблиц, а только их структуру;
-p — пароль базы данных;
-P — порт сервера баз данных;
-Q — брать все имена таблиц, баз данных, полей в кавычки;
-X — использовать синтаксис XML вместо SQL;
-u — пользователь, от имени которого нужно подключаться к базе данных.

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

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

Но если во время создания копии возникнут какие-либо ошибки, они будут выведены на экран и вы сразу о них узнаете. Более сложный вариант, это выполнить резервное копирование MySQL с другого хоста, если у вас есть к нему доступ:

Копирование таблицы MySQL может быть выполнено простым добавлением имени таблицы в конец строки:

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

Мы можем делать бэкап вручную время от времени, но это не совсем удобно, поскольку есть другие важные дела. Поэтому используем планировщик cron, чтобы автоматизировать процесс. Тут есть два способа более простой, и более сложный, но точный. Допустим, нам нужно создавать резервную копию каждый день, тогда просто создайте скрипт в папке /etc/cron.daily/ со следующим содержимым:

Папку /backups/mysql-dump.sql нужно заменить на свою папку для резервных копий. Осталось дать скрипту права на выполнение:

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

Добавьте в открывшейся файл такую строку и сохраните изменения:

Команда будет выполняться каждый день, в 2:30, это удобно, поскольку ночью обычно меньше нагрузка на сервер. Как вы поняли, первое число — это минуты, второе — часы, третье день, дальше неделя и месяц. Звездочка значит, что этот параметр не имеет значения.

Как восстановить файл дампа PostgreSQL в базы данных Postgres?

Все админы делятся на 2 категории

— те которые уже делают бэкап

и те которые ещё не делают.

PostgreSQL является современной системой управления базами данных, часто используемая для хранения и обработки информации, связанной с веб-сайтами или сторонними приложениями

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

В этом посте я постараюсь рассказать о некоторых способах, которыми вы можете сделать резервную копию PostgreSQL. Для тестов будем использовать Ubuntu 12,04 VPS с PostgreSQL 9.1. Для большинства современных дистрибутивов и последних версии PostgreSQL мои советы будут актуальны.

Создание резервной копии PostgreSQL при помощи pg_dump

PostgreSQL включает в себя утилиту под названием «pg_dump», которая позволяет сделать дамп базы данных в файл. Утилита консольная, синтаксис достаточно простой:

pg_dump name_of_database > name_of_backup_file

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

Как вариант мы можем войти через sudo под пользователем «рostgres» и выполнить команду:

sudo su — postgres pg_dump postgres > postgres_db.bak

«pg_dump» — это «полноценный» клиент PostgreSQL, т.е. при необходимости её можно запустить с удаленной машины, если имеются соответствующие разрешения к базе данных.

Расширенный синтаксис выглядит следующим образом:

pg_dump -h remote_host -p remote_port name_of_database > name_of_backup_file pg_dump -U user_name -h remote_host -p remote_port name_of_database > name_of_backup_file

Как восстановить дампы pg_dump в PostgreSQL

Чтобы восстановить резервную копию, созданную pg_dump, необходимо перенаправить файл с дампом в стандартный ввод psql:

psql empty_database < backup_file

Эта операция не создает новую базу данных. Об этом необходимо позаботиться заранее.

Для примера, создадим новую базу данных под названием «restored_database», а затем развернем дамп под названием «database.bak»:

createdb -T template0 restored_database psql restored_database < database.bak

Пустая база данных должна быть создана при помощи шаблона «template0«. Так же нам необходимо убедиться в наличии пользователя с необходимыми правами на создаваемую базу, в противном случае нам придется создать нового:

createuser test_user psql restored_database < database.bak

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

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

psql —set ON_ERROR_STOP=on restored_database < backup_file

С данной опцией мы получим частично восстановленную базу данных.

Можно попробовать восстановить весь дамп в одну транзацию, т.е. бекап будет или полностью восстановлен или не восстановлен совсем. Данный режим может быть задан, с помощью опций -1 или —single-transaction для psql.

psql -1 restored_database < backup_file

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

Резервное копирование и восстановление всех баз данных в PostgreSQL

Чтобы сэкономить время, можно сделать резервную копию всех баз данных в вашей системе, при помощи утилиты «pg_dumpall»:

pg_dumpall > backup_file

Похожим способом можно восстановить базы данных:

psql -f backup_file postgres

Резервные копии являются важным аспектом при любой работе с данными

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

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

ls -t *.sql | sed -e ‘1,13d’ | xargs -d ‘\n’ rm echo Done at `date +\%Y-\%m-\%d_\%T` pg_dump dbname —username=dbuser > `date +\%Y-\%m-\%d_\%T`.sql

Вы можете оставить комментарий ниже.

Перед восстановлением файлов базы данных

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

Также при восстановлении базы данных, если это необходимо, можно указать сопоставление дисков, имена файлов или путь для восстановления.

Это может быть необходимо в следующих ситуациях.

Нужная структура каталогов или сопоставление дисков, используемые на исходном компьютере, могут отсутствовать на другом компьютере. Например, возможно, резервная копия содержит файл, который нужно восстановить на диск E, но на целевом компьютере диска E — нет.
на целевом диске может быть недостаточно свободного места;
Если используется имя базы данных, которое уже существует на целевом сервере восстановления, а имя каждого из ее файлов совпадает с именем файла базы данных в резервном наборе данных, происходит одно из следующих действий.
- Если существующий файл базы данных может быть перезаписан, он будет перезаписан (это не затронет файл, относящийся к базе данных с другим именем).
- Если существующий файл не может быть перезаписан, возникнет ошибка восстановления.

Во избежание ошибок и непредвиденных последствий перед операцией восстановления можно использовать таблицы журнала backupfile , чтобы найти в резервной копии файлы базы данных и журнала, которые планируется восстановить.

Почему важно автоматически выполнять резервное копирование 1С?

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

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

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

Для решения этой задачи рассмотрим специальную утилиту Exiland Backup Professional для Windows. Это мощный инструмент бэкапа, при этом простой в настройке. Он эффективно использует память ПК, создает резервные копии быстро в параллельных потоках, имеет интуитивно-понятный русскоязычный интерфейс и хорошую техническую поддержку от разработчика.

Посмотрим на примерах, как настроить бэкап 1С. База данных, как известно, может быть:

файловой в виде файла 1cd
в формате Microsoft SQL Server или PostgreSQL

Рассмотрим подробнее оба варианта.

Итак, для начала в любом случае скачайте демо-версию Professional.Ее работу рассмотрим ниже.

Скачать

Пробный период демо версии составляет 30 дней и нет возможности запуска по расписанию (только по кнопке в программе). Для пробы этого вполне достаточно.

Установите и запустите программу.