Коллеги,
работаем на файловой 8.2

Архивируем базу каждые полчаса с помощью Acronis.

Как конкретно поступать, если авария произошла через 28 минут после предыдущей архивации?

Спасибо.

задайте этот вопрос акрониксу

(0) [Как конкретно поступать, если авария произошла через 28 минут после предыдущей архивации? ]
грязно выругаться
и вбить руками последние 28 минут

Перевести на скулю не предлагать?

Конкретно на этот вопрос не нашел никакого ответа, кроме "вбивайте первичку ручками".

Мы не знаем, какие еще изменения, кроме распечатанных заказов, произошли в базе за это время.

(4) мы тем более

Спасибо. Восстановление SQL в случае такой аварии - совершенно четко описанная процедура?

(0) > авария произошла через 28 минут после предыдущей архивации?

в течение минуты после сбоя покинуть рабочее место без объяснения причин

to rbcvg: я понял. инструмента типа журналирования в файловой версии не существует?

to giallo: спасибо, этот способ уже работает. другие есть)?

(9) сейчас только (2), на будущее (3)

Спасибо,
стартовая настройка 1С+MSSQL на Windows 2012 сервер "под ключ" сколько стоит?

Именно установка/настройка, с доведением быстродействия до ума.


Порядки величин? У нас 15 пользователей, нагрузка низкая, до 200 документов в день, 5000 строк.

ДА, мы говорим о типовой конфигурации УТ11.1 и БП2.0

(4)[Мы не знаем, какие еще изменения, кроме распечатанных заказов, произошли в базе за это время.]
гордо напиши это на заборе

Чёрт, да понял я, что верный ответ - клиент-серверный вариант.
Спасибо.

(14) и чем он тебе поможет?

(6) "совершенно четко описанная процедура" - а вот и нет.
Если рухнула база, и не настроено зеркалирование, лог-шиппинг или очень частое дифференциальное копирование, SQL не поможет.

(11) при низкой активности и не перебить 28 минут рабочих - просто лентяи в конторе

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

Так...

Вернемся к началу - для файлового варианта ведь такого способа вообще нет?

А в случае SQL файл логов можно в реальном времени писать в на два физически разделенных сервера, ведь так?

(19) у тебя бабла не хватит на все это

Да, такой коммент я ожидал, но чуть ниже по ветке))

на старте бабла не жалко.

а вот дальнейшее обслуживание усложнять и удорожать не хочется без внятных обоснований

У файловой версии тоже есть логи - журнал работы, там мона посмотреть, какие примерно документы и объекты создавались/убивались/модифицировались...

"200 документов в день, 5000 строк" - вам в любом случае не помешает перейти на SQL.

(0)Принципиальной разницы между файловой и скуль базой в плане бэкапов нет.
Если для вас проблема вбить последние полчаса, значит бэкапы надо делать чаще.
В данном случае только вбивать руками.

(25) [Принципиальной разницы между файловой и скуль базой в плане бэкапов нет. ]
брехня
сиквел из бэкапа восстанавливается на произвольный момент

ТС или туп или троль.

В общем я бы на вашем месте сделал так - бэкап базы каждые 15 минут с помощью теневого копирования, плюс на ответственные документы в модуль проведения дописать процедуру запуска бэкапа.
Т.е набили серьезный документ, типа поступления или отгрузки товаров, после проведения сразу же создалась теневая копия базы.

Если туп будет постов до 100 .Если тролль срачь до 1000

*если грамотный троль:-)Эт по нынешним временам редкость

(26)Да ну, прямо таки на произвольный?
Допустим бэкап создан в 12.00, база упала в 12.25.
Объясни пожалуйста как скуль сможет восстановить базу на нужный момент, т.е на 12.25 ?

(31) Sql.ru

+(27)Кстайе читайте краткое содержание предыдущих глав:-)
v8: 8.2, защита данных - физический сервер, виртуализация и тонкий клиент

*Кстати

(31) ну если жив файл лога  - с него можно сделать бэкап и
восстановить

(0) сделайте распределенку и сливайте в копию данные с частотой 4 минуты

to Jump: спасибо.

Теневую копию теми же средствами, что и сейчас - Acronis?

to Конфигуратор 1С: спасибо.

создать распределенную БД средствами 1С, так?

to Рэйв: спасибо.

(37)Без разницы.
Я лично акронис не использую, в windows теневое копирование встроено, и доступно из командной строки.
Если база лежит на достаточно быстром диске, и теневые копии делаются на другой диск, то тормозов не наблюдается даже при очень частом копировании.

Да, я понял, подходит даже теневое копирование Windows. Мы разместили базы на SSD, сейчас все быстро.

(31) Если грамотно настроено, то и на 12.25 можно.
Последний полный, последний диф, и бэкап журнала транзакций.
http://www.sql.ru/articles/mssql/01080303howbackuplasttransactionlogwhenmasteranddatabasefilesdamaged.shtml
Бэкапы журнала транзакция делаются пожалуй быстрее чем теневые копии.

последовательный накат логов журнала транзакций конечно же еще после последнего дифа, пропустил.

(32) Как ты это сделаешь, если умерли mdf и ldf? А архивы, например, раз в 15 минут.
(40) Предлагаешь делать бэкап журнала транзакций каждую минуту?
Т.е. раз в минуту SQL будет сохранять все транзакции с момента последнего полного бэкапа. Сервер не перенапряжется?

(0) я сомневаюсь что вы деалете резервную копию в файловом варианте каждые 30 мин. Для резервной копии в файловом варианте нужно скопировать каталог в монопольном доступе.

(42) Имхо, при озвученных объемах какой-нибудь простой лог-шиппинг вполне будет работать каждые 5 минут.

(42) на этот случай можно использовать зеркалирование

(0) делайте бэкап каждые 27 минут

(43) копировать папку с базой можно в работе, он тебе DT не даст сделать если монополии не будет.

(0) да это бред полный, каждые 30 минут делать бэкап, проще сделать сервер надёжнее

+ (48) вообще если сгорит сервер в пожаре, что вы тогда будете делать?

(43)Фигня, не нужен монопольный доступ, файл может быть спокойно открыт на запись.
Просто делаешь снимок, и спокойно копируешь его куда тебе надо.

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

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

(51) Почему нельзя восстановить базу после создания бэкапа при помощи лог-файла?

(49) Для этого есть резервный сервер в отдельном помещении + ежедневные бэкапы на файл сервер в другом здании :)

(54) а если ещё и другое здание сгорит, что тогда делать?))

(51) бред

(52)Между двумя бэкапами есть, не спорю.
(56)Поясни.

(50) можно и базу скопировать с работающими пользователями и она открываться будет, одноко в документации сказано нужен монопольный доступ

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

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

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

P.S. но, мне кажется, что настройка и резервирование SQL-сервера окажутся намного проще в реализации.