Бакап восстанавливается довольно долго до нескольких часов вряд ли бизнес будет ждать так долго. Элементарно куда вбивать заказы в это время?

Расскажите ваш опыт.

База 200Гигов + MS SQL 2005 SP4

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

(22) да это и есть лог шиппинг или доставка логов, читал об этом но практики нет

сейчас модель записи логов симпл

(24) Не гоже имея 200-гиговую базу не знать про разностные и бекапы лога транзакций.

(25)(27) да, пробелы надо закрывать
если есть хорошие ссылки на статьи сообщите, спасибо

(0) 10 рейд из 8 ssd дисков. Восстановление БД (50 ГБ) занимает чуть более 1 минуты. На корзине из sas дисков эта же база восстанавливается не более 5 минут. Смотри свой массив дисковый :)

(0) 200 ГБ несколько часов?:) Меняй оборудование. 192 ГБ из ближайших ко мне баз - 20 минут.

(28) http://www.ozon.ru/context/detail/id/5767915/

три задания
лог часто
разностная реже
полная 1 раз в сутки
хранить там же чтобы не тащить несколько часов по сети
а в сеть класть чтобы мало ли что и осталось
можно ещё сжатие чек и прочее по мелочи добавить

Копирование UPP Log

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\FULL\UPP\UPP_backup_log ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak'
select @n = rtrim(@n)
BACKUP LOG [UPP] TO  DISK = @n
GO

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\\FULL\ACC\ACC_backup_log ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak'
select @n = rtrim(@n)
BACKUP LOG [ACC] TO  DISK = @n
GO

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\FULL\SunLightAcc\SunLightAcc_backup_log ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak'
select @n = rtrim(@n)
BACKUP LOG [SunLightAcc] TO  DISK = @n
GO

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\FULL\SunLightRetail\SunLightRetail_backup_log ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak'
select @n = rtrim(@n)
BACKUP  LOG [SunLightRetail] TO  DISK = @n
GO



--Копирование разностное

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\FULL\UPP\UPP_backup_diff ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak'
select @n = rtrim(@n)
BACKUP DATABASE [UPP] TO  DISK = @n WITH  DIFFERENTIAL
GO

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\\FULL\ACC\ACC_backup_diff ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak'
select @n = rtrim(@n)
BACKUP DATABASE [ACC] TO  DISK = @n WITH  DIFFERENTIAL
GO

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\FULL\SunLightAcc\SunLightAcc_backup_diff ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak'
select @n = rtrim(@n)
BACKUP DATABASE [SunLightAcc] TO  DISK = @n WITH  DIFFERENTIAL
GO

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\FULL\SunLightRetail\SunLightRetail_backup__diff ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak'
select @n = rtrim(@n)
BACKUP DATABASE [SunLightRetail] TO  DISK = @n WITH  DIFFERENTIAL
GO

DBCC FREEPROCCACHE
go

-- полное


use [UPP]
go

--sp_msforeachtable N'DBCC INDEXDEFRAG (upp_prog1, ''?'')'
sp_msforeachtable N'DBCC DBREINDEX (''?'')'
go

exec sp_msforeachtable 'UPDATE STATISTICS ? WITH FULLSCAN'
go

DBCC SHRINKDATABASE(N'UPP' )
GO

DBCC SHRINKFILE (N'UPP' , 0, TRUNCATEONLY)
GO
--------------------------------------------------------------------------------------------------------------------------
use [ACC]
go

--sp_msforeachtable N'DBCC INDEXDEFRAG (upp_prog1, ''?'')'
sp_msforeachtable N'DBCC DBREINDEX (''?'')'
go

exec sp_msforeachtable 'UPDATE STATISTICS ? WITH FULLSCAN'
go

DBCC SHRINKDATABASE(N'ACC' )
GO

DBCC SHRINKFILE (N'ACC' , 0, TRUNCATEONLY)
GO
--------------------------------------------------------------------------------------------------------------------------
DBCC FREEPROCCACHE
go

---------------------------------------------------------------------------------------------------------------------------------

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\FULL\UPP\UPP_backup_FULL ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak'
select @n = rtrim(@n)
BACKUP DATABASE [UPP] TO  DISK = @n
GO

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\\FULL\ACC\ACC_backup_FULL ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak'
select @n = rtrim(@n)
BACKUP DATABASE [ACC] TO  DISK = @n
GO

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\FULL\SunLightAcc\SunLightAcc_backup_FULL ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak'
select @n = rtrim(@n)
BACKUP DATABASE [SunLightAcc] TO  DISK = @n
GO

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\FULL\SunLightRetail\SunLightRetail_backup_FULL ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak'
select @n = rtrim(@n)
BACKUP DATABASE [SunLightRetail] TO  DISK = @n
GO
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
xp_cmdshell 'del G:\AVTOBACKUP\*log*.* /q /s'
go
xp_cmdshell 'del G:\AVTOBACKUP\*diff*.* /q /s'
go

удаление спецом не писал чтобы удаляя ручками удостовериваться тому что копии делаются

(32)+ "DBCC FREEPROCCACHE" - а он есть в случае 1с?:)

(9)(22)"А вот такая фигня требует тщательного расследования"
+100500
думайте пока база не развалилась
причем что хуже всего развалиться она может задолго до того как учетчики поднимут тревогу по причине того что поплывут данные

(34)на самом деле кешей ещё больше
только рекомендаций нет для их чистки
а этот реально есть и реально глючит при изменении базы

Я за зеркалирование баз данных на MS SQL.
В другой сервеной комнате, в другом здании.
Туда же продублировать терминальники.

Без магии ни куда :)

я понял. автор в .dt бэкапит

(39)Хм... похожу так оно и есть :)

(39) нет, не в dt

(41)не знаешь что такое дт? )))

(41) у нас база 500 гиг восстанавливается 30 минут средствами скуля. а вот с .dt - да, несколько часов.

(37)если не допустима потеря даже 15 минут тогда да конечно

(42) а логи которые ты бакапишь, ты их где-то восстанвливаешь на копии? или как? как они помогут ускорить восстановление из бакапа?

(42) можешь рассказть методику аварийного восстанволения по твоей методе резервного копирования (не в виде скрипта, а просто словами).

(0) даунтайм в офисах у работников 1Сне снижается.. как правило даунтайм у них 7/24/365

Не понимаю обсуждения развертывания бекапа на тот же SQL сервер.

Думаю стоит обсудить ситуации:
- потеря нескольких дисков массива
- выход из строя RAID контроллера
- отказ SQL сервера

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

(48)копия делается сразу быстро туда же
а потом в фоне тащи куда хочешь на случай форсмажора железа
(45)(46)
http://msdn.microsoft.com/ru-ru/library/ms189275(v=SQL.90).aspx

http://msdn.microsoft.com/ru-ru/library/ms179314(v=sql.90).aspx

(49) может, тем, кто "умеют только делать бакап рестор в MsSQL ну и детач аттач." - сходить поучиться, или как минимум почитать вполне доступную документацию, книжки?

(46)произошел сбой
пытешся забекапить лог в добавок к цепочке ранее сделанного копирования
потом не важно вышло или нет забекапить лог
восстанавливашь базу из цепочки
всё

(52) я тоже так считаю... хотя если придираться, то MSSQL DB Admin это отдельная вакуха и тоже от 100 тыр

к (53) реально попыток забекапить лог после аварии не пришлось делать
а вот восстановление из цепочки в другую базу проходило успешно

(49) Эта тема в интернетах освещена уже 100500 раз. Надо читать книжки от издательства Мелкософта. Ну и msdn никто не отменял.

(55) ну да тестовые учения надо проводить это тоже важно, бакапы то могут и не восстановиться

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

(57)точно, особенно дт )))
(56)только вменяемых скриптов для фулл не так уж и часто нарыть можно
мне например по материалам инета самому писать пришлось

(58) у вас в санлайт модель симпл?

(60)санлайт это случайным образом сгенеренное имя для примера
там где это использовалось модель стала фулл

(0) Резервный сервер в другом здании

(62) зеркальный mssql?

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

Не 1С, но..

1. кластеризация сервера БД.
2. Файлы баз данных на отдельном СХД в 10 рейде на SAS винтах enterprise класса.
3. Ежедневный бэкап на отдельное железо
4. Постоянный мониторинг производительности всех компонентов.

(0) "Постоянный мониторинг производительности всех компонентов." Ну уж:)...

(66) Что не так ?

всякие "заркалирования" не спасаю когда у буха открыта массовая обработка и слышишь вдруг "оймля!"

Переходите на 2008 скуль
Архивы можно сжимать средствами самого скуля + существенный выигрыш по времени на сжатие и восстановление.

(68)+ а ведь бухи иногда и на ночь обработки оставляют

(67) Постоянный мониторинг - избыточно, имхо. По расписанию.

2 разных железных сервера SQL - с распределенной базой. Обмен каждые 10 минут в обе стороны.
2 разных железных сервера предприятия
2 терминала

время простоя за почти 1,5 года было пару раз минут по 10 - когда мне все позвонили и уточнили, надо ли уходить на вторую линию. Все просто и работает. База 40 гиг УПП пользователей более 45 в базе не бывает.

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

сейчас рассматриваю вопрос размещения "теневой" копии для бекапа в облаке. чтоб даже пожар не мог помешать нашим планам порабощения мира...

+(0) в лога SQL было такое

01/12/2013 01:04:17,spid53,Unknown,SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0x7dcf9c24; actual: 0x7dcf1c24). It occurred during a read of page (1:28792043) in database ID 5 at offset 0x000036ea9d6000 in file 'C:\sql_data\MyBase.mdf'.  Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information<c/> see SQL Server Books Online.

(74) Как красиво компетентные органы изымут оттуда теневую копию...

(76) админ-обортень быстрее спионерит данные

(76) да пусть два раза в день вынимают. все пушисто.

(77) Тоже верно
(78) пушисто... пушисто-то оно пушисто, а список контрагентов, а договоры, а цены, а скидки, а клиенты?

(79) чаще всего в туалете на подоконники расчетные листочки с зарплатами лежат. а не через Компетентные органы утечка случается. У нас 50 торговых представителей с КПК бегают по 3 областям - там у них у клиенты и цены и скидки и договоры. Каналов утечки информации, более вероятных к использованию, гораздо больше.

(79) у Вас кстати сайт за неуплату остановили. совсем наверное плохи дела финансовые.

(80) На месте твоего работодателя, я бы тебя уволил за такой образ мыслей в отношении политики безопасности

(82) Да нет у меня работодателя. Уволили уже. Давно. 1.5 года назад.

(81) С ходу переход на личности?:)...Я не понял такого сильного аргумента.

(82) ну а если предметно - выколоть глаза торговым представителям? У них там помимо всего, что перечислил (79) есть более важная инфа - сверки, долги, объемы и т.д.

(84) да не ничего личного, не огорчайся, если задел.

(82) Я ведь не против безопасности, но только от реальности не надо отходить - а то ворота с охранником будут, а забора не будет. Речь идет о простоях и безотказности - я привел свой вариант.

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

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

(88) видимо, у Вас нет торгашей с кпк. Я, конечно не разработчик сей системы, но вощникает логичный вопрос: ну как он наберет заказ без КЛИЕНТА, без СУММЫ заказа, без отчетов по долгам всевозможных, без отчетов по отгрузкам, истории заказов, возвратов и т.д.?

(85) Не об этом речь. А о том что если уж думать о защите информации, то думать масштабно, по всему периметру. А не так что "А, если конкуренты захотят, то и через ТП всё узнают, поэтому и сервак с БД нет надобности защищать. Чё париться-то?"
Я лично такую философию в (80) увидел.

(88) +1

100+ баз в десятки и сотни гигов, десятки серверов, 7 лет с 1С. Ни разу не приходилось поднимать для работы основную промышленно используемую рабочую базу из бекапа. Что за железо используете, что у вас валится железо боевых SQL серверов?
Да и про какие "несколько часов" для базы в 200 гигов говорится? Дисковый массив из 2х дисков SATA 7.2к 250Гб на софтрейде у вас что ли?
Со стримера такое счастие поднимается едва ли за полчаса.

Для отказоустойчивости и надежности используем ежедневный бекап на стримеры в другом здании + RAID массив.

(90) :):):) "Без отчетов по долгам всевозможных, без отчетов по отгрузкам, истории заказов, возвратов и т.д.?"... Мда. У нас в качестве торговых агентов - таджики. Хватает как-то.

(90) Отчёты, истории, возвраты и прочее, ЧТО БЫЛО - нафиг не надо ТП на кпк. Нужна только номенклатура и её цена.

(95)однажды один архитектор с опытом в крупных британских компаниях ощутил что стример не лепится на юсб под варей )))

к (95) и так и бросили этот стример валяться пылиться )))

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

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

(97) Это у тебя супервайзер тогда получается

(98) Все как один - без. Они только цифры понимают, а как продукцию идентифицируют - вообще непонятно. Но не ошибаются.
(99) Вот-вот, только хотел написать...

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

(100) Про Региональных менеджеров, которые "начальники" супервайзеров писАть?

(100) а сколько у Вас таких?

(103) Да человек 100, приб.

(104) а суперов сколько для этих 100? Они русские?

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

(106) Мы тут вроде как не логику системы разрабатываем.
Ссуть в том, что вовсе не обязательно ТП иметь на КПК отчётные данные.

(107) да облачные технологии и КПК - это вообще изобретение рейдеров. И данные для минимизации даунтайма не надо ни в коем случае на второй сервак копировать - вдруг украдут. За одним то проще углядеть.

(0) хм - чем бэкапишь то? А вообще, имхо - восстанавливать бэкапы надо в пустую базу.

закладка

+(109) соответственно, все фоновые задания и т.п. на сервере предприятия при этом стопорить надо.

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

(107) отчетные - не нужно
учетные (клиенты, цены) - нужно
другое дело, что как минимум можно не всех клиентов грузить всем ТП

(112) Тут все в кучу смешали. Отказоустойчивость и бекапы. Ну ну.

(114) сверился с темой ветки - я в тренде! я вообще про бекапы ничего не знаю...

(113) это точно. У меня по 100 клиентов на ТП примерно. Максимум - 118. Грузится быстро, да и лишние не нужны.

(116) вообще-то, это азбука - иметь только те данные, которые необходимы (товары в пределах матрицы, цены в пределах доступных). Плюс  еще - при загрузке от "утерянного" КПК - тереть базу. Можно вообще актуализировать только тек клиентов, которые в сегодняшнем плане посещений.

(112) ждёмс

(117) к этому стремимся. Уперлись в маршрутные листы, чтоб только по ним на "сегодня" выгружать 20 клиентов и все. Но там чисто организационные проблемы.
(118) да ищу я.

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

модель фулл тормозит работу базы, что является ее оборотной стороной медали

(120) если у вас фул тормозит работу базы то это указывает на узкое место в оборудовании.

(121) еще вопрос есть, если мы хотим воспользоваться нашим хитрым бакапом логов и откатиться на заданную точку, то где гарантия, что в заданной точке данные 1С согласуются между собой?

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

(122) по поставляется "как есть", накат лога до заданной точки - штатная процедра

Все не читал ибо лень.
(0) Тебя спасет логшиппинг. Правда он тоже не защищает от потери последних транзакций.