Резервное копирование

[neek666]

Всем добрый день!
Платформа 8.3.18.1433.
Нужен совет. Каким способом лучше осуществлять резервное копирование базы:
1. Штатными средствами (Администрирование - Обслуживание - Резервное копирование)
2. Средствами СУБД

P.S. База в клиент-серверном варианте работает.

[LexaK]

если клиент-сервер то средствами СУБД (однозначно)

[alebul]

Я через Effector Saver делаю выгрузки.

[DmitriyF]

Я через Effector Saver делаю выгрузки.

Выгрузка это не бэкап) Клиент-серверную только средствами СУБД

[Optiman]

И в том и другом способе есть свои минусы и плюсы:
выгрузка в dt-шку:
1) нужно обязательно отключать все сеансы пользователей. Иначе архивная копия не создастся ("-")
2) долго по времени восстанавливается из архивной копии ("-")
3) архивная копия имеет минимум информации для восстановления ("+")

выгрузка средствами SQL:
1) не нужно обязательно отключать все сеансы пользователей. ("+")
2) быстрое восстановление из архивной копии ("+")
3) архивная копия имеет большой объем ("-")

Если позволяет объем на диске для архивов, обычно делают так: средствами SQL каждый день выгружают копию базы в один и тот же файл (для быстрого восстановления из копии) и средствами 1С выгружают dt-шку, где в имени файла добавлена дата создания для длительного хранения. Можно не каждый день, если это не критично для восстановления.

1. Штатными средствами (Администрирование - Обслуживание - Резервное копирование)

можно и не штатными, а через скрипт

[DmitriyF]

И в том и другом способе есть свои минусы и плюсы:

3) архивная копия имеет большой объем ("-")

А вот тут не согласен, абсолютно. Выгрузка в dt примерно рядом по обьему с полным бэкапом.

[Поиск родных]

А вот тут не согласен, абсолютно. Выгрузка в dt примерно рядом по обьему с полным бэкапом.

Я даже теоретичесе не могу придумать случаи, когда нужен полный бэк-ап

[neek666]

И в том и другом способе есть свои минусы и плюсы:
выгрузка в dt-шку:
1) нужно обязательно отключать все сеансы пользователей. Иначе архивная копия не создастся ("-")
2) долго по времени восстанавливается из архивной копии ("-")
3) архивная копия имеет минимум информации для восстановления ("+")

выгрузка средствами SQL:
1) не нужно обязательно отключать все сеансы пользователей. ("+")
2) быстрое восстановление из архивной копии ("+")
3) архивная копия имеет большой объем ("-")

Если позволяет объем на диске для архивов, обычно делают так: средствами SQL каждый день выгружают копию базы в один и тот же файл (для быстрого восстановления из копии) и средствами 1С выгружают dt-шку, где в имени файла добавлена дата создания для длительного хранения. Можно не каждый день, если это не критично для восстановления.

1. Штатными средствами (Администрирование - Обслуживание - Резервное копирование)

можно и не штатными, а через скрипт

А если речь идет о PostgreSQL (ее средствами бекапить), - пользователей выгонять так же не надо, или все таки надо?

И еще момент. Цель у бекапа только одна - восстановить базу в том виде, в каком она была за секунду бекапа. Если бекап с этой целью не справляется, то смысл от него? Я где то слышал что выгрузка в dt формате в случае нарушения структуры базы (в случае каких то ошибок в базе) может привести к частичной потере данных. Это так? И как в плане надежности ведут себя другие СУБД (SQL srever, PostgreSQL) при бекапе в случае каких то ошибок структуры базы данных? Размер бекапа меня вообще не волнует (Сколько места надо выделить для хранения, столько и будет выделено, если на серваке места мало, то втыкаешь дополнительные накопители, если речь идет о хранении бекапов базы то это вообще не проблема).

[neek666]

Меня беспокоит только две вещи:
1. В идеале создание БЕКАПА должно идти не затрагивая работу пользователей (не знаю на сколько это вообще возможно)
2. Надежность бекапа. Он должен восстановить 100% информации в базе, в 100% случаях (даже если база ломанная в момент создания бекапа, он должен ее восстановить ломанной, ничего не потеряв).

[Поиск родных]

Меня беспокоит только две вещи:
1. В идеале создание БЕКАПА должно идти не затрагивая работу пользователей (не знаю на сколько это вообще возможно)
2. Надежность бекапа. Он должен восстановить 100% информации в базе, в 100% случаях (даже если база ломанная в момент создания бекапа, он должен ее восстановить ломанной, ничего не потеряв)

Это в принципе невозможно!
Как Вы себе это представляете - начался бэкап, идущий пару часов, а после его начала пользователи понаизменяли кучу данных?!

Проверять надо проведением восстановления сделанной копии, до этого - рулетка на авось: "повезёт" или не пронесёт

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

И вряд ли это полностью автоматизируется