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

Может есть у кого-нибудь какая-то хорошая идея по этому поводу? Сервер не предлагать, в бэкапах тоже большого смысла не вижу.

Заявление напиши...

Собственно после "в бэкапах тоже большого смысла не вижу.", обсуждать и советовать нечего.

так на жесткий диск похоже

(2) +100. Как говорится, люди делятся на две категории.

(0) Вот и правильно! Я лично никогда не сохраняюсь в компьютерных играх, например. Ну просто смысла не вижу.

(+) +100500

меняешь жесткий диск, еще один для бэкапов и будет тебе счастье

Либо сеть, а если все выполняется на одной машине, то диск пора менять

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

Запусти Victoria HDD и потесть диск

(2) Это пройдёт, вы со временем поймёте, что бывают ситуации, когда резервное копирование, тем более файловой базы, совершенно бесполезно. Просто поверьте.

(11) Ну, это положим глупость.

(11) смотря как делать резервное копирование

(11) Буду рад, если объясните. Вот сломалась база, глубо говоря, данные потеряны. Имеется бэкап. Неужели его наличие не делает погоды? Если б его не было - ничего б не изменилось?

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

(14) Всё зависит от кривизны рук. При достижении определённого уровня кривизны - разницы действительно не будет :)

(16) Какой должен быть радиус, что бы смело заявить о ненужности бэкапов?

(14) Объясняю: бэкап файловой базы не получается делать часто, поэтому в любом случае не получится восстановить из бэкапа последние данные.

(11) а больше поверю в упоротость и рукож.пость

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

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

(18) забавно, т.е. нет разницы восстановить последние или не восстановить ничего

(21) +100500 ))))

(22) Да, нет разницы.

(24) Мда....

(18) все там получается. достаточно промотивировать юзеров - чаще бекапитесь - лучше спите по ночам. раз денег нет на скуль и клиент/сервер

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

(24) базы используются в сетке небось...

Не, ну если у них 2 документа в день и работают два месяца, то смысла и правда нет )))

(27) Это как?

(30) Халява, гугл, читать, взять взять

https://ru.wikipedia.org/wiki/PostgreSQL

(27) За серверный ключик все равно платить... проще купить комплект для небольшой фирмы на 5 усеров

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

(30) SQL бесплатно. Но сервер 1С и клиентские лицензии 1С за деньги. Клиентские лицензии у вас есть.

(29) А если 20 документов в день, то смысл есть? И как же организовать резервное копирование? Перед каждым из 20 документов выходить из 1С, копировать (в новый набор, естественно), проверять работоспособность набора (как?), потом заходить обратно в 1С? База причем не 100 мегабайт.
Давайте, делитесь мудростью.

(32) А вдруг он найдет ключик :)

(32) Да ну, там база однопользовательская.

(34) Клиент 1С в любом случаи за деньги :)

(37) Тогда всех в Терминал.

На сервер бесперебойник, хороший :)

(35) раз или два в сутки достаточно вполне, зачем такие крайности

(39) Ну какой терминал если там один комп с базой?

(35) зачем выходить из 1с? просто в обед например(когда никто не записывает документы) копировать файл базы и всё...

(42) размер базы какой?

(42) 1 ПК.
Нет Сети
Все локально.

Пользователь поди и есть царь и бог? В лице Гл. Буха и т.д. :)

загнать всех в облако как вариант.

там вроде само облако бэкапит

+ Нечего, все до первого шифровальщика :)

>все до первого шифровальщика

нет в жизни счастья

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

(46) Погоди, щас выяснится, что это БД у кладовщика на затворках удаленного склада :)

(49) Делай каждый день копию = начальный образ + на каждый чих выгрузка изменений (в отдельный файл) с очисткой регистрации.

(49) А чего, людям история за вчерашние дни не интересна?
Тогда предлагаю их перевести в ексель ;)

(50) Как-то так.

(49) т.е. документы всех предыдущих дней не имеют никакой ценности? ну тогда конечно бэкап нафиг не нужен

(35) 100М это вообще ни о чем. Можно и раз в несколько часов копировать, и даже раз в час. за 8-часовой день 8 срезов - это всего 800М.

(50) нафиг там вообще тогда база. карандаш и книга амбарная

наличие учетной системы с требованием к ней в виде бесперебойности подразумевает под собой затраты

(56) +100500, поддерживаю :)

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

(58) Если БД дохнет локально. То скорей всего ПК вырубается постоянно.

+ Лучше подумайте об бесперебойнике и инструктажа тети Клавы, что выдергивать ПК из розетки Плохо :)

(29) А где же мудрость-то?

(59) +1000

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

(60) Думаю изо всех сил, но не помогает. А уж когда тетя Клава сидела на генераторе и у неё комп вырубался при печати, было вообще весело. Но это частности.

(58) вангую вопросы к мисте типа "здрасьте, у нас тут в деревне электричества нет. Как нам организовать бесперебойный учет кур-несушек в компьютерной системе?"

(63) Бубен! Шаманский. Помогает всегда

(51) Если база будет утеряна, скорее всего всё равно придётся менять диск либо переустанавливать винду, тогда база будет загружена заново.

(0) Бэкап всё равно делать придётся, вопрос как.

На первый взгляд для файловой 1С shadow copy должна содержать консистентную копию базы на момент снимка, по крайней мере в большинстве случаев?
Под Windows c снимками файловой системы можно нормально работь? Если можно, то делать снимки с максимальной частотой и неспешно перекладывать их на внешний носитель.

Смех смехом, а проблема-то усугубилась где-то при переходе на 8.3.

(69) скорее к тому времени база увеличилась в размерах

(70) Нет, размер растет мало, она состоит почти целиком из справочников.

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

(71) ну значит оборудование доумирает

(73) Да там ведь не один такой комп, а проблема усугубилась на всех.

(74) сча напоминаете деревенского "знахаря" который к медикам в город обратился...

(75)+ поймите что без обследования пациентов ну нифига низя сказать совершенно

вплоть до того что просто какая то зараза из розетки вырубает или просто лектричество само пропадает часто ))

(76)+ Сползай в винде в журналы посмотри какие события там

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

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

(77)+ http://pastenow.ru/SG5V

(79) оно ругаться же должно вроде как, но я уже ничему ну удивлюсь

(0) поменять прокладку, которая между стулом и монитором

а почему не было "автар, а вы кем там работаете?"

(81) Ругается только если, к примеру, 8.3.7 и 8.3.8. В таком случае, работает тот, кто первым зашёл.

Если же 8.3.7.2368 и 8.3.7.3322(номера от балды), то работать будет. Но итог печален: база ляжет.

(81) файловая не ругается. Только если одновременно с 8.2 и 8.3 - то да. А по очереди - пожалуйста, с 8.2.18 и 8.2.19 одновременно - пожалуйста. Работает, только таблицы иногда крошит)

(83) понятно что не админом и не программистом... хотя погодите ...

(86) бетонщик?

(87)
Циркулярщик-пильщик?

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

Откуда в ветке 89 постов?
(0) вполне самодостаточен, после него сразу на баш :))

У человека проблема не в 1С. И не в ПК. Тупо энергии не хватает на работу ПК, принтера + Монитора + мышки.
+ Чайника, Плиты и других бытовых приборов :)

Предлагаю (0) установить ветряные мельницы, а так же солнечные панели, прикрутить генератор. Проверить конвертер на 220 вольт.

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

(91) как проверить? а то автор решит "не совать пальцы в розетку бред"
(92) перелогинился?

(93)
Это мой единственный логин на этом сервере.

Не только из за HDD и сети может, из за битой RAM тоже легко. Memtest в помощь.

(94) про (87) который красненький в прошлый раз так же говорил кто то

(92) то есть, к примеру, у меня база сломалась(вообще не открывается). И у меня есть бэкап который ночью сделался скриптом автоматически. По вашему он мне никак не поможет?

(92) такое может быть, если вы новым бэкапом перезаписываете старый. Но, вообще говоря, можно хранить не один бэкап, а несколько, скажем сделанные в 8, 12, 14, 16 и 18 часов. Тогда в вашем распоряжении в момент аварии будет много копий разной степени свежести. Не думали об этом?

(97) там двусмысленная фраза:
вряд ли автор хотел сказать "Очень часто  нет смысла",
скорее "ОЧЕНЬ часто делать бэкапы".

(98)
Не переписываю.
Очень часто бэкап старше двух часов бесполезен.

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

(74) Восьмёрка в файловом режиме крайне неустойчива к пропадание питания на ПК.Дохнет на раз.Так что или вам переходить на семерку или купить какой нибудь минимальный бесперебойник.Разговоры про SQL смешны, если нет денег даже на это.

(92) >>Очень часто для файловых баз действительно нет смысла делать бэкапы.
А, ну да, раз еще и ты это сказал, то да, не имеет смысла, конечно.

>>Но это минимум пятьдесят штук за лицензию на сервер плюс железо не бесплатно.
Что за бред?
15 штук за минисервер 1С и скуль бесплатно.

(102) кому этот минисервер нужен? Если есть хотябы 3 рабочих базы, с которыми работает по 2 человека - все лицензий не хватит

(101) попробуйте еще планку памяти снять, вынуть доп питание с материнки, втавить вилку в кулер, уронить на системник шлакоблок

(104) У ТС денег нет даже на бесперебойник!Какие шлакоблоки, вы что?)))

(0) > Постоянно бьются базы - что делать?

Закон о дуэлях принять...

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

(18) А почему не получается делать часто?
Ну хотя бы три раза за рабочий день делаете?

Правильно понимаете(107) .

(0)Для начала выясните почему базы бъются.
Это либо проблемы с диском, либо частые отключения питания, либо проблемы с сетью.

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

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

(110) до чего у ТС руки или ноги дотягиваются, с тем и проблемы. Еще он научился шару снимать налету и удаленный ребут с консоли, нашел автомат ведущий на серверную и включил в бесперебойник 3 ХП ЛДЖ 1100 и включает их одной кнопкой

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

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

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

(93) Как еще можно проверить? У него на удаленном складе "типо того" стоит 5 ПК. На них локально запущена 1С. При этом 1С по сути однопользовательская.

(107) Можно сделать несколько разных служб-кластеров 1С, в каждом по одной базе. Лицензии должны получать клиенты не через сервер 1С. Или так не получится настроить?

Все не читал, UPS уже предлагали?

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

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

(78) Дремучесть - это предлагать заведомо неподходящие варианты, причем даже после того, как на это несколько раз указали.

(86) Одинэсю с 2004 года, админю с того же, программирую с 1994, что дальше?

(97) Вы погодите, всё началось с того, что я говорил, что МНЕ такой бэкап не особо нужен, я-то ведь не 80% советчиков из этой темы и не говорил за всех, а только за себя.

(105) Понимаете, какая беда - ломаются они гораздо быстрее, чем компы.

(113) Специалистов набралось - мама не горюй, действительно, опыта нет, стартовый пост внимательно прочитать не можете, но самомнение того и гляди крышу сорвет. Чем вам не нравится формулировка "пропадают пользователи"? Я там дальше написал, что портятся записи в таблице V8USERS, но вы же этого тоже не поняли, потому что "запись", "таблица" и другие непонятные слова.

Как можно тему куда-нибудь во флуд перенести? А то по существу тут не густо, но зато весело.

(121) Ну не в силах 1С-ник подать в сеть 220 вольт вместо 70-ти :)

(123) Беда в том, что вам нужен по сути стабилизатор. Ломаются быстро, т.к. поди все время на батарейке сидят.

(121) Зря проведенное время, нет?

(125) А тебе еще не дали право модератора?
За выслугу лет :)

(128) А вы уже поделились мудростью про бэкапы, а то я что-то пропустил?

У меня как-то был случай. Звонит мне знакомый, у него сервер падает. Там был RAID, 10 вроде. В разговоре я выясняю, что на сервере неисправен блок питания. Говорю ему об этом. "Запасной взять неоткуда, буду ковыряться с тем, что есть." Результат - провозился полдня, несколько раз звонил мне... Кончилось тем, что сервер у него перестал загружаться уже при любой комбинации дисков. Что было дальше - история умалчивает.

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

(126) почему не в силах? преобразователь напряжения воткнуть и фсё.

Оттуда я вывел одно правило: "Не работай на неисправном железе." Собственно, сказать мне больше нечего.

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

Резюмирую: ТС не хочет делать бэкапы и покупать  рабочее железо, но хочет что-то такое итить его чтобы если база рухнула, чтобы сразу воскресла как ни в чем не бывало, и дальше можно работать. А начальник, который жмот до денег, ничего не заметил.

У ТС гонору, девать некуда. Раз столько опыта, так чего ж  элементарной проблемой разобраться не смог? Кто-то здесь врет ))

(137) Кто-то здесь так и не поделился своей мудростью, а только самомнением. Ну расскажите уже, как правильно делать бэкап на отдельно стоящем компьютере с файловой базой, чтобы из него можно было быстро восстановиться, если база упала в процессе работы? Дайте добрый совет недалекому коллеге!
(136) Особенно, если факт повреждения базы виден далеко не всегда сразу - она бывает работает, но зависает при обращении к битой таблицей.

(137) налицо Эффект Даннинга — Крюгера

(0) (138) "как правильно делать ... чтобы можно было быстро восстановиться". Вопрос изначально неправильный. Когда начнете задавать правильные вопросы, начнете получать правильные ответы.

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

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

(142) почему, ночного бэкапа вполне хватит. А сколько у вас документов в день вносится?

(138)Ставь SQL. Там это реализовано.
...Если есть зависания с битыми базами, то их надо сначала вылечить. (142) Например, cobian может делать теневое копирование как папок, так и отдельных файлов.

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

(142) "... база упала в процессе работы." - это ИСКЛЮЧИТЕЛЬНЫЙ случай, вы понимаете? База не должна падать в процессе работы. Если база падает в процессе работы, этому должна быть причина. Причину падения базы в процессе работы надо найти и устранить.

(145) Буквари пишут не только для начинающих, но и для опытных. Ты не оценивай ответы. Упёрся рогами ты. ИМХО.

(143) Мне не нужен ночной бэкап: при восстановлении из него у меня будут потеряны все документы за день, сколько бы их не было, а при восстановлении битой базы они почти наверняка восстановятся?

(148) Наверняка - это вряд ли

(147) Я оцениваю то, что это ответы на другие вопросы, не на мой. Как если бы я спросил как настроить файл-сервер, а мне бы на двух страницах предлагали поставить Линукс вместо Винды.

(149) Ну во всяком случае пока 100% инцидентов попадали в это "наверняка".

(148) смотри (146) Под ваши требования подходит только SQL база с моделью восстановления FULL. Забудьте про файловую базу.

(152) Не пойдёт, у нас компьютер на верхней полке склада у тёти Клавы, никогда у неё не будет сервера. Я бы с радостью.

(150) Не передёргивай. Не все вопросы  и ответы из этой серии. В данном случае ты ждёшь лекарства, не уточнив диагноз.
(153) В таком случае или находишь денег, или платишь сам, или мудохаешься дальше. На велосипеде в космос не улетишь, даже если сильно стараться.

(153) Вы, однако, очень интересный идивидуум. Вы согласны с (146) ?

(155) Конечно.

ОФФ. Тема плавно перетекла в философию и психологию ))

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

(156) Что вы думаете нужно сделать чтобы свести к минимиуму этот исключительный случай?

Поддержу оратора в части поломок файловых баз. В последнее время участились проблемы с файловыми базами при переходе на 8.3.7 и далее и установками последних релизов.
Как правило документооборот небольшой, тут бэкапы точно помогают :)

(158) Надо выяснить почему происходит неожиданное прекращение работы и вылечить эту первопричину. 1С не просто так рекомендует клиент-серверные решения.

(159) Заземлять, развязывать, стабилизировать, фильтровать помехи. Но, как я писал чуть выше, это всё стОит денег, в отличии от восстановления базы.

(162) если вы потеряете все данные, как вы думаете, во сколько это обойдется бизнесу?

(161) Вот если бы 1С умела хранить свою базу сразу в SQL, без сервера 1С, я бы конечно тут же поставил SQLExpress или что-то в этом роде.

(162) Хороший бэкап тоже стоит денег. Ты сейчас какой бэкап используешь?

(164) Переходи на 1с77 ))

(163) Максимум в двое суток, причём бизнес в это время просто будет писать на бумажке.

(166) Она тоже так не умеет, дбфка+драйвер FoxPro - это не SQL.

Минисервер 1С стоит 14400, если я не ошибаюсь. (167) Может им и компьютер не нужен?

(167) А зачем вам вообще 1С?

(168) Есть версия для SQL

(170) 1C - платформа для построения систем учёта, нужна для учёта. Заметьте - флуд начал не я.

Можно разместить базы в облаке от 1С

(172) почему не использовать амбарную книгу?

(173) там с электричеством то напряжёнка, какое облако...

(172) Это ты про 1C: Бухгалтерию 3.0 для DOS? Доступно и всерьез

(176) Не довелось, начал свой пусть с 7.7 + 1С++. Но судя по названию, 1С:Бухгалтерия всё-таки не платформа, а непосредственно система учёта.

(174) Я же не говорил, что она не используется )

(178) Вот. Но вы так и не ответили на мой вопрос.А таки зачем вам вообще 1С?

может Excel хватит?

(179) Для учета
(180) 1. Эксель тоже стоит денег
2. В экселе (ну и в опенофисе) хоть какая-то автоматизация выйдет очень сложной, да и специалистов нет
3. Ну и, собственно, книга эксель вообще-то тоже может сломаться

(180) Попробуйте в экселе простейшую систему с приходом и расходом товаров сделать - увидите, что это не так просто.

Если там так всё просто, напиши свою, хоть на плюсах, положи базу в хоть SQLite или постгри и бэкапь хоть каждую минуту.
Бесплатно, надежно и просто.

(183) Где - там?
Про бэкапы так и не поделитесь?

(184)Раз у тебя всё ведут в амбарной книге, то самописки будет достаточно.

(185)+ ТыжПрограммист...

(185) Ну так вопрос был в том, как бы эту самописку восстановить, чтобы она работала, а не в том "установи сервер, на сервер постгрес, на постргес эксель, потому что за 12 лет работы у тебя не хватило ума на такую простоту, и настрой бэкап, который не нужен, потому что если делать его ночью, то за сегодня в нём данных нет, но все у кого не делается бесполезный бэкап - дураки"

(187) Чукча не читатель? Пиши самописку не на 1С. И нет проблем.

Бэкапов нет! Но Вы (пользователи) держитесь там!!!!))) (с) не мое...

(188) Напоминаю ещё раз: вопрос был "как бы эту самописку восстановить, чтобы она работала", а не как написать другую такую же. Я понимаю, что в силу недостатка знаний вам нечего предложить, но я не понимаю, зачем повторять одни и те же глупости, если вы даже своё предыдущее, неправильное, но яростно навязываемое мнение про бэкап не можете аргументировать?

(190) Что бы ее восстановить, нужно что-то из чего ее восстановить. Вот тут мы приходим к противоречию, не так ли?

Остался в теме кто живой? Как вам создание отдельной резервной пользователей и загрузка их в базу после восстановления?

(191) Вы - может быть. Остальные помнят про штатную утилиту chdbfl.

(191) Так что там с бэкапами?

(190) Повторюсь. Cobian Backup  бесплатный. Настраивается по расписанию. Может делать ТЕНЕВОЕ копирование. Попробуй, понравится. Копируешь на внешний диск, а с внешнего диска на другой комп. И т.д и т.п.Ты это пробовал?

Сам с собой разговаривать начал. Мда.. плохой признак. Мальчик, ты чего хочешь то? Людям объясни...

(195) Ему не нужно копировать, ему нужно восстанавливать.

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

(197) ОФФ: Вспомнился анекдот про чукчу, который на вопрос жены: "Зачем в ярангу телевизор купил? у нас электричества". Он ответил: "Чукча умный - чукча розетку тоже купил". Я к чукчам отношусь с уважением, если что ))

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

(196) Тётенька, да что с вами, я миллион раз объяснил, неужели не усваивается? А вы мне в ответ миллион раз, убогому, бэкапы советовали, а как делать - не знаете. Как же так?

(197) Извиняюсь, вижу что наконец дошло.

(200) Не так

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

(202) Так почему же у вас бьются базы-вопрос остался без ответа.

(205) С электричеством перебои

(205) Он тебе не ответит. Он ждёт ответа на его вопрос.

(204) Устраивало, пока не стала ломаться таблица с пользователями, после чего база после восстановления остается не рабочей.

(203) Судя по вот этой теме, там не всё радужно: http://catalog.mista.ru/public/63970/

(208) Почему не приобретёте ИБП?

(208) почему не заменить таблицу с пользователями?

(211) Ну наверное это и есть единственный более-менее рабочий вариант.

(209) Ты пробовал? Или теоретизируешь? Сейчас есть новые версии этой программки. (211) (210) Его боссу жалко денег и не жалко админа с пользователями.

Мало того, что битая база, но и разбираться в причинах не желает. Прикольно.

Чем эта карявка лучше батника в планировщике?

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

(213) Непонимаю, зачем работать в конторе которая не может позволить ИБП чтобы база не падала?

(216) Ты на мой прямой вопрос ответь в (213)

(215) Вопрос в том, как эта корявка может исправить ситуацию, если она делает копию в тот момент, когда происходит запись? Она там что, количество записей исправит в заголовке файла что ли?

(218) Что на него можно ответить, если я про эту корявку узнал 20 минут назад?

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

(219) Смешной ты. Повеселил.

(222) "Вам меня жаль". Я уже давно это понял )

(221) Происходит запись документа, добавляется строка в таблицу, добавляется новая страница в файл БД и в это время делается теневая копия. Откуда уверенность, что все эти данные (они лежат в разных местах на диске, ведь NTFS поддерживает фрагментацию) будут соответствовать друг другу? Если нет, то на такой копии придется потом запускать chdbfl и далее - смотрите выше. Я не знаю, как правильно смоделировать эту ситуацию, поэтому утверждать ничего не могу.

ветка феерична

(225) ТС развлекает всех уже вторые сутки. Без  понятия о предмете разговора.

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

(227) Уже говорил про всё. "Товарищ не панимаит".

(132) Сделай как надо, а не как по правилам ;)

1. Установи там Сервер SQL или postgresql или еще какой.
2. Заставь работать... 1C ни смотря ни на что :)

+ настрой бекапы

(224) не получится

(224) Данные будут соответствовать друг другу гарантированно.
1)Теневая копия выполняется мгноваенно.
2)Теневая копия делает копию не файла, а всего тома.
3)Перед созданием теневой копии принудительно сбрасываются на диск все кэши.

Ветка, без сомнений, однозначно пятничная... но, попробую быть серьёзным :)

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

Вы ещё не догадались об чём я? Подсказываю:

Р И Б

(232) А если 1С делает записи последовательно, без привлечения транзакционного API ( https://msdn.microsoft.com/ru-ru/library/windows/desktop/aa964931(v=vs.85).aspx ), не позволяя другим сеансам прерывать процесс своими блокировками на lck-файле, то как OC сможет узнать, что вот этот участок новая страница, но в список страниц, его ещё не начали записывать?

(233) см (51)

(234) Механизм теневого копирования это часть файловой системы, без его ведома, изменить что-то в файловой системе невозможно.
При создании теневой копии блокируюется любая запись на диск, вне зависимости от поддержки приложениями API.

(235) Не смешите Вы меня. Не надо извращаться там, где уже за Вас подумали :)

(233) Классная шутка, долго смеялся.

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

А как у ТетиКлавы с интернетом?
Может выложить базы на нормальный комп, где с электричеством проблем нет, в ТетьКлавы пусть на него ходят по РДП.
Нет света на складе - не беда, когда включат - тогда и заработает.
Но базы на удаленке в целости и сохранности.

(226) Я попробую вам еще раз объяснить суть, на игровом примере. Давайте отвлечемся от недалекого ТСа, пусть тётю Клаву обслуживает тётенька DDwe, которая знает, что бэкап - это всё, он решит любую проблему и вообще свернет горы.
И вот, у тёти Клавы на компе делается по ночам бэкап. В 12.00 у неё зависает 1С (чего конечно никак не может произойти, как считает тётенька DDwe) и она его снимает через Диспетчер Задач (во хватил, да?). Запускает 1С заново, проверяет что вроде всё на месте и работает дальше
- забивает расход.
/* на самом деле база уже битая */
В 18.00 тётя Клава пытается забить приход и база вылетает с сообщением про что-то там "компонента dbeng..." - потому что сломана таблица _Document456.
Тётя Клава звонит тётеньке DDwe, которая поднимает ей сегодняшний бэкап.
/* через полчаса работы выясняется, что сегодняшний бэкап тоже битый, потому что комп в 00.00 перезагрузился (чего никак не могло быть) */
Тётенька DDwe восстанавливает вчерашний бэкап.
И идёт на форум с вопросами:
1. Как восстановить битый файл 1CD, поверх которого уже два раза записан такой же
2. Какой утилитой его восстановить и как перенести из него данные за полтора дня в бэкапную базу, в которой уже вовсю работает тётя Клава.

(237) Че это?

(238) Ага, мне самому нравится.

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

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

Не спрашивай "Зачем?" и где здравый смысл. Интереса ради и наличие свободного времени :)

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

(244) Ты пробовал прочитать внимательно?

(241) Зачем ты себя мучаешь?
Ведь ты уже знаешь что сделать?
Вопрос только в твоей карме ;)

(245) Пробовал. Не получилось. Слова все знакомые, но смысл  - ускользает.

(247) Печально. Но среди 1с-ником быть тупым - это почти норма.

(243) У него БАЗОВАЯ бухгалтерия, т.к. денег мало.

(249) Опять серишь в лужу? У автора самописка, о чем уже говорилось.

(248)  +1 И не говори, каждый день с такими сталкиваюсь. Вот, сегодня опять встретил. "Никогда такого не было и вот опять снова"(цы)

(251) Ну твой круг общения понятен. "Тупой среди тупых" (с)

(250) Согласен. С самопиской пёрнул, а вот насчет денег правда.

(253) Я поэтому и предложил автору поднять и использовать обычную, рядовую риб-базу - никаких дополнительных денежных  вливаний ни на программы, ни на железо :)

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

(255) Ну, не сообразил и что? Вместо оценки чужих ответов скажи, что ты сделал сам для устранения проблемы.

+(254) В чём отличие от предложения в (51)?

Если кратко, то:

Дополнительный узел в плане обмена с файловой версией подчинённой базы, в которой не работают пользователи, что позволяет неоднократно в течении дня создавать резервные копии простым копированием 1CV8.1CD

(246)(256) Однозначного ответа у меня на самом деле нет, примерно понятно только что нужно присматривать стабилизаторы. А вот если бы у chdbfl был пакетный режим (через WSH пробовал - фигня получается), то можно было бы написать скрипт, который
1. починяет базу
2. загружает в неё пользователей
и - ура, работать уже можно в большинстве случаев!

У Tool_1CD есть пакетный режим, но что-то я сомневаюсь, что с его помощью можно сделать то же, что с помощью chdbfl, за то же время.

(257) Так в (51) я именно это и предложил, разве что каждый день образ пересоздавать заново методом копирования, а не средставами платформы. Книга знаний: Альтернативное создание начального образа в УРБД И после каждой порции выгрузки изменений изменения очищать, не дожидаясь прихода сообщений об успешной загрузке с той стороны. Но в таком случае необходимо хранение всех сообщений обмена.

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

(260) А вдруг чаво? А?

Проглядел по диагонали.

Но у меня возникли вопросы.

1. Платформа какая?
2. Режим работы какой по сети или один пользователь локально или может в терминале.
3. Где базы лежать, что за железо, какие диски, ОС какая стоит?

ТС сам себе трудности создает и сам их героически преодолевает, но ему стало скучно и он решил других вовлечь в этот процесс. Вылечить базу это не спортивно.

(262) Локально
1 пользователь
Вот думается тупо Толстый клиент (догадка)

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

(260) Если бы в chdbfl можно было передать путь и получить на выходе список ошибок, то уже по именам таблиц можно было бы понять, что ему не хватает.

(263) В игровой форме тоже не дошло?

(0) Комплекс мер: смена жесткого диска, Установка ИБП, Смена платформы(!, т.к. иногда бывают действительно глючные релизы, которые рушат таблицы), периодическая очистка кэша 1С, в качестве резервирования действительно можно прикрутить РБД, которая сможет фоном сбрасывать данные в точно такую же базу, которую одним батником можно подавать тете Клаве в качестве основной и вместо нее создавать новый узел в качестве запасного.

(265) Какой смысл мечтать о несбыточном? Глядя правде в глаза, надо использовать только доступный инструмент. Напиши в 1С ))

(264) И в эксель прикрутить справочники, регистры и остальное.

ТС высосал проблему из пальца, еще и всех окружающих дураками назвал.

(268) Честно говоря, я надеялся, что в этой теме вместо меряния невежеством кто-нибудь подскажет альтернативный инструмент.

(267) ИБП есть, они дохнут. Вернее дохнет аккумулятор, т.к. ток такой маломощный, что все время работает батарейка. (со слов ТС данного топика)
ПК Локальный, нет внешней связи.

Но тут непонятно, как ТС админит...
Чет он не договаривает об структуре сети :)

(270) Нет, не всех, не надо всех грести под своё крыло.

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

(269) Регистр? Да клали они на твои остатки :)
А по справочникам, это да... ексель тут не катит :)

(271) Вы лучше описали бы, как у вас на самом деле, может кто подскажет

+ А приходится по крохам все собирать

(272) Да проблему с железом тут уже сто раз решили, теперь бы решить проблему с фанатиками-бэкапщиками.

(271)дак вот тебе альтернатива - фоновый РБД обмен взаместо быкапа. и релиз поменяй

(278) Если решили с железом? То какого БД рушатся из-за ребутов? :)

(279) Релиз непонятно на какой менять, проблема же не каждый день появляется, а следующие релизы может еще ломучее.
(280) Тут на форуме решили, в реальности всё как было.

(281) "а следующие релизы может еще ломучее" - дет.сад.

капец (200) ставишь .нет 3.5, кобиан бэкап, аккуратно проверяешь, что кобиан рапортовал "служба теневого копирования успешно установлена и запущена" и использовать теневое стоит в настройках. Настраиваешь в кобиане 2 расписания 1) "Обед" каждый день в 14:00, глубина хранения 3 дня, папка Е\бэкап\обед 2) "вечер" каждый день, глубина хранения 17 (отпуск + 3) папка Е\бэкап\вечер. Всё, ищешь другого клиента, с этим станет скучно уже

Идея с фоновым РБД каждые 15 сек (чаще - на свой страх и риск) не лишена здравого смысла.Но тут есть вероятность того, что именно в те самые злополучные 5 сек может произойти то самое нехорошее, из-за чего уже почти 300(!) постов и подчиненный узел станет бесполезным:)

1. Купить один сервак (можно типа сервак)
2. Купить на него хороший бесперебойник
3. Сделать нормальную гигабитную сетку
4. Поставить на сервак терминальный сервер
5. На всех компах снести оси и превратить их в тонкие клиенты
6. Сервак убрать в сейф/кладовку, ключ спратать админские логины никому не давать

(282) Тётенька, вы уже своё завышенное ЧСВ показали со всех сторон, можно дальше не продолжать. Ну или перейти на комментарии по существу.

(285) Сисьадминский подход:)
В нормальной конторе так бы и сделали.

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

(284) Идея мне в принципе нравится, но в моей ситуации мне кажется это лишнее.

(287) Тёте Клаве на верхнюю полку склада поставили бы нормальный сервак?

(286)а в чем все-таки секрет, озвучьте номер релиза?

(290) именно туда бы и поставили, в рамках страховки от ОБЭП :)

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

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

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

(291) Самописка ред.1.0. Мне уже два раза объяснили.

(291)(295) 8.3.6.2152  и пара соседних (все 8.3)

Эээ... хотя я уже ушёл... но вернулся ненадолго :)

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

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

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

(296) у меня такое же. Сам считаю его достаточно стабилным, но у меня SQL

(296) Конфигурацию назови )) Устал гадать

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

(299) Самописка ред.1.0

(298) Отборы в отчетах не по два раза приходится выбирать?
У меня 8.3.6.2237 на сервере не взлетел, там какие-то фоновые процессы были что ли, не оценил.

(300) Я дома так выключаю, никто не жаловался.

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

(304) Дядя necro принесёт новую.

(305) А где он ее возьмет?

(306) Там же, где брал, когда устанавливал в первый раз. Там ещё есть.

(307) Тогда откуда вопрос? Ну и подпихивай каждый раз как сломается.

(308) Опередил)

(305) Ну ты же в 241 горевал, что дневной труд бабы Мани потеряется. А в новой он откуда у тебя возьмется?
Если я правильно понял, что рекомая база - только аналог экселя, только со справочниками - набили документ, распечатали его и далее пофиг, то я бы предложил сделать так.
1. При проведении документа выгружать маленький файлик с его содержанием. Файл не поломается. А если документ записался в базу корректно, то как минимум его таблицы пока целые.
2. Когда база поломалась - не насилуем ее восстановлением, а берем новую (в которой только справочники) и загружаем туда сохраненные за сегодня файлы с документами. И вот это автоматизируется гораздо лучше, чем корректное восстановление базы chkdbf (которое не автоматизируется вообще, обращаем внимание на слово корректный).

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

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

(311) Пургу ты гонишь, короче. Троллишь народ по-тихому.

(310) Да, аналог экселя - со справочниками, документами, константами, регистрами накопления и регистрами сведений, а так же программным кодом, который всё это обслуживает.
А так 1С он вообще как эксель, да. Только 1С.

(312) Никогда не мог пройти мимо самовлюблённого скудоумия.

(314) ... глядя в зеркало ))

(313) "со справочниками, документами, константами, регистрами накопления и регистрами сведений"
Еще раз спрашиваю - для чего нужна база?

(315) Да разве же это я, читая "бэкап не предлагать" предлагаю бэкап, считая, что я умнее всех на свете?

(316) Ещё раз отвечаю - для ведения учёта.

(302) по два раза, по два раза

(317) Ты уже по кругу начал. Скучно.

(320) +100500 )))

(320) Ну вам же не лень одну и ту же чушь нести четвертую страницу, причем не представляя себе как бэкап должен работать. Я где-то на предыдущей странице предположил, как будет развиваться процесс по сценарию ночного резервного копирования, вы мне не возразили (кроме того, что я ничего не понимаю в компах и 1С), ваш вариант не подходит, он плохой.
Но вы продолжаете на нем настаивать.
При том, что вопрос был вообще не про то (наверху посмотрите).
Это просто праздник какой-то.

С такой упёртостью вы доработаете до первой серьёзной проблемы.

(318) Какой же ты трудный.
Ведение учета, да. Которому покер на то, что часть данных после "восстановления" пропадает. Ты уверен, что такому учету нужно "со справочниками, документами, константами, регистрами накопления и регистрами сведений" ?
В 310 только последнюю строчку прочитал?

(324) Там уже два раза озвученный вариант регистрировать и выгружать обмены. При проведении выгружать действительно выгоднее, чем по расписанию, согласен.

(322) Я настойчивый...Предлагаю только то, что реально  работает у моих клиентов. Бэкапы не только ночные.

(326) Ну тогда повторю еще раз: в бэкапе (ночном, дневном и любом другом) нет последних трёх документов. А в битой базе они есть.

Его философия понятна, нафига бэкап если он может оказаться битым. Значит бэкапы - зло. Дурдом.

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

Кто б про упертость говорил.
"Я где-то на предыдущей странице предположил, как будет развиваться процесс по сценарию ночного резервного копирования"
Ты привел череду отказов один на миллион и сказал - ага, ковно ваш бэкап.
Я привел отказ один на сто, когда база однажды не восстановится. Ты сказал - фигня, заменю новой.
Заметь, я не предлагаю бэкап (уже понял, что тебе - бесполезно).
(327) "А в битой базе они есть."
Ахахаха. Если включено виндовое кеширование записи на диск, в битой базе может не оказаться ни следа документов за последние пару часов.

(317) Болит голова. Медицину не предлагать.

Но я надеюсь, что хотя бы кеширование у тебя отключено

(328) "Значит бэкапы - зло" - нет, это значит что бэкапы, в данном случае - не решение.

(330) Нет, "Болит голова. Отжимания от пола не предлагать"

Мной вся тема прочитана... Один вопрос к автору, только прошу не ругаться, почему пытаетесь устранить следствия а не причины?

И ведь написано - "У меня куча файловых баз. " И они все непрерывно ломаются. Он их чинит. Он походу мазохист или лентяй или не грамотный.

ТС в (310), а именно в пункте 1 очень хорошая идея для Вас, из затрат только время.

(335) Зато всегда при работе

1. (334) +100500 Проверка памяти и дисков. Замена неисправных. Установка ИБП как страховка от проблем по питанию.

Дополню (310) Без бекапов действительно страшно. Алгоритм следующий:
1. Делай бекап раз в сутки.
2. При записи документа\справочника, сериализируй его и выгружай. в конце архивируй и подкладывай данные к бекапу.
3. После или перед бекапом тестирование\исправление. По результатам понятно следует ли поднимать базу из бекапа и накатывать, все, что было после или нет.
Всю эту историю можно хранить к примеру за месяц.

(338) Не нужные ему бэкапы, для него они не имеют смысла.

(335) А тётенька которая думает что бэкапы - панацея от всех бед, грамотая?

(336) Спасибо, мне это уже в сообщении (310) и (324) написали.

(340) Тебе уже и бэкапы не помогут.

(340)Передергиваешь зачем? Тебе не говорят, от всех бед. Тебе говорят, что в них есть смысл. "Есть смысл" <> "Панацея от всех бед"

(341) И? Этот путь имеет смысл?

(343) Там где в них есть смысл, там они есть.

ТС до сих пор так и не понял, для чего нужны бекапы и как с ними работать?

(346) Великолепно, еще один. Расскажите пожалуйста, уж не побрезгуйте!

(344) Выглядит перспективно.

(0) 1. "У меня куча файловых баз. И они постоянно бьются."
Но с этим ничего делать не будем, ведь так?
   2. "Раньше после восстановления утилитой chdbfl пропадала часть данных, но не критично. В последнее время... бьется серьезнее"
Вот судя по всему главная проблема автора. То что ранее помогало перестает помогать.
   3. "Если база будет утеряна, скорее всего всё равно придётся менять диск"
Т.е. вопрос о смене оборудования рассматривается...
   4. "Ну какой терминал если там один комп с базой?"
Куда делась "куча файловых баз" или она на "куче" компах с одной и той же проблемой?
   5. "Да там ведь не один такой комп, а проблема усугубилась на всех."
Ах вот же они.
   6. "Понимаете, какая беда - ломаются они "УПСы" гораздо быстрее, чем компы"
   7. " восстановление базы почти ничего не стОит, а стабилизатор стОит,"
Вот тут денежный вопрос судя по которому наверное не устраняется причина поломок.
   8. "Файловые базы по большей части бьются при неожиданном прекращении работы"
И вот похоже первопричина всех бед "неожиданном прекращении работы"

Спрашиваете есть ли "хорошая идея по этому поводу" и "решение, которое позволит пользователю работать после восстановления БД без танцев с бубном".
Если будете лечить симптомы а не саму болезнь то никогда не выздоровеете...

В нормальном режиме работы файловая живет вечно. Если сети нет, то может с диском что-то, а еще спящий режим, например.

(349) Ну то есть, кратко "у меня нет варианта".

(350) Попробуйте включить проведение расчета себестоимости и снять задачу, а потом проверить базу chdbfl. Думаю, будут ошибки.

(352) Заявлено было, что базы почему-то падают.
А попробуйте дождаться результата.

(352) Ясен пень будут, особенно если на этапе создания ключей грохнуть базу.

(353) +100500 )))

(353) Ну наверное организация рано или поздно завершит свою работу и выкинет компы на свалку, я так думаю. Или вы про то, что комп сдохнет? Ну так это рано или поздно случается.

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

(352) Зачем вы снимаете задачу при расчете себестоимости?

(357) Это вообще имеет хоть какое-то отношение к делу, или просто начались неконтролируемые фантазии?

(358) Мучают кошмары?

(360) "Попробуйте включить проведение расчета себестоимости и снять задачу" - Это кем написано? Отсюда и вопрос.

(359) Это имеет непосредственное отношение.

Есть предположение, что ТС или пьян или с похмелья или просто заговаривается ...))

(351) Вариант - устранить проблемы ведущие к поломкам баз. А пути устранения уже предлагались неоднократно.
Но Вам то нужен способ "чудотворного восстановления"...

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

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

(361) читаем:
"В нормальном режиме работы файловая живет вечно. Если сети нет, то может с диском что-то, а еще спящий режим, например."
ещё читаем:
"Попробуйте включить проведение расчета себестоимости и снять задачу, а потом проверить базу chdbfl. Думаю, будут ошибки."

если опять непонятно, то ещё читаем.

(364) Ну так да.

(367) Т.е ты считаешь, что выключение питания во время расчета это нормальный режим?
" читаем:
В нормальном режиме работы файловая живет вечно"

Пьяный, короче или хм....

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

(371) У тебя нет задачи, просто дурь в голове и все.

(370) На вашем месте я бы лучше пошёл почитал про стратегии резервного копирования хотя бы в Books Online, а то всё пишете "делай бэкапы!", а что такое бэкапы - толком не знаете.

(373) Зачем свою элементарную неграмотность прикрывать умными заявлениями? Умнее не станешь.
Скучно тут. ))

(374) Я у вас это кажется ещё на первой странице спрашивал. А потом на второй и на третьей. Но вы кроме слова "бэкап" ничего не знаете и оно вам очень нравится. Как в анекдоте "тётенька, а ты еще какое-нибудь слово знаешь - ВАДАЛАЗ!"

(375) Расскажи анекдот))Я такой что-то не слышал)))

(0) Открывай новую тему, эту тетенька из (2) увела не в то русло.

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

(378) Начни с малого: с покупки УПСов. Думаю, что бОльшую часть проблем с электропитанием это отсечёт. Если же нужна бесперебойная работа 24/7 тогда ещё помимо упсов нужен дизель с автоматикой.

(379) Моя бы им счеты купить...

(373) Ну если бэкапы не катят, то архивы делай.

+(381) Ну если это не нравится, то перейти в ручной учет. Завести амбарную книгу и сейф купить несгораемый, чтобы книга осталась цела. Нуда на сейф тоже деньги нужны)))

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

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

(384) комп с конфликтным железом/дровами ее укатает "на раз"

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

(384) надежно - это не 100% гарантия.

(349)Очень героично создаем проблемы и так же героично с ними боремся, новой версией чекдбфл например

(385) Я же говорю - при грамотной эксплуатации.
А если вы экслпуатируете ее неграмотно, то конечно она будет сыпаться.

(387) 100% может дать только Бог.
А все остальное - менее 100%.

(380) Всё, ваша меня утомила. Действительно, иногда лучше жевать, чем говорить.

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

(392) А ты образованная?

(391) Поделись, что решил сделать? :)

(378) Бекапы в файлово?
Да нафига?

1. Лучше вообще-то раз, один раз синхранизировать справочники с другой БД, удаленной.

2. Запретить вводить новые элементы справочников, или предусмотреть такую выгрузку.

3. И регламентным заданием, выгружать в файлики формата XML набитые документы за день.

4. потом их либо подтягивать в рухнувшую БД, либо отправлять в центральную БД :)
Это уже тебе придумать, как быть :)

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

+(395) >>> выгружать в файлики формата XML набитые документы за день.

Можно писать их в XML каждый раз при нажатии кнопки "Записать"

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

(395) Это всё есть, вопрос в том как быстро вернуть базу в рабочее состояние.
Кстати, поклонникам ИБП: 1С не умеет завершать работу, если открыто модальное окно. Неприятно, но факт.

(399) Быстро? Иметь тупо копию БД, на утро. На вчера. Без документов. Документы там ненужны. Они все в файликах, готовых к выгрузке :)

Или вообще иметь только заготовку со справочниками :)

(399) >>>1С не умеет завершать работу, если открыто модальное окно

Не используй предупреждения. А коль используешь, то выставляй таймер :)

о, ветка еще актуальна, продолжайте, я за попкорном.

(401) Справка - "О программе" тоже не использовать?

(403) Её что, каждые две минуты открывают? Что за бред.

ОФФ:до пятницы дотянет?

(405) Обязательно, мы наверняка узнаем много нового, бэкапы не просто бесполезны, но и даже вредны; в ит инфраструктуру вкладываются только слабаки; любую БД можно спокойно потерять и восстановить такую же на следующие день, а кто не может тот просто не работал программистом с 2004 года и нипанимаит.

(404) А файловые диалоги?

(402) Что-то поздно, угар-то уже вроде как поугас.

(406) Я тут уже людям с гуманитарным складом ума указывал на то, что говорю не про ЛЮБУЮ, а только про свою базу. Но медицина тут бессильна - "Бэк-ап чем-пи-он!"

(408) да, было весело

(408) но впереди пятница

(0) Автор проблему то решил - не?

(412) Автор не сидит у разбитой базы, вырывая последние волосы и не кричит "что делать", автор изучает перспективы.

(412) ... и ещё людей с гуманитарным складом ума.

(431) Ты уже 3 дня изучаешь базы от этого биться не перестанут)

(415) "Что тут думать, бэкап делать надо!"?

(416) Никогда!!! Слышишь? Никогда их не делай. Сиди и думай и изучай перспективы ))))
И все-таки, давай, держи ветку до пятницы!

(404) Бред в (2) и далее любой твой пост.

(418) Речь о модальных окнах которые открывает пользователь, он же может и закрыть их при пропадании электричества.
Если ты какой-то своей обработкой их открываешь и не заботишься о закрытии, сам себе злобный буратина. Упертый под стать ТС. ))

(419) Что еще скажешь?

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

Ты может клон ТС?

(422) Ага, конечно. Шаблонное мышление и здесь.

(422) Может это ТС с другого аккаунта?)

Ты еще скажи что (421) тоже клон. И вообще все, кто в этой теме клоны, кроме тебя, конечно.

(424) Оч похоже. Прям близнец...)))

(426) Возможно просто друган - оба из кемерова )))

(427) Возможно ))) Но двое таких в одной ветке это не перебор?

(419) У вас там пользователи смирительной рубашкой к 1С прикручены?

(427) Будь осторожен, так и тебя в клоны запишут :)

(429)(430) Эй, эй ребята, потише... не так быстро )))

(431) А то что?

(428) как минимум подозрительно)
(430) меня нет, я за бэкапы)

(405) Скорей всего да :)

(417) В его случаи ненужны бекапы :)

(433) А кто против бэкапов?

(436) Necro писал:
"в бэкапах тоже большого смысла не вижу."

(437) Да что вы так, ну ненужно в БД бекап 1С, когда все пишется интерактивно в другие источники информации.
При этом все что нужно Кладовщику, это справочники. И липовые остатки, хотя бы на утро :)

(437) Перечитай теперь и остальные сообщения, но только не там, где флуд. Включи мозг, подумай.

(436) Да твой земляк вроде не в восторге от них) Ты не парься,  ты ж не против)

(440) Сколько у тебя занимает действия, указанные в (421) ?

*занимают

У тебя не возникало мыслей как-то автоматизировать эти действия? Или у тебя уже автоматизировано?

(441) Нет у меня мысль только исключить эти ситуации и я уже перевожусь на скуль. Это решает проблему

Как часто делается бэкап файловой базы на точке? Проверяется ли целостность бэкапов?

(444) 50 * 14400 = 720000. Да и у тебя же наверняка не по одному пользователю на базу?

(445) Раз в сутки бэкап. Ну и база РИБ. Т.е. все данные в центральной есть, обмен с ней раз в час. (бэкап на тот случай, если обмены не ходят).
(446) у меня на базу в основном 1 пользователь, есть по 2.

(445) целостность не проверяется. Просто копия файла

(445) Но на файловой оставаться не собираюсь. Много гемора. При любом раскладе только одна утилитка может пол часа- час работать, не говоря уже обо всем остальном. Когда база была маленькая - не сильно парило, сейчас - не вариант вообще

сорри, все не осилил, но относительно бекапов: регулярный обмен с централкой спасет отца русской демократии?

(450) к (24)

(450) Уже предлагали. ) " автор изучает перспективы"

(450) Спасет, но не всегда, если связи нет, то за все время отсутствия связи потеряешь данные

(439) Госпади, он сам написал бэкапы не предлагать меня от них тошнит, в чём вопрос?

(452) спасиб,

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

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

(457) чо за паника?! частота проверки определяется договоренностью и к тех части отношения не имеет.  это вообще не тс может делать

(458) А в чем паника? По мне, так это нормальное отношение к делу. Зачем гонять людей, когда комп может сам все за тебя бэкапить. Не понятна паника по отношению к настройке бэкапов

(458) Настроенный бэкап, есть, пить не просит. Тихонько делается и никому не мешает.

(459) как писал ТС,
1. Он честный
2. Только файловая, только хардкорд
3. Бекапы тоже могут быть уже битыми. К примеру в Понедельник был скачек электричества. Потом сделался быкап. А уже только во Пятницу заметили ошибку. Либо уже наконец достало, что 1С отваливается и соизволили позвонить :)

(460) Настроенный обмен, есть, пить не просит. Тихонько делается и никому не мешает.

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

(431) Надеюсь, ваше начальство или клиенты ваш ник не знают? А то спать будут плохо - "не закрываются партии - бэкап! не заводится машина - бэкап! сколько вам лет - бэкап!"

(421) Вот это дельный вариант - перед проверкой перезаписать пользователей, спасибо!

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

(463) Остынь, парниша. Не кипятись так. Вредно это. И кроме того пацанчики так себя не ведут.)))

(466) Тебе от ПМС бэкап помогает?

(467) О, и братишка ТС нарисовался.

(468) Ну так помогает или нет?

Ты не стесняйся, рассказывай.

(421) сорри, тока ща увидел, у нас даж расхождений нет :)

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

(466) Тётенька, вы там ещё не надумали почитать про то, что собственно такое бэкапы, какие бывают и зачем нужны? Пятистраничную техническую тему в цирк с конями превратили. Талант прямо!

(471) В теме уже перечислены все возможные виды решений, но из-за флуда типа (468) их просто не видно.

ОФФ: Набросились на даму ))

(472) Тетя? Я думал там бородатая тетя :)

(473) Делай голосовалку с перечнем выбранных вариантов.

(468) Вы сами-то бэкапы делаете? Какое у вас запланированное время простоя? Сколько данных запланировано потерять? Как проверяется работоспособность копий? Какие сценарии покрыты бэкапами, какие нет?

(473) Вот тебе нормальное рабочее решение
1)Сделать так чтобы базы не бились - нормальное электропитание, ИБП, хорошая сеть, мониторинг дисков.
2)Делать бэкапы раз в день, и теневые копии каждый час.
3)Настроить автоматическую проверку баз на ошибки - чтобы в случае падения сразу же определить побилась база или нет.

(475) Женщины-старообрядцы не стригут бороды :)))))

(461) по пункту 3 - бэкап до скачка и данные после скачка помогут восстановить картину при необходимости. Никто не мешает еще и бэкапы проверять, лично я не против такого решения )
(471) Да ничего. Все нормуль

(478) Я же говорю - варианты перечислены. Пункт 2 - не нужен, пункт 3 - это вообще как? Как определить что 1. база могла побиться 2. что она побилась? У нас вроде есть одна единственная штатная утилита, но долго работает и не имеет пакетного режима.
Или при каждом запуске программы попытаться перезаписать в ней все данные? )

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

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

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

(471)  Не, копировать централку не очень, ведь в удаленной, хоть и битой, но есть неотправленные данные, которые при моем способе не пропадают

(482) >> По поводу проверки работоспособности - запуск из батника конфигуратора в режиме тестирования.

Это не избавляет от проверки утилитой проверки физической целостности.

(482) Мне от конкретного упёртого пользователя, который по всей видимости недавно узнал волшебное слово "бэкап" ответ хочется увидеть. Правда до этого этот пользователь ответов по существу не давал.

(481) Это конфигуратор то не имеет пакетного режима? Или в конфигураторе нет инструментов для определения битой базы?

(486) Да, в конфигураторе нет таких инструментов.

(483) Как конфигурацию обновляешь?

(488) Обученные пользователи на обновление конфы. Там 3 действия всего.

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

(488) Если кто подскажет по этому вопросу - буду благодарен

(491) По идее надо с обменом отправлять, чтоб по окончанию обмена перезапускалась и обновлялась. Есть время на обмен - найдется и на обновление.

(490) Проверяй КонфигурацияИзменена() после чтения сообщения обмена.

(493) Там не РИБ

(491) А ведь ты похоже мой клон!

(492) так нельзя. Там если очередь стоит, то будут проблемы. Обмен то автоматический, раз в час, никто даже не замечает его....работаю и работают. если не провелось из-за блокировке, еще раз кнопку нажали и дальше работают. А тут программа закроется, и работать не даст совсем. Нужно дать пользователю выбор, когда обновить конфу, или при закрытии программы как-то делать

(495) Даже не надейся ))

(496) А автоматический обмен как реализован?

(494) Для чего нужен РИБ с двумя планами обмена: РИБ и НеРИБ ?

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

Что-то градус неадеквата резко упал, до пятницы не дотянем )

(501) Подлей огоньку :)

(499) В принципе можно конфигурацию и так в сообщении передать - как элемент справочника, или даже просто прицепить к файлу обмена.

(490) Как вариант - обновление в планировщик на ночь.
Если не устраивает - большая кнопка для пользователя на рабочем столе, которая при запуске сообщает пользователю примерное время обновления, и если он согласен запускает.

(502) Тётенька DDwe видать ушла проверять всё то, что я написал, и обнаружила, что бэкап - это не кактус у монитора.

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

не дотянули до пятницы, жаль.

(507) (;_;)