Добрый день! Не делается бекап журнала регистраций 1с sql. При этом full бекап делается и восстанавливается. Можете подсказать в чем причина

(0) можем - он (журнал) не храниться на сиквеле

(1) Как тогда сделать бекап с журналом регисраций?

https://its.1c.ru/db/v8318doc#bookmark:adm:TI000000145

(3) чет нету инструкций

(2) Не "с", а отдельно и независимо. Любыми инструментами для файлового бэкапа.

(5) Как делать независимо бекап журнала регистраций?

(6) Я обычно поступаю следующим образом. Останавливаю сервер приложений. Переименовываю файлы журнала. Запускаю службу.
Перемещаю переименованные журналы к копии базы, где эти журналы можно анализировать.

Его унесут в звенящую даль
Две белые птицы - Тональ и Нагваль,
Балтийское море, загробный февраль,
И мёртвые птицы - Тональ и Нагваль.

(7) Это можно делать и без остановки, штатными средствами.

(9) Можно, но при большом журнале долго и нужно что бы никто ничего не делал в базе.

Включаешь старый формат ЖР. Включаешь для него сегментацию по дням. С файликами предыдущих дней поступаешь как душе угодно.

(11) Не, ну это не честно. Это же нужно старый формат включать :-)

(11) Не подскажешь - начиная с какого релиза движка появилась возможность конвертировать формат ЖР со старого формата на новый и обратно ?

У меня два сервера 1С.

На одном 8.3.17.1851 - там эта возможность есть.
на другом 8.3.8.2322 - там этой возможности нет.

(11) >С файликами предыдущих дней поступаешь как душе угодно.

То есть не останавливая работу базы можно спокойно удалять файлы ЖР старого формата ? Если так то отлично.

(12) >Это же нужно старый формат включать

Так старый формат намного удобней в работе.

(13) вы похоже поиском совсем не умеете пользоваться, ваш же вопрос вбил и первая ссылка
https://techlab.rarus.ru/news/articles/pereklyuchenie-zhurnala-registratsii-v-staryy-format/

(15) В (12) был стеб.

(16) Вы прочитайте то что написано в (13) более внимательно. А не бросайтесь отвечать бысто.

Там черным по белому написано в чем сложность. В том что на релизе 8.3.8.2322 нет возможности перейти штатными средствами со старой версии на новую и наоборот. На 8.3.17.1851 эта возможность есть.

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

Зачем вообще нужен до кроме регистрации исключений?

*ЖР

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

(13) 8.3.12

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

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

(24) Ага, особенно если этот "виновный" зять, зам, друг, сват, и т.д. генерального. Или очень важное лицо которое должно сидеть в конторе и получать деньги за то, что-бы у компании была возможность спокойно работать. Еще есть военные приемщики, но они по большей части люди вменяемые. Много случаев есть когда наказывать будут не пользователей, а технарей. Поэтому журнал не столько для того что бы сделать учет корректным и правильным, сколько для того что бы прикрыть пятую точку если "звезды" накосячат.

(25) А версионирование разве не проще для разборок ?

(23) >перейти на старый формат можно было только создав файлик с расширением старого формата и рестартовав сервер

А разве нельзя выгнать всех пользователей и остановить регламентные задания, удалить базу в кластере сервера, завести ее кластере сервера под этим же именем (поставив блокировку регламентных заданий при создании), в новом каталоге где находится ЖР этой базы создать файлик с расширением старого формата, и войти в базу ?

(24) >> чтобы такого не происходило нужно устроить расследование с наказанием.

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

(26)  >> А версионирование разве не проще для разборок?

Версионирование не всегда помогает, т.к. не все объекты версионируются. Кроме того, иногда важно знать контекст изменений - кто и что делал в тот момент времени, когда рождалась новая версия объекта. Например, тупо надо знать изменил документ пользователь ручками или при выполнении какой-то групповой обработки.
Короче говоря, версионирование и ЖР инструменты, которые могут дополнять друг друга, ни никак не могут друг друга заменить.

(27) >> А разве нельзя ... удалить базу в кластере сервера, завести ее кластере сервера под этим же именем.

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

(28) так версионируй все объекты, кто мешает то?

(30) Жаба поди,жалко места на дисках

(30) Ещё раз. Версионирование не заменяет журнал регистрации.
Версионирования, например, регистров нет. А увязать проблему изменения движений документа из-за того, что кто-то поменял данные в каком-нибудь настроечном регистре сведений, без ЖР не удастся.
Переписывать типовые и вкорячивать туда своё самописное или платформенное версионировение - тот ещё геморрой.

(31) >> Жаба поди,жалко места на дисках.

С этим проблем вообще нет. Во всяком случае не с продуктивными базами.

Если вы всерьёз верите, что версионирование решает любую проблему расследования косяков пользователей, то вы просто не сталкивались с действительно серьёзными проблемами на эту тему. Случаи, когда МарьИванна "случайно" перепровела какой-то не тот документ - это обыденность, и пожалуй единственный сценарий, когда версионирование решает и его более чем достаточно.

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

(28) >Версионирование не всегда помогает, т.к. не все объекты версионируются

У меня в базе версионирование сделано на регистре сведений. Пишутся ВСЕ документы и ВСЕ справочники.

(32) >Версионирования, например, регистров нет.

А зачем тебе версионирование регистра ? Движения по регистру изменятся если ты документ изменишь. У меня например в регистр версионирования пишется когда документ проводится.

То есть ты видишь изменение по регистру. Открываешь документ и видишь что тогда-то он перепроводился.

> кто-то поменял данные в каком-нибудь настроечном регистре сведений, без ЖР не удастся

И что ты увидишь в ЖР ? Что кто то записал набор записей регистра ? А что конкретно он записал не увидишь.

Не проще ли  этом случае ролями закрыть доступ тому кто может залезть и сделать эту запись ?

(32) >При этом обосновывают свои действия как раз экономией места на дисках и каким-то мифическим выигрышем в производительности.

Пример с боевой базы.

Журнал регистрации 1С только одной базы - 150 Гб. Темпы прироста - 2,5 Гб в ДЕНЬ.

При этом на диске свободно  100 Гб.

(35) Вы там чем барыжите?))

(36) после того как ноутбук сперли, стали фиксировать каждый пук в конторе, в том числе и в базе)

(37) Че, даже сколько времени ты в туалете провел?Тогда у меня для вас есть хорошая новость,среднее время на мочеиспускание 21 сек,те кто дольше пусть пишут поясняшку))

(35) Если вам кто-то запрещает сокращать журнал и архивировать его - какие ко мне то вопросы?
Проблемы с нехваткой дискового пространства я тоже не решаю.

В случаях неоправданно большого прироста, как у вас - по 2.5Гб в день, разумеется можно и отказаться от ЖР или логировать только ошибки.
Я вовсе не утверждаю, что его ведение является обязательным всегда и везде. Здравый смысл никто не отменял.
Но в 99% случаев он необходим.


(34) >> А зачем тебе версионирование регистра? Движения по регистру изменятся если ты документ изменишь. У меня например в регистр версионирования пишется когда документ проводится. Открываешь документ и видишь что тогда-то он перепроводился.

О возможности изменять наборы записей вне контекста объекта-регистратора ты не слышал?

>> И что ты увидишь в ЖР? Что кто то записал набор записей регистра? А что конкретно он записал не увидишь.

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

>> Не проще ли  этом случае ролями закрыть доступ тому кто может залезть и сделать эту запись?

Проблема в том, что иногда косячат как раз те самые люди, которым это право (например, менять регистр) дано специально.

(33)>> У меня в базе версионирование сделано на регистре сведений.

Я уже писал, что городить своё версионирование поверх типового - решение не самое лучшее.
Одно дело самописка - делай как нравится. Хоть платформенное включай.
Другое - типовая конфигурация, где количество изменений хотелось бы минимизировать. И прежде чем что-то дописывать своё, надо 33 раза подумать.

(39) >Если вам кто-то запрещает сокращать журнал и архивировать его

Мне никто это не мешает делать. Проблема только в том что на релизе 8.3.8.2322 где у меня две базы с ЖР в новом формате нет возможности конвертировать ЖР в старый формат.

При этом базы работают 9-21 7 дней в неделю. То есть для того чтобы что то сделать с базой мне нужно это делать глубоким вечером переходящим в ночь.

Если бы платформа на этом релизе позволяла переводить базу в старый формат то я бы запустил процесс и лег спать.


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

Для этого есть подписки на события и расширения. Как вариант.

(40) Ты неуклонно сваливаешься к частностям и проблемам конкретно вашей базы.
Я не имею ничего против того, что всегда есть какие-то особенности и нюансы.
Я говорю об общем правиле, которое вовсе не является обязательным или какой-то догмой.

Ну нравится вам иметь зоопарк из разных версий платформы - да ради бога. Уверен, что для этого у вас есть какие-то достаточно веские причины. Я только одного не понимаю - зачем ради этого ты так настаиваешь на том, что надо непременно корячить какое-то своё самописное решение по версионированию и отключать ЖР?
Зачем ломать типовую для задач, которые решаются типовыми методами?

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

(41) >Ну нравится вам иметь зоопарк из разных версий платформы - да ради бога

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

(41) >Я только одного не понимаю - зачем ради этого ты так настаиваешь на том, что надо непременно корячить какое-то своё самописное решение по версионированию и отключать ЖР?

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

Штатное версионирование очень тяжелое.

(40)
>Мне никто это не мешает делать. Проблема только в том что на релизе 8.3.8.2322 где у меня две базы с ЖР в новом формате нет возможности конвертировать ЖР в старый формат.
Остановить базу, переместить ЖР, перейти на старый формат.
Сконвертировать lgd как в статье https://infostart.ru/public/1240376/ и выводите отчеты за прошлые периоды.