Здравствуйте, недавно перешли на клиент серверный вариант базы. (БД на postgres) в связи с этим возник вопрос, достаточно ли делать бэкапы выгрузкой базы 1с или нужно еще бэкапить саму базу postgres? На данный момент настроил выгрузку по ночам, но вот терзают меня сомнения, достаточно ли этого? пользователей 20 человек.

Выгрузка в dt - это не бекап.

Почему? что мешает создать новую БД и загрузить dt? разъясните пожалуйста поподробнее.

(2) Выгрузка средствами 1С вещь недостаточно надежная. (если конечно, не проверять каждый новый dt-шник).

Все правильные варианты бэкапов базы на postgres здесь: https://postgrespro.ru/docs/postgrespro/10/backup

dt - только если в дополнение к одному из описанных выше.

dt - долго (если база большая) и требует монопольного доступ к базе. К тому же зачастую сервер 1с плохо переживает массовую выгрузку баз в dt. Возникают ошибки.

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

По той же причине резервной копией файловых баз считается на dt, а сам файл базы данных (1cv8.cd), скопированный когда пользователи не работают с базой или на крайний случай через теневое копирование.

(2) Потому что сама 1С уже высказалась по этому поводу.
Выгрузка в dt по сути только для перехода из одного формата БД в другой (например, с файлового на клиент-серверный).
В результате выгрузи и последующей загрузки вы получаете копию базы, которая будет НЕ абсолютно точной копией исходной.
Копию следует делать средствами СУБД (в вашем случае - Postgres). Кроме всего прочего, создание копии средствами СУБД позволяет не выгонять всех пользователей и блокировать фоновые и регламентные задания.

(1) вполне себе бэкап. со всеми своими минусами
(2) проблемы выгрузки из 1с: Долгое время создания/развертывания, требуется монопольный доступ.

(6) Бекап с минусами?.... Вы это серьезно? ;)

(2) Потому, что можно обратно не загрузить. Т.е. ты будешь думать, что у тебя бэкап есть - а на самом деле его не будет :)
Поэтому бэкап - это или копирование файла 1cv8.1cd или резервное копирование средствами используемой СУБД.
Все остальное - это детство в песочнице :)

Я бы ещё посоветовал, если размер баз и технологическое окно позволяют не отказываться от dt, но только как дополнение к правильному бэкапу.

Накосячить с бэкапами СУБД не так сложно, как может показаться, тем более мы про postgres говорим.

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

(10) Effector saver удобная, есть платный, есть бесплатный вариант.

(8) Так за исключение копирования файлов все не бекап, и даже после копирование база может перестать работать.

(10) Бери dt и никого не слушай. При достаточно кривизне рук неважно чем сделан бекап - угробить можно всё. А если нет разницы ...

(10) Серверные ОСи мелкософтовцев укомплектованы системой архивирования штатно. Их вполне достаточно.

+ (14) В случае не самых кривых рук админа лучшего инструмента не найти.

всем спасибо.

(15) Лет 10 назад был у меня бекап скуля и захотел я дома развернуть его чтобы поковыряться в базе. Ну дома естественно скуля небыло, пришлось искать в интернете и выяснилось что не всякий скуль станет на домашней машине. Кое как нашел, установил и запустил, разобрался с особенностями подключения 1с к експресс версии скуля и тут бекап меня послал нафиг со словами версия скуля не та, мол на эту версию я не буду разворачиваться.

Короче плюнул сделал бекап через dt и спокойно развернул дома файловую версию для своих экспериментов.

С тех пор у нас на работе админы делают бекап средствами скуля, а я параллельно для себя делаю бекап средствами 1С. За 10+ лет еще ниразу небыло проблем с восстановления из dt-ника

(17) мсскульный бекап разворачивается снизу вверх на одинаковых (или бОльших) вариантах сервера.
То есть 2012 проф развернётся на 2018 проф или ентерпрайз, к примеру.

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

Тем более у ТС БД на postgres

(19) Поставь дома DE (он полностью совместим с интерпрайзом). На него развернётся

(21) мы говорим про времена 2006-2008 год.
Зачем ты мне сейчас пердлагаешь современные технологии для потребности которая была 10 лет назад?

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

(22) Какие современные технологии? DE я ставил себе в 2003м году...

(20) чем постгри так отличился, что его помечают ярлыком "тем более"?

(17) > админы делают бекап средствами скуля, а я ... средствами 1С

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

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

(22) 100гигов в архиве? этож скока база в субд?

(26) нет не в архиве

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

(21) Он разве на XP разворачивается?

(10) напиши 2 строчки в батнике, и не надо ничего покупать. Засунул в планировщик (если речь о винде) и забыл.

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

(27) а в субд?

(31) бекапы скуля практически не сжимаются. так что на скуле примерно столько же

(25) > Со случаями невозможности загрузить базу из dt сталкивался неоднократно

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

(32) А мужики- то и не знают...
У меня сжатый бекап минимум в 5 раз жмётся...

*несжатый

(34) +1
(32) не бывает так

(32) > бекапы скуля практически не сжимаются

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

(34) я ему про фому а он мне про ерему

(38) "бекапы скуля практически не сжимаются"

Это я написал? Кто тут Фома неверящий?

Есть база на 400 гигов, бэкап sql-ный 37 гигов. Выгрузку в dt прекратил когда база была 100 гигов, т.к. длилась около 1 часа. а загрузка часа 3 и то на компе где оперативки не менее 16 гигов. поэтому dt хорош на маленьких базах.

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

Естественно, что если натравить rar архиватор, или поставить галку сжимать бекап, то он пожамкается

(41) Ты того... Научись свои мысли выражать ясней, а то анноишься на ровном месте.
Так тебе и XAB могут приписать...

(41) согласен. Все верно. Речь шла бэкапе просто выше.
Расходимся посаны))

(41) зачем архиватор натравливать? особенно когда средствами самого скуля хорошо сжимается (есть галка в настройках) и файл bak примерно в 10-11 раз меньше размера базы

(41) И кстати, по дефолту в современных скулях галка сжимать бекапы стоит по умолчанию...

(44) а не затем ли что копия данных будет делаться в разы дольше?

+(46) Тут ключевое слово ДАННЫЕ.

А если в этот момент будет транзакции по базе, будет потом рассинхрон (или как это назвать)?

(46) с архиватором, да дольше чем без него и с галкой сжимать. 400 гигов выгружается за 10-15 минут

(47) можно подгадать время когда это наименее вероятно

(47) > А если в этот момент будет транзакции по базе, будет потом рассинхрон?

Нет. В том и суть архивации средствами СУБД, что в архив записываются только завершенные транзакции. Делается архив со сжатием или без - значения не имеет. 10 секунд или целый час.
Делать архив средствами файловой системы можно только когда база офлайн или служба СУБД остановлена. Ибо файловая система понятия не имеет о состоянии транзакций.
У архива средствами 1С (выгрузка в dt) по умолчанию этой проблемы нет, т.к. делается в режиме монопольного доступа и отсутствия каких-либо активных транзакций. Но это же и ахилесова пята этого способа, т.к. в нормальных продуктивных базах невозможно так часто предоставлять технологическое окно нужной продолжительности для монопольного доступа да ещё и контролировать закрытие всех активных сессий (что не всегда происходит автоматически при установке блокировки).

(49) > можно подгадать время когда это наименее вероятно

Есть куча примеров, когда такого времени не существует. Базы крутятся 24/7 с почти одинаковой нагрузкой в течении всего времени. И ведь живут как-то люди. И архивы делают, и разворачивают их.

(46) > А если в этот момент будет транзакции по базе, будет потом рассинхрон?

В момент начала процедуры резервного копирования состояние базы данных стабилизируется (т.е. никаких изменений в ее файлы не вносится), после того, как завершен процесс копирования самой базы, в файл резервной копии дописываются изменения, которые произошли за время резервного копирования. (Это справедливо для MSSQL)

(51) >>Есть куча примеров, когда такого времени не существует. Базы крутятся 24/7 с почти одинаковой нагрузкой в течении всего времени. И ведь живут как-то люди. И архивы делают, и разворачивают их.<<

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

(53) Если база крутится 24/7, то во первых, она SQL, и тогда бэкап только средствами SQL. Бэкапы хранить на отдельном файловом хранилище, которое подключать непосредственно перед бэкапом (чтоб шифровальщики не смогли туда залезть)