1С8, SQL2005, бекапы собаки такие по 3 Гига. ВЫгружаю через конфигуратор - 150 Метров. Сейчас возникла задача хранить каждодневные бекапы за длительный период. Вот думаю через что лучше это делать.
Возникает два вопроса:
1) Насколько надежны SQL-бекапы? Насколько верно сохранится информация, если она в этот момент изменяется пользователями?
2) Насколько надежны dt-шки?

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

(1) Не понял про список юзеров. Как нет?

(1) все есть, только при восстановлении из *.dt очищается журнал регистрации

разница только на ЖР?

а плане надежности есть какия нибудь разница?

да. попутал слегка, сорри :-)

(0) Просто жми их чем то. У меня комплит в 20 гигов ужимается до 1.5 гигов. Естественно, все делается батником по ночам.

sql

1С вроде SQL - рекомендует, так же как и копирование файловой версии, а не DT.... на ИТС что-то было...

хотя не значит, что это правильно ;)

(7)Crjkmrj ;vtncz gj dhtvtyb

(7)Пардон, а сколько по времени сжимается?

в sql ЖР сохраняется что-ли?

(12) без понятия - у нас админ серваками и бекапами занимается

(11) 40Г сжалось до 3Г примерно за пять часов :)
Правда, днём и при работающих пользователях.

(7) (14) чем жмем?

(15) Жму раром. Жмется где то час - полтора.

(15) Аналогично с (16)

А вы сравните скорость разворачивания бэкапа из dt и из SQL-бекапа.
В плане надёжности: если уж бэкап сделался, то скорее всего из него удасться восстановится.

>>Сейчас возникла задача хранить каждодневные бекапы за длительный период.

нафига это надо...

(18) >>В плане надёжности: если уж бэкап сделался, то скорее всего из него удасться восстановится.
все равно какой бекап?
(19) чтоб доказывать, что мы не ослы, так как данные портят

(19) +1 Ну за неделю, ну за месяц+ежегодно мож еще. А КАЖДОДНЕВНЫЕ-то нах? Паранойя?

(20) Все равно. Я битых dt за 3 года ни разу не видел...

(18) Если ты про dt - то сохранение базы в dt не гарантирует, что можно восстановить базу из этого dt. Т.к. если база с ошибками, то эти ошибки переносятся в dt. А при восстановлении достаточно одной ошибки чтобы никогда нельзя было востановиться из этого dt.
Вывод: лучше сохранять первоисточник.

(20) Храните полные бекапы недельные + бекапы журналов транзакций (full)

А можно купить что то вроде http://infohardware.ru/razdelg/view/0020/ и не париться о свободном месте. Мы себе недавно купили на 2 терабайта стоит где то 20000 р.

По пятницам фул бекап, и каждый день инкременты... можно и дифференциальные, они меньше, но их накатывать дольше

в (18) второе утверждение совсем не верно...

(26) Там написано "скорее всего" - как такая фраза может быть совсем не верной?
У вас есть данные, что как минимум 50% плюс 1 сделанных бэкапов битые? :)

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

(24) +1

Вообще-то SQL бэкапы тупо удобнее - а для dt - один способ бэкапа - full.

А в dt бекапится, если есть пользователи в базе?

(31) Я думаю его уже уговорили :)

если база кривая, то из dt потом не загрузишь, а SQL на это пофигу, он что было то и восстановит.

(33) если смог выгрузить в dt, то сможешь и загрузить из него

(34) нет, были случаи, что из dt не восстанавливалось.
В 1С при этом совершенно серьёзно отвечали, что "выгрузка не является средством создания резервных копий".

(35) на какой платформе были такие случаи. Помнится я на одной своей работе что то подобное слышал. Тогда был релиз 8.0.8

(35) ИМХО, ошибка из-за винта. Более серьезные системы при записи всегда перепроверяют нормально ли записано (запись->чтение) и при траблах сигнализируют о неприятностях. Думаю, что в случае работы с файлами рабочими 1С это выполняет, но при выгрузке точно нет. А зря...