Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

Бекапы 1С. Модель восстановления Полная VS Простая?

Бекапы 1С. Модель восстановления Полная VS Простая?
Я
   Обработка
 
22.04.21 - 05:48
3. Все зависит от ситуации.50% (1)
4. Свой вариант.50% (1)
1. Полный всегда лучше!0% (0)
2. Простой всегда лучше!0% (0)
Всего мнений: 2

На днях мы обсуждали про периодичность бекапов 1С баз вот тема:
У кого какая периодичность бекапа для больших и критичных баз?

Когда я поднял вопрос у своего ИТ начальника почему у нас не "полная" а "простая" модель восстановления?
Ответ (аргументы) был такой.
1. При полной  - логи растут очень быстро и всю память занимают.
2. Опытные админы  sql и и опытные 1С-ники ему советовали при больших база такой режим лучше.

Как я раньше озвучивал у меня базы одна 100 ГБ другая 250 ГБ. Есть еще куча разных баз на других серверах объемом меньше.
Все на разных серверах.

Какие у вас на этот счет мысли доводы и контраргументы?
Кстати в другой фирме другой мой ИТ начальник лет 10-15 назад твердил наоборот другое что не стоит делать простой.
   Обработка
 
1 - 22.04.21 - 05:54
Конечно тут главный аргумент риск потеря данных при восстановлении против свободного места на диске и управлением этим.
Но хотел бы услышать что у вас на практике. Какие случаи бывали? Помогло ли спасти базу тот или иной режим?
   Обработка
 
2 - 22.04.21 - 05:56
И еще вопрос. Модель - "с неполным протоколированием" для 1С используется или нет?
Никогда не юзал этот режим.
   Paint_NET
 
3 - 22.04.21 - 06:05
Использую простую, т.к. в (0) правильно сказано - логи разрастаются сильно, а мне не нужен инкрементный бэкап, достаточно дифференциального. Других преимуществ, кроме возможности инкрементного бэкапа, у полной модели я не знаю.
   Paint_NET
 
4 - 22.04.21 - 06:07
+(3) Т.е. применительно к базам 1С преимуществ не знаю. В других случаях, когда, например, нужно зеркалировать БД, без полной модели не обойтись.
   Обработка
 
5 - 22.04.21 - 06:13
(4) Как и 99% всех случаев с 1С мне нужно лишь хранить базу на случай восстановления и для создании копий по необходимости.
   ADirks
 
6 - 22.04.21 - 06:15
(0) Про бэкапы есть хорошая статья от speshuric'а: http://infostart.ru/public/173494/
там всё расписано.
Всё зависит от конкретных условий, так что решать вам, как обычно :)
   Обработка
 
7 - 22.04.21 - 06:17
Процесс бекапа во время работы юзеров ведь не сильно влияет на скорость работы базы для юзеров.
Я к тому что при дифференциальном ведь идет накопителя с момента полного бекапа, а лог-бекап делает только разностный тем самым это быстрее и не занимает (не загружает) особо базу.
   Paint_NET
 
8 - 22.04.21 - 06:21
(7) Ну тут как посмотреть. Я просадок при диффе не замечал ни разу, но у нас конфигурация серверов заточена на быструю дисковую подсистему. С другой стороны, постоянное логирование тоже занимает ресурсы так или иначе. В таких условиях свободное место ценнее иллюзорных преимуществ, т.к. SSD не резиновые и слишком дороги, чтобы наращивать по каждому чиху :)
   Обработка
 
9 - 22.04.21 - 06:26
(6) Спасибо бегло прочитал.  Там в общем понятие про различные варианты бекапов. А вот пристальное глубокое сравнение  модели восстановления нет.
Просто пример, который и так всем известен.
   ADirks
 
10 - 22.04.21 - 06:47
(8) Логирование в любом случае занимает ресурсы сервера, при любой модели восстановления.
При full recovery скорее "административный" ресурс нагружается, т.к. надо постоянно следить за своевременным выполнением бэкапов и всяких регламентов. Но иногда это просто неизбежно.
   Йохохо
 
11 - 22.04.21 - 07:28
(10) в симпл если административный ресурс прослакал - всё потеряно, лог провернулся, только новый полный. в фул просто вырос лог
   Почему 1С
 
12 - 22.04.21 - 08:26
Если делать бэкапы логов транзакций не растет сильно, а после его обслуживания у нас раз в месяц и вовсе маленьким становится.
А решать simple или full модель, исключительно от необходимости восстановления базы на конкретное время.
Для себя определяюсь так - полные копии и разностные делать только вне рабочего времени, далее если нужна возможность восстановится внутри рабочего времени то full и бэкапы логов, иначе simple.
   ptiz
 
13 - 22.04.21 - 09:05
(0) "логи растут очень быстро и всю память занимают." - если настроить всего 1 задание (бэкап лога), ничего никуда не растёт.
   Обработка
 
14 - 22.04.21 - 09:30
(13) Бакапы и периодичность бекапов ни как не влияет на размер лог файла.
   mistеr
 
15 - 22.04.21 - 09:40
(14) При полной модели влияют.
   mistеr
 
16 - 22.04.21 - 09:42
(0) Место на дисках сейчас дешевое. Аргумента в пользу простой модели вижу только два.

1. Недостаточно мощный сервер, бэкап в рабочее время мешает пользователям.
2. Нет квалифицированного админа, некому следить за бэкапами.
   Paint_NET
 
17 - 22.04.21 - 10:08
(0) Это на каких дисках место дешёвое? SSD терабайтный enterprise класса стоит за килобакс нередко, они обычно в рейде, что в случае с зеркалом удорожает место вдвое. А базы типа ERP растут как на дрожжах, за пару лет полтерабайта.
   SSSSS_AAAAA
 
18 - 22.04.21 - 10:11
(17) Место дешевое на HDD, куда нормальные админы и делают бэкапы.
   ptiz
 
19 - 22.04.21 - 10:26
(14) BACKUP LOG (в отличие от BACKUP DATABASE) как раз позволяет удалить старые записи в логе.
   Йохохо
 
20 - 22.04.21 - 10:34
(14) для логов достаточно использовать классику хдд, которая копеешная, запись в один поток за 300 мбс более чем
еще можно подумать что будет при обновлении базы в модели симпл, или просто при реструктуризации. будет оба на)
   Почему 1С
 
21 - 22.04.21 - 10:38
(20) Ничего страшного не будет, такие вот массовые изменения как раз таки в модели FULL не желательны.
   ptiz
 
22 - 22.04.21 - 10:49
(21) Да нет разницы при записи в базу при любом режиме. Только место под логи требуется.
   Dmitrii
 
23 - 22.04.21 - 11:09
(0) Ерунда какая-то.
Продуктивные базы должны быть всегда только в полной модели работать. И никак иначе.
Базы для разработки, тестирования или развёрнутые копии за прошлые (неактуальные) периоды - в зависимости от конкретных обстоятельств.

Аргументы про дисковое пространство звучат так же смешно, как использование SMS вместо WhatsApp или Telegram из-за дороговизны мобильного интернета.

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

4. Свой вариант.
   ADirks
 
24 - 22.04.21 - 11:13
(23) Отсутствие грамотных админов - очень веский аргумент :))
   Lama12
 
25 - 22.04.21 - 11:35
(0) Судя по прошлой ветке у тебя есть резервные копии с дискретностью в час. Зачем делать полную модель, если бизнес устраивает потеря данных за час работы? Если не устраивает, то лучше полную модель. Бэкапы замучаешься делать чаще.
   Обработка
 
26 - 22.04.21 - 12:04
(25) Так вот я хочу разобраться это идеальный вариант или что-то мы упустили.
Зачастую Бизнес и не знает что есть выбор. И вообще может и про бекапы не обсуждали досконально.
Или ИТ отдел поставил перед фактом что так и будет и все.
Бекапы не я же ручкам буду делать а сервер сам по расписанию...
   VKS
 
27 - 22.04.21 - 12:14
Если можете с этим работать и данные важны чуть ли не последние 5 минут, то полная. Если не можете (логи там у вас растут, места не хватает, восстановить не получается) или данные за сутки не важны, то простая

3. Все зависит от ситуации.
   dmpl
 
28 - 22.04.21 - 12:22
(17) За пару лет там программистам тысяч 200 баксов заплатят. Что на этом фоне пара килобаксов?
   Обработка
 
29 - 23.04.21 - 09:23
Еще есть кому насыпать тут семечек?
   Вафель
 
30 - 23.04.21 - 10:31
Если достаточно раз в сутки то простая модель вполне сойдет
 
 Рекламное место пустует
   timurhv
 
31 - 23.04.21 - 11:25
(0) Реорганизация\перестроение индексов на стороне SQL?
Перепишите на скрипт, он будет обслуживать только нужные таблицы, лог не будет разбухать после обслуживания, соответственно бэкапы тоже будут занимать меньше места.
Но если потребуется обработать большую таблицу, то он может резко вырасти, например:
1 день бэкап лога 10Гб
2 день бэкап лога 10Гб
3 день бэкап лога 70Гб

А при стандартной реорганизации\перестроении будет:
1 день бэкап лога 110Гб
2 день бэкап лога 110Гб
3 день бэкап лога 110Гб


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.