Бэкап SQL , что за фигня?

Дык чего в итоге? Полный бэкап + журнал будет оптимально?

А у меня же вроде и поставлено перезаписываться через 14 дней?

За 14 дней ваш Бэкапфайл разрастется (14 полных бекапов + логи), а так каждый день - новый файл.

Я бы выбрал его. Но если рост базы не ожидается и не потребуется преимуществ полной модели, то можно выбрать простую модель.

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

Кратко о разделении прав и ответственности:

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

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

Важно: "Админ данных" не может быть "Разработчиком" - это должны быть разные люди.

* "Разработчики" - работают в своей копии БД, которая периодически поднимается на сервере с рабочей БД. У нас на каждую рабочую БД было две тестовые базы для разработки. (одна для мелких доработок, другая для долгосрочных разработок). Все обновления ставятся сначала на тестовую БД и проверяются, если обновления существенные, то к тестовой базе подключаются и обычные пользователи и каждый департамент прогоняет полный цикл своих проводок или действий, после этого они отчитываются "Владельцу данных", что их кусок работает нормально(в отдельных случаях брались и бумажные подписи). После этого "Владелец данных" дает отмашку "Админу данных" на выставление обновления.

Важно: "Разработчики" имеют права только на чтение в рабочей БД, они не имеет права выполнять SQL запросы на обновление данных в рабочей БД. Если нужно изменить данные, то разраб. тестирует эти изменения в тестовой базе, потом отправляет заявку с вложенным SQL запросом(пачкой запросов), владелец подписывает, админ применяет на рабочей БД.

Важно: все манипуляции с данными проводить только штатными средствами, никаких SQL запросов или правок в гриде. Исключения - только за подписью владельца БД.

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

БД - только на аппаратных рейдах. Я еще застал несколько серверов-старичков на которых диски периодически выпадали из рейда или дохли, покупали новые(или выдергивали из соседнего сервера), меняли, фоновый ребилд и так до следующего раза. Потерь данных при таких операциях не было ни разу.

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

Я вам про одно, вы мне про другое, думаю вы не поняли мысль, которую я пытался вам донести.

Перечитайте цитату. Как ваше разделение полномочий помогло бы в данной ситуации?

1с не зависла бы во время обновления?

Но да, в целом с идеей разделения согласен. у нас доступ к обновлению тоже имеет только 2 человека.

И что, наличие рейда на 100% гарантирует сохранность БД ?

Я вот знаю одних ребят, они тоже считают, что с их дорогим ноутбуком (там БД в файловом варианте) ничего случится не может

И резервными копиями они не заморачиваются.

Подведем итог. admak, у вас в той фирме используется простая или полная модель восстановления?

---------- Добавлено 17.08.2017 в 07:54 ----------

У меня с вами разные взгляды на ситуацию.

Вы смотрите и думаете, что и как сделать, для сведения к минимуму форс-мажорных ситуаций.

Что конечно очень важно.

А я думаю как правильно настроить резервное копирование, что бы максимально быстро и просто восстановить работы БД, если форс-мажор всё-таки наступил.

И мне, как человеку который будет поднимать БД, не важно человеческий фактор (чей то косяк) привел к аварии или сбой в железе. Главное я восстановлю за 15-20 минут без потери данных.

Вот о чем я. И именно по этому я совету модель full.

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

Вот зависла у вас 1с на обновлении, откатили вы назад по логу. Упало "не важно почему", вы быстро восстановили по логу.

А вот теперь попробуйте доказать, что вы не слон и десяток кривых проводок(юзер/разработчик решил на вас списать свой косяк) это не результат обновления или зависания, т.е. ваш косяк. Самое неприятное, что баги могут начать появляться спустя несколько месяцев по нарастающей. Мне приходилось поднимать для разборов полетов и бекапы годовой давности.

Административно-технический подход:

1. Пишется заявка, на обновление, доработку, разработку нового функционала. Согласовывается ТЗ.

2. Владелец данных принимает решение нужно это или нет.

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

4. Разработчик/пользователи говорят, что все ок - тут наступает их ответсвенность. Владелец данных дает добро на продакт, согласовывается время установки и процедура.

5. Тут наступает ответственность админа

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

5.2 Делается полный бекап (у нас было несколько связных баз)

5.3 Ставится обновление, если повисло или есть малейшее подозрение на кривизну, то восстановление из полных бекапов и снова пункт 5.3

5.4 Если все ок, то снова полный бекап.

5.5 Пускаются в базу разработчики для быстрой проверки

5.6 Пускаются все остальные, отчитываемся что все ок.

6. Владелец данных подтверждает, что все ок

Сохраняем полные бекапы до/после установки в отдельную папку, туда же сохраняем и сами обновления, которые устанавливали. Это и есть наш спасательный круг и маркер для возможных разборов полетов. Можно будет в любой момент на тестовой базе поднять состояние базы до обновления, по новой накатить обновление, сравнить результат. Таким образом отсекаются попытки списать косяки друг на друга.

Рейд значительно повышает живучесть ос/сервера бд/и самой бд. Но ничего не вечно, видел у соседей и сдохший навороченный СХД и рассыпавшиеся рейды тоже. Поэтому бекапы рулят и не только БД, но и полностью всего сервера. Кстати, для одного тестирования поднимал копию всего сервера на обычном тазике, удивительно, но завелось все сразу и без танцев с бубном. :)

Это было давно... сейчас бы я все в виртуалки засунул бы и не парился бы с "особенностями и прибабахами" серверных железок.

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

После нескольких разборов полетов, это становится еще важнее, свои нервы нужно беречь, попутно берегутся и нервы окружающих. :)

Поспешайте медленно, но надежно. :) Возможно в случае только 1С такой подход будет работать, но все-равно лучше подстилать соломку в виде полного бекапа.

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

1. Принимается решение, что ситуация начинает выходить из-под контроля, оценивается время на ее гарантированное исправление.

2. Рабочие битые данные - в полный бекап, затем их в тестовую базу. Или переименовать БД.

3. На рабочей базе поднимается ночной бекап.

4. Продолжается текущая работа. По итогу это теже 15-20 минут.

5. В фоне штатными средствами экспорта/импорта или при помощи SQL возвращались "потерянные" данные. Мелочевка перебивалась руками, т.к. это оказывалось быстрее и проще.

ps: сколько букафф понаписывал, аж ностальгия взяла.