Есть база Торговля в 8.2 sql. Сейчас стоит FULL. Делал шринк лога, при фулл не получилось. Перевел в Симпл, сработало
Могу оставить ее в этом режиме? Или каждый раз прыгать туда - сюда?
У кого как стоит и что посоветуете?

Планы обслуживания изучи и будет - счастье

Если для восстанавления базы достаточно суточных файлов dt, то simple, а если надо восстановить на нужный момент времени средствами SQL - то FULL.

Бэкапы ночью и в обед

если не знаешь, зачем тебе full - делай simple

(0) Нет, по правилам надо спросить сторону бизнеса, какая частота бэкапов его устраивает.

(3)Круто :)
А зачем так насиловать технику?
Сколько раз вам понабилось восстанавливать БД?
Какой именно Бекап был использован, Вчерашний, или который пол час назад? :)

+ А оно раз в неделю на выходных, и усе

(4) Можно я это распечатаю и в рамочку повешу?

За всю свою практику с 1с ни разу не потребовалось восстанавливать базу средствами скл.

Фулл только жрет место на диске и ресурсы добавляя тормоза.

лет 5 уже как при создании скл базы новой, всегда ставлю симпл

(6) еще не разу не понадобилось за почти год который я тут работаю. Железо не особо напрягается. Но это не повод делать бекапы реже

На моей практике фулл раз 5 помогал

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

(12) можно поподробнее?

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

Вот у нас тоже стоит FULL. Но вот непонятно, спецов по SQL у нас нет, если навернеться, то фиг кто восстановит.
Но при этом страшно ставить Simple.
Пы.Сы. Бэкапы каждый день делаем

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

(11)Не знаю, не знаю... при админских бекапах, по среди рабочего дня, все курят отдыхают :)

(17) Хорошо сказал.

(17)Да хоть Сам Путин!!! Ты тут не бабы Маши из бухгалтерии :)

>>> Ты тут не бабы Маши из бухгалтерии
Ты тут не главнее бабы Маши из бухгалтерии

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

сейчас есть возможность восстановить на каждый час.

(8) давай!

(17)>>> во сколько это обойдется
Тебе, если же бекапы не помогут, обойдется все лишь сменой работы. И н-ой суммой денег самой конторе, для восстановления информации :)

(16) а спецы по поиску в интернете у вас есть?

(0) Я бы сказал что это зависит от степени пофигизма одинэсника. В случае потери базы бухам можно всё что угодно навешать на уши. Настроены бэкапы каждый час. Полный раз в несколько дней и диффы через каждый час (не знаю можно ли так настроить в симпл). Такая схема выручала и экономила время бухам и мне очень много раз. Ну например ктонить перепроведёт чёнить в заднем периоде и т.д.

(14) Пример:
Неопытный прог зачистил регистр сведений значения свойств объектов (отбор не установил) на живой базе. Полняли копию базы - оттуда перенесли набор записей.

(22)Тогда ваш, путь FULL

(24) Естественно, каждый должен отвечать за свою работу.

+(22)>>>сейчас есть возможность восстановить на каждый час.

Как правило, ошибки ловят уже спустя полгода :)
А фатальные ошибки только от жадности руководства.

(25) Есть :)
Но чтобы нормальных найти тоже время надо. А когда все накроется и все будут бегать и орать, даже незнаю что лучше.

Если надо перед какой-то групповухой (проведение, а не секс!) обязательно сделать бэкап - то через FULL это делать кошернее, по крайней мере - чем чаще фулл-бэкап  - тем он быстрее.

(31) Тут надо точно угадать момент и уволится ДО того, как всё накроется :)

(33) Люди с таким чутьем одинэсниками не работают :)

(33)Это тоже просто, новые сервера сами тебе говорят, что винт, сейчас упадет.
А железо и по виду видно, что да как.
...
Остается только деньги клянчить на новое железо, либо линять, плавномерно :)

1. раз в сутки фулл
2. каждые 4 часа дифф
3. каждый час лог журнала

(30) кроме ошибок есть еще много всего прочего. сама 1с способна вывести свою базу из строя.

а есть кто то кто ставит full?

(27) и почему этого нельзя сделать на симпл?

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

(26) Можно. У меня как раз Simple. Ночью полный бэкап, днем каждый час дифф.

(34)Ответь лучше:
1. Ты какую БД, будешь бекапить, Бухию, торговлю, еще что?
2. Какой функционал данная БД несет, как часто она нужна, и как долго в неё набить информацию с бумажных насителей, из архива?
3. Какой железо у вас?
4. Какая сеть у вас?
5. Как сильно загружены сервера в пик работы?
6. Методом тыка ставишь Simple, и делаешь полные бекапы, к примеру "Symantec Backup Exec". И наблюдаешь за лесными отзывами, что да как.
7. У нас круглосуточно работают, по этому бекап только ночью, либо по выходным :)
8. Миста не последняя инстанция по поводу администрирования :)

(37) В любой мало-мальски крупной конторе встречал только FULL.

(40)+ Но база таки неболшая, около 10 Gb.

(42) админинят скуль серваки студенты? :)
богатые наверно конторы

(43)У нас 20-Гб, и рост продолжается.
Но и это Мало, вот когда будет под 60-Гб, тогда буду говорить большая ;)

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

(0) При модели ФУЛЛ шринк на ура делается.

(41)
6. Методом тыка ставишь Simple, и делаешь полные бекапы, к примеру "Symantec Backup Exec". И наблюдаешь за лесными отзывами, что да как. - Штатно скулем. ФУЛЛ каждый час. Отзывов нет.
7. У нас круглосуточно работают, по этому бекап только ночью, либо по выходным :) - Да вы отчаянные. :)

Ставлю симпл, ибо нефиг

Если нет разностного бэкапа то FULL тока ресурсы лишние жрет.

(45) 20 гб?
мммм....
документооборот вообще есть, то?

(16) Вот у многих ложное понимание, что FULL более отказоустойчив, чем SIMPLE. На самом деле, FULL всего лишь дает ВОЗМОЖНОСТЬ архивации журнала транзакций, что опять таки дает возможность быстро бэкапить состояние базы, записывая лишь изменения. Хоть каждые 5 минут. Но это именно ВОЗМОЖНОСТЬ, которую админ должен РЕАЛИЗОВАТЬ!

Если это не надо - тогда и незачем включать режим FULL.

(51) тут 99% не поймет того, что ты написал..
зря старался

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

(34)
1. УПП
2. Всё что заложено в УПП. Мне УПП низачем не нужна, зато УПП нужна всем остальным сотрудникам и они решили что 4 часа простоя в случае падения их устроит. Данное решение запротоколировано специальной бумажкой. Чтобы выполнить их решение, я включил FULL, закупил ресурсы для бэкапа, запасной сервер, регулярно провожу тренировки по восстановлению системы.
3. Остальные вопросы не в тему

(51)Ага, еще все забыли, как активно ведется работа в БД?
Если поставишь FULL, то может быть так, что все пространство на сервере займет твой файл логов :)

(44) Да нет. Не угадал. Нормальные спецы админят.

(51) дифференциальные бэкапы можно делать и при симпл

+(51)Ах да, ты конечно понимаешь, что в режиме FULL, у тебя должны быть вообще все бекапики без исключения, включая и самый первый бекап :)

(57) поподробнее

А вообще присоединюсь к (4). Очень правильно сказано.

(57) Но не каждые 5 минут, всё-таки дифф ресурсоемкая процедура

(56) у меня за последнии 5лет мелких контор не было (от 500 человек) и баз менее 100Гб тоже...
что ты понимаешь под крупными конторами и
читал ли ты внимательно (53) ?

(55)При бэкапе логов транзакций режется этот самый лог. Так что не надо нам тут.

перевел в Simple только что, молитесь за меня

(59) какое слово расшифровать?

(60) не прошло и 10 лет

(63) Имеется в виду, когда стоит фулл, а лог не бэкапится, потому что никому это не надо)

(62) Читал. И могу тебе сказать, что везде модель FULL выбиралась вполне осознанно и обоснованно. А тебе читать (4) до полного просветления.

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

Может пользователей устроит потеря данны за последнюю неделю...

(65) какой командой?
или ему каждый раз надо подсовывать предыдущий бэкап для анализа различий?
Скорость такого бэкапа? по сравнению с FULL моделью

(68) я (4) писал 5 лет назад здесь же...
так что сынок, не надо мне рассказывать про настройки сервака, ибо админством я занимался до 1С, больше 10 лет назад

(58) я не понимаю. зачем нужны вообще все бекапики без исключения?

(72)Тогда ваш путь  Simple, и полный бекап с большим интервалом :)

Иногда возможность восстановить базы "до секунды" позволяет выявить причины "глюков 1С".

+(72)Ты когда-нибудь игрался с виртуальными ПК?
Там есть такой термин "Снеп-Шот", так вот это примерно тоже самое (все бекапики).

(71) Ах да. Ты видимо единственный спец по скулю в мире. Если твои конторы устраивала модель симпл, то это не значит, что так везде.

(73) Не нужен "самый первый". Нужен бэкап базы и цепочка (неразрывная!) бэкапов журнала транзакций с этого момента.

+(75)Для примера https://www.virtualbox.org/

(77)"самый первый" и "Нужен бэкап базы"
Считай, что это один и тот же термин :)

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

(75) всегда должен быть последний полный бекап. все остальные, кто сколько времени хочет столько и хранит.

+(80) тут проблема в том, что админы даже не задаются вопросом: "а надо ли ?"

(82) Пока диск не забивается журналом транзакций)

1) Ибо обычно хватает простых ночных бэкапов.
2) Если не умеешь этим пользоваться то Симпла хватит

(80) Я за время своей работы раз пять сталкивался с ситуацией, когда нужно было срочно откатиться на заданное время/транзакцию. Так что в этой ситуации только FULL/

(70) так же, как и полный с добавлением WITH  DIFFERENTIAL
бэкапы подсовывать не надо, оно и само помнит, что поменялось с момента последнего полного бэкапа. сравнением скорости не занимался

(80) о как. а что за специфичный бизнес? можно узнать?

(83) У нас никогда ещё не забивался. Модель всегда FULL. :))

Фулл для небольших и средних баз 1с себя не оправдывает.

(83) уж это нормальные админы всегда сразу настраивают

(87) например розница 24 часа...
потерять заказы, даже за 1 час..
серьезный убыток

(88) Видел несколько фирм где при Фулл забивался диск и падала база (Всё на одном диске было, включая Темп файла)

(85) не сталкивался с таким не разу, ибо остальные все равно теряют свою введеную информацию,
так что было не сильно принципиально на начало дня или на середину дня

(91) Ты знаешь, даже с документооборотом хотя бы 1000-1500 документов в день, уже существенно. И 24 часа не надо :)

(94) с таким документооборотом никто откатываться не будет даже на 1 час

(0) Ghb FULL  не получилось открой для себя
backup LOG WITH NO TRUNCATE

SIMPLE + раз в сутки фул бекап + Каждый час дифференциальный бекап

(91) Например заказы можно ещё выгружать в МайСКУЛЬ.
Потому что у меня было что упал сервак да так что с бекапами, и только то что копировал(параноя) я на всякий случай в другое место бекапы спасло.
Так вот , а заказы за день подняли с Майскуль (там велись логи что кто менял,этого хватило)

simle

А вообще спор неочём. Если нужна инфа за день то Full если не нужна то Simple

симпл - а частоту и структуру резервных копий можно настроить отдельно

(99) если нет проблем с производительностью, то по большому счету все равно что :)

для фулла шринковать лог нужно после бэка этого лога ...

backup log <name_base> with truncate_only

dbcc shrinkfile (N'name_file_not_extension')

(99) поясни

(96) полностью согласен

Достаточно

А нам больше и не надо

(97) Выгрузка в MySQL - это какая-то штатная фича конфы?

в (17) все написано, исходя из этого уже и составляется стратегия резервного копирования,
все остально писькомерство (базы большие, админы крутые, конторы большите и т.)

Емнип, на симпле логшиппинг не делается. Только на фуле

И каждый час выгрузка в dt

График работы 24/7

(110) это издевательство же. юзеров выкидывать каждый час из базы.

(110) dt не гарантирует сохранности данных

Спасибо за ответы - я для себя решил СИМПЛ оставить. База бекапится раз в сутки, бекапов до минут не надо.

(96) тоже плюс. При базах до 50 гб более чем достаточно, как мне кажется.
Использую эту схему.

(111) не, никого не выкидывает
(112) за три года проблем не было ни разу

(115) Успеваете во время регламентированного ежечасового 10-минутного перекура, к которому если не вышел из базы - лишение премии?

бекап 4 раза в сутки,утром полный,если простой это все вешалка,документо оборот до и больше.

(116) неа.. пользователи работают, база бекапится в дт и отправляется на удаленный фтп

(118)выгрузка при работающих пользователях?

(119) типатово

фантастика прям какая-то

(121) http://infostart.ru/public/22419/

(122)молодец

(122) так бы сразу и сказал что из копии выгружаешь

(118) чем это лучше обычного цкульного бэкапа?

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

(18) в обед вообще-то все как раз обедают и отдыхают, или может вы работаете? ))

(126) в общем случае со цкулем и сервером 1с:предприятия, т.к. лимит 4гб/тбл еще никто не отменял.

10 гигов DBF, побыстрее ваших SQL будет

+(128) знаю..
когда то получилось что дт меньше по объему занимал
вот и родилась такая идея

(130) Сама по себе идея с мгновенными снимками заслуживает внимания. Возможно, даже возьму на вооружение. Спасибо.

Если пожать в 7z или rar по окончании процесса, может даже и поменьше dt-шника выйти. Но это уже мелочи.

штатное сжатие сиквела нормуль жмет и базы и бекапы

(131) из скульного бэкапа не развернуть базу локально... поэтому тема с дт интересна

У мну FULL каждые 10 минут, т.к. ячеистое хранение. Если база наикнется (не дай бох)..., то даже часовой давности бэкап не поможет. Т.к. рота бойцов бегает по складу с терминалами. Попробуй потом восстанови - чего они там между ячейками наперемещали...

(134) это ты погорячился с фулом каждые 10 минут. делай дифы каждые например 2 часа, и лог журнала каждые 10-15 минут

(131) Насколько я помню, сам снапшот делается моментально. Но с момента создания запись происходит сразу в 2 места, что приводит к более медленной работе.
+ Enterprise - у него более дорогие требования лицензирования, чем у стандарта, например.
+ в 2008 появилась возможность архивировать скулевские бэкапы самим скулем.

Хы!!! Помнится прожжённый SQLщик пяткой в грудь себе стучал за подробные архивы. Оно ж чуть ли не с минутной частотой делается!! Ну настало время Х, навернулся у него супер-пупер надежный рэйд. Навернулся тазом. Медным. Тот с криками "банзай" начал колдовать со своими архивами. Пол дня тъяхался. В конце взял обычную ДТшку, восттановил и бухи начали работать дальше.
Уж я не знаю как оно там сохранялось, но восстанавливая наикрутейшие минутные срезки, получали затыки то в одном месте, то в другом

(137)а чего там колдовать-то ... может там такой-же скульщик как я испанский летчик?

В общем надо держать базу СУБД в симпле, делать периодические бакапы средствами СУБД и раз в сутки переводить один архив в формат 1С, т.е. в DTшку

(138) Фиг знает как, но получалось, что база из портала выходила частично

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

Все базы ставлю фулл. В рабочее время бекапы лога каждый час делаются. Все что старше 30 дней - удаляется. Плюс планы обслуживания. Все нормально шринкуется.

+(143) Раз несколько это спасало. Только катастрофы не было. Просто просили сделать копию по состоянию на определенное время.

(28) "Неопытный прог зачистил регистр сведений значения свойств объектов (отбор не установил) на живой базе" - а что неопытный прог делал в живой базе?

(144) Т.е. бухи забыли кто что час назад делал???? С таким самодурством архивы не спасут. Эти зверки найдут методы обвинить восстановленные базы в подтасовке данных. А вот полугодичные данные иногда нужны.

(146) Не час назад. А например - восстановите базу по состоянию на 15:20 среды прошлой недели, чтобы посмотреть - что было в базе на момент предоставления отчета большому боссу :)

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

Хотя с другой стороны, в 1С-е предусмотрена версионность необходимых данных. Например, складские отчеты можно с итерацией в секунду смотреть и все нормально видно вообще без восстановления базы. Или есть другая потребность?

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

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

(149) Бывают случаи, когда бэкапится база, уже с порвреждениями в структуре. При этом бэкап прекрасно проходит, а вот с восстановлением или роллапом возникают проблемы. Но это скорее исключение, нежели регулярность.

(146) а причем тут бухи?
есть например менеджеры которые в реальном времени сидя с гарнитурой на бошке забивают в базу расчетные технологические карты по параметрам которые им надиктовывают клиенты по телефону/скайпу...

Кстати, у нас настроен логшиппинг на другой скульный сервачок. В результате, если грохнется основной - запустить рабочую базу можно через 15 минут с потерей данных в 10 минут. А логшиппинг только фулл.

(152) Ок. А потом что? Когда надо восстановить базу на час назад?

(153) А у нас кластер из 1С серверов и СКЛных и мы еще быстрее восстановим работу, если что-то поломается без потери данных вообще.

кто быстрее понеслось,
восстановление базы

(135) ну да, конечно, речь о логе каждые 10 минут

(139) А если база гигов 100 - как ее в dtшку каждые сутки делать?

ни разу еще не понадобилось восстанавливать базу на определенный момент, пользователи рады и базой недельной давности, лишь бы работала.

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

Ну вот представь. Склад у тя хотя бы 10 тыс ячеек и хотя бы столько же номенклатуры. И база, которая все это дело хранит. И человек 50, которые в эту базу на терминалах фигачат каждую секунду по нескольку транзакций.
И что тебе даст вчерашний simple?
Да ничего... Он будет также полезен, как и архив годичной давности. Т.е. с таким же успехом брякнется в корзину.

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

(159)не завидую я твоим пользователям

(160) Симпле мне даст то, что я смогу на каждый момент времени сделать складской отчет и посмотреть инфу по всем складам на любой период. Или так не делают? Отчеты на разный момент времени делают исключительно из бакапов? Хм, надо подумать

(161) Попробуй мир скриптов. На каждый день своя DT-шка без остановки баз

(158) Для таких объёмов, свои подходы. Самое первое - когда покупаю много продуктов в магазине, прошу упаковать в несколько пакетов, а не трамбовать в один, что бы потом не корячиться и не рыдать, пока буду нести

(163)симпл собственно это просто модель восстановления данных ... как он у тебя влияет на то, что ты смотришь в базе?

(164) Вот именно - ни как! Ни симпле, ни фулл, не влияют. А вот на ресурсы это влияет. Поэтому я за маленький размер СУБД, вместо секса с ней

База маленькая до 10 Гб.

Если база большая ну где-нибудь 100 ГБ, то тут без Full сложно будет делать частые архивы ...

У меня SQL Express и маленькая база. Архивирование полное длится минут 5-10 ... да я могу хоть каждый час его запускать, тем более, что полный архив всегда надежнее разностного

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


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

(167) Я понял где горячее, а где холодное. Историю склада я смотрю средствами платформы, а не средствами бэкапов!!!!

В (151) описан случай разгильдяйства, а не штатная ситуация. Если автоматизировать разгильдяйство, то получится полный абзадец. Перво-наперво, надо научиться регламентным операциям и по максимуму их автоматизировать. Да, всякое бывает, но проще предусматривать непонятный развал, нежели лечить.

(163) Про маленькие базы - прирост базы 20 гигов в месяц. Делать новый архив каждый месяц? Или каждый год?
Свертка вещь хорошая, но потом приходит VIP клиент и говорит - мы проходим аудит, а предоставьте мне единый отчет с 01.06.2008 по текущую дату, и начинаешь склеивать отчеты с нескольких баз...

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

(170) Нууу, имхо, за предоставление пользователям права на непосредственное удаление надо бить табуретом.
Другой вопрос, когда покосячили данные и надо их восстановить. Здесь может помочь версионирование, если оно реализовано/включено. Ну или поднимать бэкап

(145) Работал е-мое..
Кто же не косячит?

(169) Я ж говорю, ситуация не из тех, где обсуждается модель СУБД. Тут надо думать про то, на чем вообще это дело должно крутиться. И если 20 гиг в месяц прирост, то... надо работать с ИТ отделом. Это же за год 240 гиг, а за 4 года 960!!!!!
Нет, тут тоже 120-140 гиговый монстр был и доказывали. что это ноухау уникальное во всей вселенной. Утверждали... пока не отказались от уникальности.
Извини, я не против больших объёмов, но 20 гиг в месяц на 1С-е!!!!

(171)под удалил не имелось ввиду документ ... а удалить приход можно удалив строчку из табличной части приходного документа

Обычно хватает бэкапа сделанного раз в сутки. Поэтому

(170) У меня отключено интерактивное удаление и это правильное решение. Все остальное смотрится средствами платформы!!!!! Вычисляется гораздо быстрее восстановления базы. К тому же если в коллективе есть чудак, который пытается что-то удалить, то опять же задумаюсь о месте работы

(177)причем тут интерактивное удаление?

(171) Ммммм, это интересно, а как можно прокосячить?

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

(163) "Симпле мне даст то, что я смогу на каждый момент времени сделать складской отчет и посмотреть инфу по всем складам на любой период. Или так не делают? Отчеты на разный момент времени делают исключительно из бакапов? Хм, надо подумать "

чевооо? При чем тут бэкап и складской отчет?

так, мои проигрывают, надо поддержать

(175) Журнал регистрации + дописка как и версионирование в УПП + инструкция ответственным лицам. В итоге косячники исчезли как класс, все подобные косяки главбух находит мгновенно.
Стоп, неужели крутейший бэкап лучше будет?

(180) в (183) кратенько описал, как это исключить эволюционно

(183)расскажи мне как в журнале регистрации посмотреть какую строчку удалили из документа?

(181) Ну а тебе то что дает фул? Восстановить базу на 9 сентября в 12:36 по мск. Что увидишь такого удивительного, чего не увижу я?

Симпл. Еженочные копии. На пальцах разложила, мои сказали что в аварийном случае готовы перебить данные за день. Ну и отлично :) Пока аварий не было :)

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

(185) "+ дописка как и версионирование в УПП" я же написал. Там все изменения фиксируются прекрасно. Какая строка была, как её удалили. Все видно. И этим уже давноооо ни кто не пользуется

(186)что было с документом из которого удалили строчку 12:35

(188) Любители твоего метода, тъяхаются с поиском удаленных строк, поддерживающие мои методы, просто не сталкиваются с таким. Когда народ видит, что кара приходит незамедлительно, пропадает желание нечаянно удалять строки. У нас по началу сабботаж был. Мы даже не ругались, просто указывали на косяки. Это первое время и все

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

(190) Я посмотрю в версионировании. Понимаешь? Это будет быстрее, удобнее и без участия ИТ отдела!

(193)блажен тот кто верует ... удачи тебе ... и моли бога что-бы к вам на работу не пришел специалист по отжиму лишних денех у компаний

(192) Жаль, что ты со мной не работаешь. Очень жаль. Особенно жаль, что ты не работаешь на тех местах, где мы создавали инструменты для контроля таких вот "менеджеров" и какие им дела после этого шили

(194) Что ты? Приходят постоянно! Не переживай, они уверенны в себе. Отжимальщик, блин...

(196)к вам приходят чайники ... ну или овцы криворукие ...

(194) Не обижайся, я просто пытаюсь тебе сказать, что в жизни, начальнику не важно сколько см, важно быстро и четко найти причину "почему товар не можем продать".

(197) Не обзывай людей, не зная их. Это так, совет просто

(168) Вот именно.

FULL - есть средство предотвращения непредвиденной ситуации.
Когда по любым ситауциям, кроме аппаратных сбоев на сервере и физического разрушения БД SQL (а это не так легко сделать) есть возможность откатиться на _любой_ момент времени. В т.ч. и за минуту до аварии.
Поэтому (тсссс.... секрет...) после косяков первым делом делают... еще один бюкап лога. И восстанавливают за минуту до этого.

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

При нормальной настройке плана обслуживания никаких проблем с базой нет и снижение производительности несущественно.

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

Кстати, версионирование в УПП _гораздо_ тяжелее FULLа :) и занимает намного больше места.

(199) Может лучше заняться предупреждением поломок, а не предусматриванием их последствий? А то ведь может война случиться или потоп. Если уж на то пошло, то бэкапить надо в соседнее здание, а еще лучше в соседний город. У нас есть такая инфа, которая (не в 1С-е) по разным городам реплицируется на случай полный ппц

(200) Кстати, самописное версионирование вообще не заметно

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

(202) +100500. Да! надо и то и другое.
(201) насчет твоего самописного ничего сказать не могу. А из 230-гиговой базу УПП 72Гб _старых_ данных версионирования вычищал. И после уменьшения количества версионируемых документов (оставил минимально необходимые) по замерам +15% скорости прибавилось.

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

А "на соседний сервер/в соседнее здание/в соседний город" прекрасно архивируются ранее созданные бэкапы.

(202) Да я не спорю. Чесслово. Просто мы предложили такую концепцию и она прижилась. У нас сильные скульщики. Мы оценили время реакции и шансы получить по шее. Уверяю, ответственные гораздо больше довольны системой отчетов, нежели мальчика, держащего палец на кнопке восстановления. Если бы выбрали упор на бэкапы, то нам пришлось бы в начале кампании дежурить круглосуточно и без выходных.
В общем для бэкапы на самый страшный случай, которого не будет (!!!!!!!!!!). А вот для выявления не честных, анализа прошлых данных и прочих хотелок пользователе, лучше использовать средства платформы.
Это у нас так

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

(205) "Использовать бэкапы для анализа - жесть"

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

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

(205) ты сейчас нахаляву рассказываешь решения, которые стоят денег. Нафига?