1с как сделать копию sql базы 1с
Коллеги! Есть такая проблема: довольно большая (1.5 террабайта) рабочая база, есть бакап (конечно), надо быстро развернуть 3 тесовых базы для 3-х разработчиков. Как это сделать наиболее быстро? Ну первую базу поднимаем из бакапа, а вот как быстро клонировать еще 2?
А точно всем разработчикам нужны полные копии рабочей базы? Может достаточно им пустые базы с нужной конфижкой сделать?
(3) Ага, чтобы у разработчиков на тестовых данных работало, а на реальных - нет. Нужна не пустая база, а с реальными настройками и данными. Тут 2 варианта: копия рабочей базы, либо специально обученный человек делает тестовую базу по образу и подобию реальной, только с меньшим количеством данных (т.е. вводит тестовые примеры).
Как минимум после восстановления бэкапа выпилить из копии базы ненужные данные (например, сохраненные файлы, если они в базе лежат, может какие-то регистры, с которыми точно не будет работы)
(0) А что разработчикам нужны все данные в вашей базе ? Оставьте то что кому что нужно, остальное выпилить.
(1) Вот я не понял как это - в одной базе с помощью хранилища? Думал что много знаю про 1С, а тут прошу пояснить.
3 конфигуратора над одной базой не запустишь. Или ты имеешь ввиду над разными базами? Так нам нужны свежие данные.
Давайте лучше обсудим есть ли способ быстрого клонирования. Может средствами SQL как то?
(8) Вопрос в том, что будет дешевле - выпилить, или каждому разработчику полную копию организовать. и не забыть, что ее надо будет обновлять периодически.
(12) Ничто не мешает. Просто думал если уж у насесть одна база, то может еще две получить можно еще быстрее?
(16) ну (2) может быть быстрее, а может не быть. А может вы РазработчикаНаПолутораТерабайтах полдня будете из копии уговаривать выйти служебками
(18) бакап сильно меньше всей базы. Копировать его значительно быстрее.
бакап копируется полчаса (тестовые на отдельном сервере) восстановление из бакапа - 6 часов. Вопрос был собственно как уменьшить эти 6 часов.
(0) (21) А в чем собственно проблема?
6 часов это разве время. Поставить на ночь, как раз у всех троих будет к утру по свежей базе.
Можно одну из бэкапа поднять, а потом скопировать mdf + ldf елси MS SQL как выше писали, то всего займет 6 + 30 минут + 30 минут.
(24) Вполне нормальное время. У меня база 100 Гб, поднимается из бэкапа 30 минут.
А тут в 15 раз больше база.
(25) ну может если копировать по сети 1.5тб, да - нормально. но если скопировать архив сначала локально на сервер, а потом поднять 6 часов - это долго
(21) Поднимаем из обычного SQL бакапа. Я не сисадмин, в настройках SQL не сильно то шарю, ускорить не знаю как.
(31)Так вы проанализируйте состав базы, какие таблицы самые большие. Наверняка найдете возможность грохнуть не сильно нужные для тестовой базы данные.
(31) Без восстановления из бэкапа или копирования mdf - никак.
Ради интереса - все базы на одном сервере будут восстанавливаться? Там какая дисковая подсистема?
Предлагаю быстрое решение. Всех разработчиков пустить в одну базу. Пусть между собой договариваются. И сказать: "Если что испортите - восстановление 6 часов!" Это подействует.
А правильное решение — не давать разработчикам рабочие базы. Пусть тестовые примеры делают, а то совсем обленились. Сделать выгрузку из рабочей базы основных справочников и настроек через КД не так сложно.
Полтора терабайта скопировать быстрее, чем позволяет дисковая система - поможет только квантовый гуглёвский комп на 8096 кубитов.
(32) Что бы их грохнуть - надо время. И сначала надо восстановить полную базу. потом грохнуть.
(39) Ага. А если тебе поручили разработать отчет? Будешь ручками заводить документы. Ну ну. У тебя получится быстрый отчет, который будет всю полноту данных учитывать. Ага, ага.
(42) Обычно есть копия рабочей базы, но старая, обновляется раз в год примерно. Разворачивать копию на каждый чих смысла не вижу. Только если не удается воспроизвести ошибку.
(44)Ну так проанализировать один раз. На будущее. А дальше уже скулевыми скриптами можно будет обрезанные копии делать.
(46) там разница будет при восстановлении работы в случае смерти одного или нескольких дисков, но для тестовой сойдет
(53) Тестовые данные - супер. Только через 10 лет прогнул отдел аналитиков что б они отдельную базу вели с тестовым примером :-(, и то не уверен что приживется.
его генерит разработчик.
все равно он его генерит для разработки, так почему бы не оформить как следует
(56) Пока вручную, дальше посмотрим. Может аварийные ситуации универсальным переносом будем из рабочей переносить.
(58) Разработчик сгенерит так, что у него все будет работать. :-) Проходили уже.
Вообще, было бы любопытно послушать аргументацию, зачем нужна для постоянной разработки база в 1,5 ТБ.
Я как раз в отличие от ТС проклинал разработку в такой базе. Все действия в нее, связанные с применением структурного изменения к базе могли влететь внезапно на реструктуризацию и? Я курить давно бросил, если что
Причем, не тестирование, а именно разработка.
Сделал разработку. Нужен тест. Объем данных огромный. Кто в здравом уме пропустит этот тест на совесть просто разработчика и не выделить отдельный тестовый стенд с регламентом доступа к нему и с регламентом по признанию результатов? Ну если данные носят архиважный и критичный характер, иначе бы их никто и не хранил бы и уж тем более не тестировал.
Ну и наличие быстрообновленных свежих копий при огромном объеме источника - это сама по себе не рядовая задача.
Не думаю, что файловое или подобное файловому клонирование будет для этого адекватным решением.
(0) поднимаешь одну из бекапа, сжимаешь средставими SQL? копируешь, подключаешь.
Экономия места и времени. Ну только на сжатие, но это один раз
(63) а если у тебя реструктуризация пройдет за 20 минут, а на проде не пройдет за ночь? тоже не вариант
(63) "могли влететь внезапно на реструктуризацию " - именно для этого и надо вести разработку на такой копии. Чтобы с рабочей не влететь.
Ага. Особенно, когда у тебя такая реструктуризация в процессе разработки над парой-тройкой параллельных заданий случится за один день несколько раз. А ты просто еще разрабатываешь. Тестить - это отдельно и это сделают все равно без тебя.
Но даже если и нет препрода, то есть тестовый контур в виде центральной тестовой базы. База разработки совершенно точно не должна быть настолько большой, чтобы доставлять неудобства разработчику.
(21) У вас где-то тормоза. 6 часов на 1,5 Тб - это средняя скорость 70 Мб/с. Нормальный дисковый массив может переварить ~500 Мб/с и выше. Нормальный SSD - 1 Гб/с и выше.
(73) так еще и по сети наверно нужно качать.
ктож на продуктивах разворачивает тестовые базы для разработки
(49) Ага, а потом бьетесь 100500 часов над глюком из-за того, что обрезали лишнее. Обрезать должен тот, кто конфигурацию знает от и до. Сколько там его час стоит?
(0) видел организацию где спец скриптами убирали лишнее из рабочей базы. оставалось только нужное для разработчика на 5 тб
(75) 20% усилий дадут 80% результата, а большего и не требуется. Сломать при этом что-то - это надо постараться)
(74) БД, если туда не насовали JPEG'ов, жмется раз в 10. Так что пары Гбит/с хватит.
(78) В случае с ERP сломать - это запросто. Безболезненно можно убирать только вложенные файлы.
Сжать файл журнала, скопировать базу в три каталога, подключить на сервере с разными именами, вроде все, зачем такую тему расплодили.
А размеры таблиц не смотрели, может у вас там история версий и регистр с проводками все место занимают.
чистятся одним запросом за 5 сек. Только не из 1С.
Подчистите самые жирные таблицы, все записи старше года в документах и регистрах, база похудеет заметно.
(82) Зависит от настроек сжатия. Можно использовать что-то типа алгоритма, которым при гибернации жмут - там сотни МБ/с на ядро скорость даже на слабых ЦП. В принципе, MS SQL сам умеет жать бэкапы на лету довольно шустро.
Я бы заархивировал mdf и ldf на другой носитель(не на тот, где файлы sql). Потом обратно в три каталога разархивировал. Это ежели не заморачиваться с оптимизацией базы.
1.5 тб средствами SQL на нормальном железе это 50. 100 минут выгрузить и загрузить на соседнем сервере по сети (без копирования файла), штатно из энтерпрайса мышкой это не делается, а вот скриптом - легко, то есть если не переносить файл экономи по времени примерно минут 30. 60 будет
(21) это странно. в нормальном режиме восстановление SQL бэкапа идет практически со скоростью копирования, а у вас разница в 12 раз.
что то с дисковой системой?
(63) К вопросу зачем нужна большая база. Вот как раз для того, что бы оценить за какое время и как пройдет реструктуризация например. Мы должны понимать насколько долго будет происходить перенос наших изменений в рабочую базу. Работа круглосуточная, рабочую больше чем на час в день (в обед) не дают. Если на тестовой мы видим, что реструктуризация или иное изменение займет слишком долгое время - либо ищем другое решение, либо выбираем подходящий день когда отгрузка минимальна и нет иных мероприятий, договариваемся со всеми отделами. Например одно изменение пришлось откладывать 2 недели, сначала хотели в одну пятницу (там после 12 инвентаризация, отгрузки долго нет), но вдруг оказалось, что в этот день много работы у кассира, зарплата, заберем у нее базу - будут толпы людей злиться у кассы. Пришлось отложить до следующей пятницы.
В общем нужно иметь полноценный макет на котором можно заранее отработать все изменения и увидеть что будет с рабочей базой.
Как в космической отрасли, когда они на земле оставляют точную копию того, что летит в космос, что бы посмотреть в живую всякое ;)
(93)Вопрос-то в чём. нахрена несколько полных копий? Небольшие базы для разработки, полноценная копия - предпрод (ну может быть еще одна для тестирования пользователями), но разработка в базе в 1.5 Тб на железе, которое скорей всего хуже, чем на проде - это то еще развлечение.
(94) > Вы обрезку не делаете что ли из принципа?
А зачем?
Поиметь геморрой с выверкой остатков только ради того, чтобы копии для разрабов быстро делались? Боюсь пользователи не оценят. Это во-первых.
А во-вторых, в зависимости от структуры и особенностей конфигурации свёртка может не давать достаточно большого уровня снижения объёмов базы. То есть геморрой получим, а уменьшение базы - нет. Типичный пример - почти все типовые конфигурации. В какой-нибудь бухне если из 10 лет ведения учёта свернуть данные за 5 лет, то сокращение объёма будет не на 50% (как может показаться), а в лучшем случае - 20-25%%, а реально ~15%. Но зато головняка с выверками остатков - вагон и маленькая тележка.
(93) логично. Сам затратные изменения обкатываю на полной копии базы, чтобы оценить временные интервалы. 365/7/24
(94) В частности главбух хочет иметь всю(!) историю. И не моя работа ее переубеждать.
(96) Кроме того свертак базы не даст экономии места потому, что (внезапно) надо будет оставить копию базы до свертки.
Разработка на урезанной базе. Вот пример - сделал некоторую обработку, почти месяц назад, пару дней назад пользователи наткнулись на особенности в одном документе, которые я не учел. Поскольку база разработки у меня свежая, я спокойно сейчас переделываю обработку используя этот пример. А если бы у меня его не было, то что бы я делал?
(93) Никто не спорит, что Тестовая база, равная по всем показателям текущей, рабочей должна быть.
Оспаривается мнение, что полных копий нужно обязательно много и каждый разработчик просто обязан заниматься разработкой исключительно в полной копии.
Между прочим, есть ситуации, когда, даже при огромном желании разработчика получить полную копию боевой базы в свое владение и под полный контроль, ему категорически в этом отказывают. Причем, если базы действительно огромные, то отказ обосновывается не только и не столько вопросами коммерческой и какой-то еще тайной, но и техническими возможностями серверов заказчика, например.
Настройка резервного копирования (резервирования) баз данных на "бюджетной" версии 1С Предприятие под MS SQL Server. Используется пример MS SQL Server 2008 R2 под Windows. Для малых и средних предприятий, исключая производственные и торговые, так как тестирование на них не проводилось.
Настройка резервного копирования (резервирования) баз данных 1С Предприятие на MS SQL Server .
В данной статье используется 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С в режиме конфигуратора и, никому не мешая, делаем файловую копию.
Если нужны данные «на сейчас», тогда предварительно запускаем на Windows сервере командный файл BackUp1C_Diff.cmd и получаем свежую разностную копию.
В этой статье я хочу поделиться опытом резервного копирования файловых и 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 на запись. Это позволит защитить ваши бэкапы от многих опасностей (дурная голова, вирусы). А если вам понадобится внести какие-то изменения в хранилище бэкапов, то всегда можно дать себе временны доступ, или запустить любой проводник (например Total Commander) от имени учетки backup для полного доступа к хранилищу.
Сетевую папку желательно разместить на компьютере с данной программой, т.е. по факту для нас это будет локальная папка (если скорость позволяет, то и любой другой сетевой путь).
Доступ к папке Temp (каталог временных файлов) должен быть:
- для backup на запись
- для учетки из под которой работает служба MS SQL Server на запись
- админам на чтение
Чтобы обойти это ограничение, мы выбираем сетевой путь для временной папки. Тогда 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, всегда пусто и не понятно настроено или нет.
- нет возможности быстро включить/выключать задания (нужно открывать каждое и заходить в расписание). Хотя в главном окне интуитивно так и просится двойной клик по галочке.
Но в целом результат меня очень порадовал. Считаю программу очень полезной.
Напишите о своих алгоритмах бэкапов, которые возможно вас сильно выручали и могут быть полезны другим.
Теперь можно приступать к настройки Плана обслуживания (Maintenance Plan). План Обслуживания можно создать сразу для всех БД, но удобнее для каждой БД создать свой план обслуживания.
В нашем Плане обслуживания будет три подплана: 1 - резервное копирование БД (Полное); 2 - резервное копирование БД (Разностное); 3 - Резервное копирование Журнала транзакций. У каждого подплана есть свое расписание выполнения. Раписание каждый настраивает по своим усмотрениям, в моём же случае полное копирование делается раз в неделю в воскресенье, Разностное копирование каждый день кроме воскресенья, ЖТ - журнал транзакций каждый час. При такой модели резервирования можно восстановить искомую БД на любую дату и час, причем экономим пространство на жёстком диске т.к. полное резервирование выполняется фактически раз в неделю, а в течении недели только изменения.
Настройка дневного расписания. Недельное отличается только установленной галочкой "Воскресенье" и снятыми с "понедельника" по "Субботу"
Расписание для ЖТ. Красным выделено время сохранения в течении дня, имеет смысл например, если пользователи работают с БД в определённый период, если режим работы 24х7, то оставляем по уполчанию.
На рисунке ниже, изображен редактор недельного подплана, он состоит из задач, которые выполняются в заданной последовательности. Последовательность задается вручную, причем зелёные стрелки означают, что следущая задача будет выполнена только при успешном выполнении предыдущей, а синяя, что задача выполнится при любом завершении предыдущей задачи. В редактор подплана обслуживания, задачи можно добавить из "Панель элементов", которая находится в левом верхнем углу, когда редактор открыт.
Задачи. В каждую задачу нужно зайти и выбрать БД, для которой она будет выполняться и ряд других настроеек (если есть). Рассмотрим, какие задачи содержит недельный подплан нашего плана обслуживания.
1. "Проверка целостности БД" (Check Database Integrity Task). Следующая задача будет выполняться, только если БД не содержит ошибок. (Замем резервировать БД с ошибками?)
2. "Восстановить индекс" (Rebuild Index Task). Восстановить (Перестроить) индекс необходимо каждый день, т.к. при работе с индексами они сильно фрагментируются и при фрагментации более 25% SQL начинает заметно "тормозить". Эта операция довольно ресурсоёмка, поэтому её можно делать хотябы раз в неделю, а в дневном подплане заменить её менее ресурсоёмкую задачу "Реорганизация индекса".
3. "Обновить статистику" (Update Statistics Task). Для оптимизации. Кстати эту задачу можно выполнять несколько раз в течении дня, если ваша БД сильно нагружена.
4. После обновления статистики ОБЯЗАТЕЛЬНО нужно очистить процедурный кэш. Для этого перетаскиваем в редактор задачу "Выполнение инструкции T-SQL" и в поле "инструкция T-SQL:" написать процедуру DBCC FREEPROCCACHE. Но нужно учесть, что эта процедура очищает кэш у ВСЕХ БД, а мы обновили статистику по одной! Как очистить процедурный кэш для определённой БД, читаем
5. "Резервное копирование БД" (Back Up Database Task). В этой задаче указываем какую БД мы резервируем, тип резервной копии (Для недельного подплана - Полное, для дневного - Разностное, для часового - Журнал транзакций.) Ставим переключатель в положение "Создать резервную копию баз данных в одном или нескольких файлах" и добавляем ранее созданное устройство резервного копирования. В таком случае ВСЕ копии сохраняются в один файл, который указали при создании устройства резервного копирования, если переключатель оставить в "Создать файл резервной копии для каждой базы данных", то на каждое резервное копирование будет создаваться отдельный файл и на Полное и на Разностное и на ЖТ, что очень неудобно при восстановлении, зато удобно при хранении. Не забываем укзать что нужно сжимать резервные копии!
6. "Очистка Журнала" Очищает записи, создаваемые при выполнении задач. Также можно включить задачу "Очистка после обслуживания" и настроить её для удаления текстовых логов или устаревших резервных копий.
Подплан для резервирования ЖТ, состоит из одной задачи "Резервное копирование базы данных". ЖТ для меня удобнее сохранять не в Устройство резервного копирования, а в отдельный файл, что необходимо указать в настройке задачи.
Резервное копирование данных бизнес-приложений – тема древняя, как Кобол, и вечная, как процесс исправления ошибок на 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 – это именно то, что нужно лично вам, то этот вариант, по всей видимости, вполне можно и нужно рассматривать. Мне же настоятельно необходим был бэкап именно для файловой версии. Поэтому я расстроился и уехал с этого ресурса.
Странствие шестое: Архипелаг скриптов и утилит
Странствие седьмое и последнее: Выбор сделан!
Не стану делать секрета: я выбрал Handy Backup. Мне очень понравились также Effector Saver и, в особенности, «Бэкапер-1С», но два резонных соображения склонили меня в итоге к другому решению.
Во-первых, техническая поддержка бесплатных утилит обычно оставляет желать лучшего, а критические ситуации имеют привычку возникать неожиданно. С техподдержкой Нandy Backup у меня проблем не возникло; замечу, впрочем, что за год, прошедший со времён описываемых странствий, я воспользовался ей только один раз, когда устанавливал сетевые агенты. Сама по себе программа работала и работает как часы.
Во-вторых, бесспорно, очень приятно иметь хорошую утилиту для бэкапа файловой там или, наоборот, SQL-версии 1С, или для бэкапа, скажем, на Яндекс.Диск, или ещё для какого-нибудь бэкапа. Но бэкапить надо всё, буквально всё, и очень удобно, когда один и тот же продукт делает за тебя все виды работы!
Так что я свой выбор сделал. Я вернулся к Handy Backup, к его старинному интерфейсу, удобному набору хранилищ и сверхнадёжным расширениям. Именно Handy Backup, по моей рекомендации, были доверены данные 1С из нашей бухгалтерии. Впоследствии именно на эту же программу я перевёл сперва хранение технической и пользовательской документации в нашем институте, а позже – и свою собственную маленькую фотостудию, где приходится хранить в архивах и коммерческие данные системы 1С, и фотоархив. Я не пожалел ни разу о потраченных суммах. Их всё равно не хватило бы даже на поездку на Гавайи, не говоря уж о новых путешествиях на сказочные острова, где на деревьях растёт эффективное и бесплатное программное обеспечение.
А без путешествий – какая же жизнь?!
Читайте также: