1с как сделать копию sql базы 1с

Обновлено: 12.07.2024

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

Перед тем, как начать это, требуется убедиться что выполнили следующие предварительные условия:

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

Разрешения

Если восстанавливаемая база данных не существует, пользователь должен иметь разрешения create database , чтобы иметь возможность выполнить восстановление. Если база данных существует, разрешение выполнения по умолчанию назначаются членам sysadmin и dbcreator фиксированным ролям сервера и владельцу базы данных (dbo).

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

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

Чтобы восстановить базу данных, выполните следующие действия:

  1. После подключения к соответствующему экземпляру СУБД MS SQL требуется щелкнуть имя сервера, чтобы развернуть дерево серверов в обозревателе объектов.
  2. Разверните Базы данных. В зависимости от базы данных, выберите пользовательскую базу данных или разверните Системные базы данных и выберите системную базу данных.
  3. Щелкните ПКМ базу данных, выберите «Задачи» > «Восстановить» > «База данных», чтобы открыть диалоговое окно «Восстановить базу данных».
  4. В разделе «Источник» страницы «Общие» укажите источник и расположение наборов резервных копий для восстановления, выбрав «Устройство» > «Добавить», а затем найдите файл резервной копии:

Путь к файлу резервной копии

Рисунок 1 - Путь к файлу резервной копии

  1. В разделе «Назначение» страницы «Общие» поле «База данных» автоматически заполняется именем базы данных, введите новое имя в этом поле.
  2. В разделе «План восстановления» на странице «Общие» оставьте значение по умолчанию «До последней сохраненной резервной копии» или нажмите «Временная шкала», чтобы открыть диалоговое окно «Временная шкала резервного копирования», где вы можете вручную выбрать момент времени, чтобы остановить действие восстановления.
  3. В разделе Резервные копии для восстановления сетки выберите резервные копии для восстановления. Эта сетка отображает резервные копии, доступные для указанного местоположения. По умолчанию предлагается план восстановления.
  4. Чтобы просмотреть или выбрать дополнительные параметры, на панели «Параметры восстановления» на странице «Параметры» можно выбрать любой из следующих параметров, если это соответствует вашей ситуации:

Окно об успешном завершении

Рисунок 2 - Окно об успешном завершении

С опциями (не обязательно):

  • Перезаписать существующую базу данных ( with replace )
  • Сохранить настройки репликации ( with keep_replication )
  • Ограничить доступ к восстанавливаемой базе данных ( with restricted_user )

Выберите опцию для поля Состояние восстановления, которое определяет состояние базы данных после операции восстановления:

  • restore with recovery - это поведение по умолчанию, которое оставляет базу данных готовой к использованию, откатывая незавершенные транзакции
    • Дополнительные журналы транзакций не могут быть восстановлены
    • Выберите эту опцию, если вы сейчас восстанавливаете все необходимые резервные копии
    • Дополнительные журналы транзакций могут быть восстановлены
    • База данных не может быть использована, пока она не будет восстановлена
    • Он отменяет незавершенные транзакции, но сохраняет действия отмены в резервном файле, чтобы можно было восстановить эффекты восстановления

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

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

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

    Нажимаем ОК, после этого выполнится восстановление базы данных и увидим информационное окно об успешном завершении.

    В данной статье используется MS SQL Server 2008 R 2 под Windows.

    Хочу сразу сказать, что статья посвящена настройке самого бюджетного варианта размещения 1С для среднестатистической фирмы с не более чем 10-ю рабочими местами, использующей только Бухгалерию Предприятия и ЗУП. Подойдет ли это для торгового предприятия – не проверял.

    Можно разместить 1С сервер на PostgreSQL и Linux . Это будет дешевле за счет меньшей стоимости лицензий 1С и «бесплатности» SQL -ной части. Но так ли это на самом деле? Для обслуживания серверной части необходим специалист в штате или постановка на обслуживание в одной из фирм-франчайзи 1С. Совсем не бюджетный вариант.

    Обычно в каждой малой или средней фирме всегда есть хотя бы один системный администратор, он же «железячник», хорошо разбирающейся в «окнах». Всегда есть Windows сервер и можно выделить место или машину для 1С. Почему бы не использовать MS SQL Server? Он очень хорошо дружит с Windows. Кто бы спорил. Дорого. Так ли это?

    В линейке SQL Server у Microsoft существует выпуск под названием « Express ». Это и есть наш бюджетный вариант. Microsoft о нем говорит следующее: « Бесплатная база данных начального уровня, которая идеально подходит для обучения и создания приложений для обработки данных на настольных компьютерах и небольших серверах (размером до 10 ГБ) ». На 4 ядра процессора, буфер 1410 Мб, объем памяти на базу 352 Мб, максимальный размер базы 10 Гб. А для нашей фирмы надо больше? Нет.

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

    1.Особенности резервирования MS SQL Server Express.

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

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

    2.Стратегия резервирования.

    Для нашего случая (малая или средняя не торговая фирма) стратегия будет такая:

    - полная резервная копия 1 раз в день. Этого достаточно. Лучше делать во внерабочее время – ночью или утром.

    - несколько разностных копий в рабочее время с периодичностью 1 – 3 часа. Разностные копии сохраняют только изменения внесенные в 1С после создания полной резервной копии. Поэтому они существенно меньше и их создание занимает меньше времени. Если нужно откатиться на несколько времени – делаем восстановление из полного и накатываем разностный по ближайшему времени до возникновения ошибки. От этого времени до момента ошибки – руками в 1С. А что делать? Бюджетная модель. На практике восстанавливать приходится очень редко и периодичность разностных копий в 3 часа вполне достаточна.

    - сохранение всех резервных копий не только на основной носитель, но и на резервный файловый сервер. Обычно на сервере, где крутится 1С, не так много свободного места. Поэтому время удержания (количество хранящихся резервных копий по дням) может быть невелико. Увеличить время удержания и обезопасить себя от сбоев основного сервера можно выделив место на стороннем файловом сервере и передавать туда копии бэкапов после их создания на основном сервере.

    Будем использовать штатные возможности SQL Server и Windows. Подойдем к решению задачи комплексно. Максимум начальной работы и минимум на поддержание, проверки и прописывание новых без данных.

    3. Как это сделать. Часть на SQL Server.

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

    CREATE TABLE [dbo].[adm_reserved_db_names](

    [id] [int] IDENTITY(1,1) NOT NULL,

    [name_rsrv_db] [varchar](50) NOT NULL,

    [flag_rsrv] [int] NOT NULL,

    [flag_diff] [int] NOT NULL

    Id – номер по порядку, далее имя базы данных (совпадает с Database Name), флаг создания полной резервной копии и флаг создания разностной резервной копии. Флаги – целые числа. Удобно ставить и менять. 0 – делать, 1 – не делать. Понятно, что если не делаем полную копию, то разностная пойдет от последней сделанной полной или выдаст ошибку.

    В результате заполненная рабочая таблица adm _ reserved _ db _ names будет выгляеть так:


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

    Полное резервирование adm _ BackUp _ Bases :

    CREATE PROCEDURE [dbo] . [adm_BackUp_Bases]

    declare @pathbkp varchar ( 100 )

    declare @extbcp varchar ( 5 )

    declare @dltfromdate varchar ( 19 )

    declare @file varchar ( 200 )

    declare @filename varchar ( 50 ), @logfile varchar ( 50 )

    declare @dt varchar ( 15 )

    declare @rdnc int

    declare CurDBName cursor for

    select name_rsrv_db from master . dbo . adm_reserved_db_names

    where flag_rsrv = 0 order by 1 ;

    set @pathbkp = 'C:\SQL_Data\BackUp\'

    set @extbcp = 'bak'

    select @dltfromdate = convert ( varchar ( 19 ), dateadd ( DAY ,- @rdnc , getdate ()), 126 ); --'2011-11-23T11:14:48'

    select @dt = cast ( datepart ( yyyy , getdate ()) as varchar ( 4 ))

    when len ( cast ( datepart ( mm , getdate ()) as varchar ( 2 )))= 1

    then '0' + cast ( datepart ( mm , getdate ()) as varchar ( 2 ))

    else cast ( datepart ( mm , getdate ()) as varchar ( 2 ))

    when len ( cast ( datepart ( dd , getdate ()) as varchar ( 2 )))= 1

    then '0' + cast ( datepart ( dd , getdate ()) as varchar ( 2 ))

    else cast ( datepart ( dd , getdate ()) as varchar ( 2 ))

    when len ( cast ( datepart ( hh , getdate ()) as varchar ( 2 )))= 1

    then '0' + cast ( datepart ( hh , getdate ()) as varchar ( 2 ))

    else cast ( datepart ( hh , getdate ()) as varchar ( 2 ))

    when len ( cast ( datepart ( mi , getdate ()) as varchar ( 2 )))= 1

    then '0' + cast ( datepart ( mi , getdate ()) as varchar ( 2 ))

    else cast ( datepart ( mi , getdate ()) as varchar ( 2 ))

    fetch next from CurDBName into @filename ;

    while @@FETCH_STATUS = 0

    select @file = @pathbkp + @filename + '_backup_' + @dt + '.' + @extbcp ;

    BACKUP DATABASE @filename TO DISK = @file WITH NOFORMAT , NOINIT ;

    EXECUTE master . dbo . xp_delete_file 0 , @pathbkp , @extbcp , @dltfromdate

    fetch next from CurDBName into @filename ;

    Определяем курсор CurDBName для перебора таблицы, переменной @ pathbkp определяем путь хранения резервных копий, @ extbcp - расширение резервного файла, @ dt - дата-идентификатор файла, @ rdnc - удержание в сутках. Запускаем курсор, считываем имя базы данных, формируем имя резервного файла, делаем backup средствами T-SQL и удаляем устаревшие резервные файлы. И так – до конца таблицы. Получаем файлы с такой нотацией:

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

    Разностное резервирование adm_BackUp_Bases_Diff:

    CREATE PROCEDURE [dbo] . [adm_BackUp_Bases_Diff]

    declare @pathbkp varchar ( 100 )

    declare @extbcp varchar ( 5 )

    declare @dltfromdate varchar ( 19 )

    declare @file varchar ( 200 )

    declare @filename varchar ( 50 ), @logfile varchar ( 50 )

    declare @dt varchar ( 15 )

    declare @rdnc int

    declare CurDBName cursor for

    select name_rsrv_db from master . dbo . adm_reserved_db_names

    where flag_diff = 0 order by 1 ;

    set @pathbkp = 'C:\SQL_Data\BackUp\'

    set @extbcp = 'bak'

    fetch next from CurDBName into @filename ;

    while @@FETCH_STATUS = 0

    select @file = @pathbkp + 'DFF_' + @filename + '.' + @extbcp ;

    BACKUP DATABASE @filename TO DISK = @file WITH DIFFERENTIAL , NOFORMAT , NOINIT ;

    fetch next from CurDBName into @filename ;

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

    DFF _ XX _ ACC . bak

    Все разностные копии SQL сервером кладутся в один файл и он, с течением времени, увеличивает свой размер.


    4. Как это сделать. Часть на Windows.

    В примере использован Windows Server 2008 R2 Standard.

    Так как в MS SQL Server Express отсутствует SQL Agent, то никакое задание на стороне SQL сервера мы выполнить не можем. Но можно управлять им из командной строки операционной системы.

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


    Полное резервирование sql-инструкция BackUp_DB.sql:

    Здесь дается команда выполнить процедуру на SQL сервере в системной базе данных Master.

    Полное резервирование командный файл BackUp1C.cmd:

    sqlcmd -S ServerName\Instance -U User -P Passvord -i C:\ BackUp_Tools\BackUp_DB.sql

    del \\ ServerName \BackUp\DFF_*.bak

    robocopy "\\ServerName\BackUp" "\\DisasterServerName\BackUp" *.bak /R:0 /MAXAGE:1

    Sqlcmd - служебная программа, которая позволяет вводить инструкции T-SQL, системные процедуры и файлы скриптов в командной строке. Она предустанавливается с MS SQL сервером или ее можно скачать с сайта Microsoft. ServerName – имя сервера где размещена 1С, Instance – имя экземпляра MS SQL Server где крутится 1С, User и Passvord – имя и пароль пользователя с правами администратора (sa). Пароль в открытом доступе очень плохо. Но в нашем бюджетном варианте от этого никуда не денешься. Лучше всего создать в MS SQL Server специального пользователя только для создания backup-ов и хорошо защитить операционную систему от проникновения извне.

    Как я говорил выше, после создания полной резервной копии файлы разностных backup-ов теряют смысл, поэтому их удаляем.

    DisasterServerName – имя резервного файлового сервера, где размещается архив полных резервных копий. Копируем их после удаления всего лишнего утилитой robocopy. Для нашего случая она подходит идеально. Задаем пути откуда брать и куда класть, шаблон имен файлов и время удержания. В нашем примере MAXAGE:1 – это файлы с текущей датой. Robocopy качаем из интернета и устанавливаем.

    Разностное резервирование sql-инструкция BackUp_DB_Diff.sql:

    Разностное резервирование командный файл BackUp1C_Diff.cmd:

    sqlcmd -S ServerName\Instance -U User -P Passvord -i C:\ BackUp_Tools\BackUp_DB_Diff.sql

    robocopy "\\ServerName\BackUp" "\\DisasterServerName\BackUp" DFF_*.bak /R:0 /MAXAGE:1

    Дальше надо настроить выполнение заданий в операционной системе. Используем Task Sheduler. Для разностного резервирования можно использовать такой вариант периодичности:


    Через каждые 3 часа начиная с 8 утра до 8 вечера.

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

    Восстановление базы после ошибок по просьбе бухгалтерии производится стандартными средствамиSQL Server. В SQL Server Management Studio подключаемся к экземпляру 1С, выбираем нужную базу данных, левой кнопкой мыши открываем меню, находим раздел Задания (Tasks), выбираем, находим раздел Восстановление (Restore), выбираем и в открывшемся меню выбираем пункт База данных (Database…). Появится такое окно:


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

    6. Небольшой лайфхак для администратора.

    В жизни 1С администратора и программиста возникают моменты, когда надо сделать свежий файловый архив базы данных. Например развернуть тестовую базу у себя на компьютере. Это всегда сопряжено с трудностями: либо выгонять всех пользователей, либо ждать когда они же разойдутся по домам. В случае базы данных на SQL сервере это сделать несколько проще.

    Создаем на 1С сервере пустую тестовую базу данных. Переходим в SQL Server Management Studio.Аналогично как в п.п. 5 откроем окно восстановления нашей тестовой базы данных.


    Будем использовать архив нужной Вам базы. Для этого выбираем ее из списка в разделе From database. Переходим в раздел задания параметров Options.


    Ставим галочку перезаписывания тестовой базы данных (2), проверяем выбор статуса восстановления (3). Нажатием кнопок (4 и 5) заменяем наименование файла базы-иметента данных (файл *.mdf) на наименование Вашей тестовой базы данных из списка (4) и заменяем наименование файла журнала событий базы-иметента данных (файл *.ldf) на наименование журнала событий Вашей тестовой базы данных из списка (5). Нажимаем ОК и ждем. После завершения работы открываем тестовую базу 1С в режиме конфигуратора и, никому не мешая, делаем файловую копию.

    В этой статье я хочу поделиться опытом резервного копирования файловых и SQL баз 1С в локальное, сетевое и облачное (на примере Google Drive) хранилище с помощью Effector Saver.

    ПО является платным: 2500₽.
    Переход на новую версию (с 3 на 4) также является платным: 1250₽.

    Писал инструкцию для друга, но думаю она пригодиться и кому-то из вас.

    И как всегда, в комментариях, вы научите меня чему-то новому =)

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

    Цель:
    Автоматическое создание шифрованных бэкапов по расписанию с отчётом об ошибках на почту.

    Логика бэкапов:

    • Ежедневно последние 30 шт (срок хранения 1 месяц)
    • Ежемесячно 1 числа последние 24 шт (срок хранения 2 года)
    • Ежегодно 1 февраля последние 10 шт (срок хранения 10 лет)
    • Бэкапы выгружаются в хранилище бэкапов (локальное или сетевое) из под учётки backup
    • Бэкапы выгружаются в облако Goole Drive (возможно с собственным OAuth ID Client/Secret)
    • Отправка отчета об ошибках на электронную почту
    • Данная инструкция приводится как готовый пример использования, который можно и нужно адаптировать под свои задачи.
    • Задания могут запускаться в одно время, т.к. поддерживается параллельное выполнение заданий, что ощутимо сокращает время для бэкапов.
    • Дополнительное копирование выполняется на основе задачи, т.е. выполняется копирование последнего уже созданного бэкапа. Например, если дополнительное копирование должно быть выполнено 10 числа, а бэкап выбранной задачи от 10 числа завершился с ошибкой (а мы не стали вмешиваться), то дополнительное копирование сделает копию для последнего успешного бэкапа выбранной задачи, в нашем примере будет от 9 числа.
    • В программе можно настроить выгрузку баз средствами 1С в виде .dt файлов, с автоматической блокировкой/разблокировкой базы и выкидыванием пользователей. В данной инструкции такой способ не рассматривается, как ненадежный способ резервного копирования формата .dt.

      Автозагрузка
      Запускать как служба Windows (сервер)
      пользователь backup, пароль свой

    Пояснения по пользователю backup, для чего отдельная учетка
    Для бэкапов считаю важным создавать и использовать отдельную учетную запись, например backup. Это может быть как локальная так и доменовская учетка.
    Доступ к хранилищу бэкапов для админов должен быть настроен для чтения, и только у учетки backup на запись. Это позволит защитить ваши бэкапы от многих опасностей (дурная голова, вирусы). А если вам понадобится внести какие-то изменения в хранилище бэкапов, то всегда можно дать себе временны доступ, или запустить любой проводник (например Total Commander) от имени учетки backup для полного доступа к хранилищу.

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

    1. для backup на запись
    2. для учетки из под которой работает служба MS SQL Server на запись
    3. админам на чтение

    Чтобы обойти это ограничение, мы выбираем сетевой путь для временной папки. Тогда SQL сервер будет получать сетевой путь и будет выгружать бэкап по этому адресу.

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

    Тут вносить изменения не обязательно, но как всегда есть небольшое НО Если вы это настраиваете удаленно на сервере или чужом компьютере
    То можно выполнить авторизацию альтернативным способом. Закрываем окно ввода логина и пароля — появится ошибка авторизации — жмем кнопку Пользовательский режим, далее жмем по ссылке Получить код подтверждения ссылка авторизации откроется в браузере. Ссылку копируем к себе на компьютер, авторизуемся у себя на компьютере, подтверждаем права доступа, получаем ключ, копируем его обратно в поле окна Авторизация приложения в пользовательском режиме, жмем ОК

    Выбираем путь к папке в облаке, аналогично:
    Backup/EveryDay

    • Основные параметры
      Включить в архив бэкап базы SQL (на примере Microsoft SQL Server)
    • База Microsoft SQL
      Прописываем все реквизиты.
      Проверяем, что на MS SQL сервере открыт TCP 1433 порт.
      Жмем: Проверить
    • Хранилище архивов
      — Добавляем хранилище \\NAS\Backup\EveryDay
      Автоматически удалять устаревшие резервные копии: 30
      — Добавляем хранилище EveryDay (Google Диск)
      Автоматически удалять устаревшие резервные копии: 30
    • Файл архива
      Имя файла архива: название базы
      Окончание имени архива: yyyy.mm.dd_hh.nn.ss
      Архивирование
      Формат: 7z
      Сжатие: без сжатия

    При резервном копировании SQL базы стоит рассмотреть 2 варианта

    1. Сжатие базы средствами SQL сервера. — Быстрый, но сжимает хуже чем 7z.
    Если выбрали этот вариант, то нужно:
    — Выбрать: без сжатия (т.к. сжимать уже сжатый .bak файл без толку)
    — В свойствах MS SQL сервера включить: Параметры базы данных > Сжимать резервные копии.

    2. Сжатие базы средствами 7z — Медленный, но сжимает лучше чем SQL.
    Если выбрали этот вариант, то нужно:
    — Выбрать: максимальное сжатие
    — В свойствах MS SQL сервера отключить: Параметры базы данных > Сжимать резервные копии.

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

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

    • Основные параметры
      Задача резервного копирования — источник: выбираем нужную задачу
      Хранилище… источник: выбираем хранилище \\NAS\Backup\EveryDay
    • Хранилище архивов
      — Добавляем хранилище \\NAS\Backup\EveryMonth
      Автоматически удалять устаревшие резервные копии: 24
      — Добавляем хранилище EveryMonth (Google Диск)
      Автоматически удалять устаревшие резервные копии: 24
    • Файл архива
      Имя файла архива: название базы
      Окончание имени архива: yyyy.mm.dd_hh.nn.ss
      Архивирование
      Формат: 7z
      Сжатие: без сжатия
      Шифровать архивы
      Шифровать имена файлов
      Устанавливаем пароль (запишите его, если забудете, то бэкапы будет не восстановить)
    • Расписание автозапуска:
      Запускать по расписанию: включить
      Ежемесячно. Все месяцы 1 числа.
      05:00
    • Прервать выполнение задачи через: включить
      2 час. 0 мин.
    • Хранилище архивов
      — Добавляем хранилище \\NAS\Backup\EveryYear
      Автоматически удалять устаревшие резервные копии: 12
      — Добавляем хранилище EveryYear(Google Диск)
      Автоматически удалять устаревшие резервные копии: 12
    • Расписание автозапуска:
      Запускать по расписанию: включить
      Ежемесячно. Февраль 1 числа (год закрыт)
      05:00
    • Основные параметры
      Количество дней. : 1
    • Выбираем все задачи, у всех выбираем фильтр записей: Записи журнала с ошибками
    • Параметры почты
      Заполняем реквизиты почты. Куда и с какой темой отправлять отчеты.
    • Расписание автозапуска:
      Запускать по расписанию: включить
      Ежедневно
      07:00

    Пример журнала резервного копирования MS SQL базы весом 52Гб (mdf):
    ===========================================
    Задача: Base1
    Вид задачи: Резервное копирование файлов и баз данных
    Компьютер: SRVTS0
    Версия: 4.5 / 2
    Запуск: По расписанию, как служба
    Начало: 11.11.2019 4:01:08
    Конец: 11.11.2019 5:13:57
    Статус: Успешное выполнение задачи
    ===========================================
    11.11.2019 4:01:08 - Резервное копирование MSSQL базы "Base1" .
    11.11.2019 4:01:08 - SQL Server version 11
    11.11.2019 4:22:15 - Выполнено
    11.11.2019 4:22:15 - Резервное копирование файлов .
    11.11.2019 4:22:15 - формат 7z, без сжатия, c шифрованием заголовка
    11.11.2019 4:26:50 - 1 файлов добавлено, 0 файлов пропущено
    11.11.2019 4:26:50 - Выполнено
    11.11.2019 4:26:52 - Загрузка бэкапа 5,41 GB в хранилище "EveryDay (Google Диск)" .
    11.11.2019 4:26:54 - Загрузка "Base1_2019.11.11_04.26.52.7z" 5,41 GB (1 из 1)
    11.11.2019 5:13:57 - Загрузка удачно завершена
    11.11.2019 4:26:52 - Загрузка бэкапа 5,41 GB в хранилище "\\NAS\Backup\EveryDay" .
    11.11.2019 4:26:52 - Загрузка "Base1_2019.11.11_04.26.52.7z" 5,41 GB (1 из 1)
    11.11.2019 4:28:13 - Загрузка удачно завершена

    Из журнала видно, что загрузка в хранилище и в облако началась одновременно.
    Бэкап в хранилище был завершен через 27 минут. А в облако был выгружен через 1 час 12 минут от старта задачи.
    При условии, что параллельно в это же время выполнялось еще 4 задачи резервного копирования баз, размер которых 38Гб, 28Гб, 6Гб и 5Гб (mdf).
    Все задачи были одновременно запущены в 4:00 и успешно завершены до 5:15:00.

    Есть конечно и небольшие недоработки, кроме тех, что уже описал в статье:

    • отсутствие возможности экспорта и импорта настроек и задач в виде текстового файла (именно текстового, а не mdb и т.п., чтобы можно было легко открыть и отредактировать)
    • нет визуального сохранения настроек OAuth, всегда пусто и не понятно настроено или нет.
    • нет возможности быстро включить/выключать задания (нужно открывать каждое и заходить в расписание). Хотя в главном окне интуитивно так и просится двойной клик по галочке.

    Но в целом результат меня очень порадовал. Считаю программу очень полезной.

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

    Бэкап 1С

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

    Странствие первое. Effector Saver

    В любом путешествии есть места, миновать которые невозможно. Например, индийский обезьяний полководец Хануман, летевший из Индии на Ланку, не смог миновать пасти водяной змеи Сурасы; голуби, носившие Зевсу амброзию мимо пограничников, регулярно разбивались о камни Симплегад. Вы сами, попав в Париж, обязательно пойдёте глазеть на Эйфелеву башню. И, разумеется, ни один искатель утилит бэкапа для 1С не сможет миновать контакта с Effector Saver, бесплатной программы для сохранения данных 1С! Ну, вот и я – тоже вляпался!
    Нет, я ругаться не буду. Effector Saver – программа очень неплохая. Есть бесплатная версия, есть бэкап SQL-контента 1С наряду с файлами, есть и много других приятных «плюшек», здорово облегчающих сисадмину или эникейщику жизнь.
    Особенно радуют такие плюсы, как возможность запуска программы в качестве службы Windows, чтобы не отвлекать внимание пользователя лишними действиями, и автоматическое отключение активных пользователей 1С на время бэкапа. Интерфейс весьма логичен, лёгок в освоении и не даёт оснований задумываться над каждым действием.
    Сложности начались при переходе от теории к практике. Я – стреляный воробей и тёртый калач, поэтому, прежде чем доверять судьбу родного предприятия стороннему коммерческому продукту, я прежде всего проверил отзывы пользователей. А они, мягко говоря, противоречивы. И пусть соотношение дёгтя к мёду вполне традиционное – бочка к ложке, — но реакция разработчика программы на обнаруженный дёготь, мягко говоря, далека от совершенства. Иначе говоря, он конфликтен. Он справедливо упирает на то, что сделал очень хорошую (и это так!) бесплатную программу, и что за мелкие проблемы этой программы ругать его совершенно не следует. Но проблема-то не в ругани! 1С – это не файл записи к игрушке под DOS, это штука, под управлением которой внезапно могут крутиться многие миллионы. И никому не захочется терять эти миллионы из-за того, что разработчик (повторюсь, проделавший огромный труд!) не стал прислушиваться к паре-тройке неожиданно возникших мелких замечаний.
    Повторюсь: не хочу быть несправедливым. Effector Saver показался мне прекрасной программой. Но там, где дело идёт о деньгах, одной красоты недостаточно. И я вынужден был расстаться, скрепя сердце, с чудесной страной Effector Saver и пуститься в следующее своё странствие.

    Странствие второе. Handy Backup

    Этот продукт изначально пленил меня сочетанием несколько старомодного внешнего исполнения с весьма современным наполнением. По виду он архаичен, как Windows 98, а по функциональности надёжен, как автомат Калашникова. Под замшелым интерфейсом скрывается, как в волшебном гроте, прекрасный набор самых актуальных функций для бэкапа, восстановления и синхронизации данных. Здесь тебе и запись бэкапов на какое угодно коммерческое облако, хоть Dropbox, хоть Amazon S3, хоть OneDrive (не говоря уж о более приземлённых носителях, вроде FTP или USB-диска), здесь и работа со всеми видами баз данных, и хранение нескольких версий под временными метками… Руководство пользователя Handy Backup, сулившее неисчислимые возможности, пленило меня, как нимфа Калипсо пленила некогда застигнутого бурей Одиссея. Там было описано в подробностях всё, вообще всё, что только можно делать с бэкапами! Это было весьма захватывающее чтение…
    Я немедленно помчался на официальный сайт Handy Backup и скачал пробную версию на тридцать дней, чтобы убедиться, как рекламные посулы в очередной раз затуманили мне вид на неприглядную истину. Я разочаровался! Нет, не в том смысле: я разочаровался в своих ожидаемых разочарованиях. Handy Backup и в самом деле делает всё, что обещает! В отчаянии, я связался со службой технической поддержки продукта («предоставляемой в течение всего срока жизни лицензии», как написано на сайте) – и внезапно получил грамотную, серьёзную техническую консультацию. Эта функция тоже работает, как и все остальные! Более того, за время моего тестирования Handy Backup вышли два обновления, каждое из которых содержало не затычки и заглушки к предыдущим ошибкам, а новые полезные функции.
    Почему же я покинул этот рай земной и отправился дальше, в новые странствия по негостеприимным берегам чужих программных продуктов? Ответ прост: деньги. Handy Backup – платная программа, а душа, как известно, просит программ бесплатных. А у Handy Backup бесплатная только версия, позволяющая сохранять копии чего угодно (да, и 1С тоже!) исключительно на Яндекс.Диск. За всё остальное надлежит выложить денежки, в количестве, зависящем от требуемого набора функций автоматического бэкапа. И если файловую версию 1С Handy Backup способен распознавать и сохранять во всех комплектациях, начиная с базовой Standard примерно за сорок долларов, то за хранение резервных копий СУБД на основе SQL придётся существенно доплатить.
    Послав руководству подробный отчёт о прелестях Handy Backup (в надежде, что внезапно всё-таки дадут денег!), я тем временем собрал свой скудный багаж и двинулся в новый путь.

    Странствие третье. «Хранитель V»

    Мой путь привёл меня на пустынный, необитаемый остров с полной романтического очарования вывеской «Хранитель V». Разработчик этого волшебного дива — под стать названию, это ГЭНДАЛЬФ. Так, и именно так, называется компания, создавшая волшебный продукт.
    На сайте компании о функциональных возможностях «Хранителя» удалось узнать довольно мало. Гораздо больше внимания уделялось рекламным слоганам и баннерам, шелестевшим повсюду, как дикий лес. Не слишком-то прояснила ситуацию и короткая экспедиция на окрестные форумы; таинственный «Хранитель» от ГЭНДАЛЬФа оставался для меня по-прежнему загадочен и неясен. Быть может, в былые времена этот край было полон жизни и движения, а множество ликующих пользователей делали бэкапы 1С с утра до вечера, не желая и думать о лучшей судьбе; ныне же «Хранитель» выглядит бесприютным, и, судя по сайту, в последний раз нога сисадмина ступала куда-то туда ещё в 2011 году.
    Признаюсь: я внезапно испугался. Мне стало страшно бродить среди слоганов и рекламных призывов «Хранителя»; я не посмел тревожить девственный покой этого места попытками скачивания программы или какого-нибудь другого нарушения тишины. Я боялся, что останусь в этой программе единственным пользователем и буду вынужден много лет вести робинзонаду, сражаясь за выживание в одиночку. Ак знать: быть может, в чащобе притаился уже страшный и неодолимый баг, который только и ждёт, чтобы пожрать все мои данные! И я, разочарованный, покинул этот волшебный, но совершенно опустевший край, чтобы продолжить свой путь в море Интернета.
    Неподалёку от «Хранителя» ГЭНДАЛЬФа обнаружился ещё один островок, бесхитростно обозначенный на картах «1Сbackup». Обследование показало, что этот продукт затонул совершенно, и лишь отдельные буруны на замшелых форумах указывают случайному страннику на его прошлое существование.

    Странствие четвёртое. «Бэкапер-1С»

    Наконец-то судьба вновь занесла меня в цивилизованное место! «Бэкапер-1С», написанный, как мне удалось понять, программистом Алексеем Кармановым, не только живёт, но и время от времени обновляется (последняя версия вышла где-то в середине 2013 года). Эта программа проста, бесплатна и обладает хорошим понятным интерфейсом. К тому же, разработчик очень дружелюбен, хорошо объясняет не только выгоды и преимущества своей программы, но и технику работы с ней, а также, по всей видимости, быстро и адекватно реагирует на замечания пользователей. После контакта с «Бэкапером» короткий опыт общения с Effector Saver кажется годом, проведённым в пещере циклопа Полифема.
    «Бэкапер-1С» предназначен для «простых» пользователей 1С и, как следствие, лишён некоторых важных особенностей функционала. В частности, мне не удалось запустить его как службу Windows. Кроме того, для архивирования данных он использует встроенную программу 7-Zip, что бывает весьма удобно для пользователей, но иногда вызывает самые неожиданные проблемы, например, с корпоративной политикой безопасности. И всё же это решение заняло в моём личном рейтинге место рядом с Handy Backup; к нему мне не раз захотелось вернуться.

    Странствие пятое: «1СкриптМенеджер для MS SQL»

    В этом месте меня начали мучить сомнения: туда ли я попал? Ведь мне нужно сохранять резервные копии и для файловой версии, и для самых разных СУБД! Но, кроме упоминания MS SQL в заголовке, я не нашёл с ходу никаких других вариантов работы с «1СкриптМенеджер». Ужаснула и цена: что-то около пяти с половиной тысяч рублей за продукт с, мягко говоря, ограниченной функциональностью!
    Я хотел было уже развернуться и закончить странствие, но меня привлекли неожиданно хорошие отзывы о продукте. Системные администраторы – народ суровый, они без нужды не похвалят ни Стива Джобса, ни Стива Балмера, ни даже, о ужас, Питера Нортона – а тут вдруг собрались на форумах и поют настоящие дифирамбы! Иначе говоря, если бэкап 1С с базой на MS SQL – это именно то, что нужно лично вам, то этот вариант, по всей видимости, вполне можно и нужно рассматривать. Мне же настоятельно необходим был бэкап именно для файловой версии. Поэтому я расстроился и уехал с этого ресурса.

    Читайте также: