Доброго времени суток. Комплексная 2.2 в клиент-серверном варианте, платформа 8.3.17.1386 х64. Делал обновление, в процессе обновления оказалось, что места на диске С нет и обновление вылетело с ошибкой. Решил загрузить бекап, созданный перед обновлением, однако к моему ужасу практически сразу система выдала "Неверный формат файла для загрузки информационной базы. Ошибка формата потока". Кеш почистил, но dt-шник отказывался грузиться. Попробовал в новую развернуть - результат тот же, в файловую - то же самое. Ощущение, будто он выгрузился битым, хотя размер 2.14 Гб, как и у предыдущего от 6 декабря, который, кстати, успешно загрузился. Вопрос: есть ли возможность как-то восстановить битый бекап, и как вообще можно решить такую проблему?

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

(0)   восстановить битый бекап: dt - сжатый дефлейтом текст(упрощенно).
с помощью тж выясните. что не нравится 1с и исправьте в тексте dt.

(1) А в каком формате самое надежное? Конкретная задача - есть база SQL, нужно сделать копию в файловой базе.

(0) А с базой-то что? Хотя после загрузки dt..

(0) бэкапов СУБД нет? Если МС-СКЛ - модель восстановления какая?

(2) >исправьте в тексте dt.
дт - не текстовый файл а архив... и править его ручками - ну-ну

(6) Архив, а внутри текст, как утверждается в (2) То есть, распаковать, поправить, запаковать обратно, попробовать.

Вообще, схема похожая. В 7.7 так же было с выгрузкой, текстовый .dat внутри .zip.

(7) ты там рылся хоть когда-то? Ты очень понимаешь в каком месте рыться что-бы поправить?
PS Один раз "корректировал" выгрузку ИБ на Постргри в текстовый файл (это было всё что от базы осталось актуальнее чем бэкам давности дней в 10) - наверное на порядок проще но и этого опыта мне хватило!!!

(4) восстановил на 6.12, база работает, но документов на 7-е число в ней, разумеется, нет. Чтобы хотя бы Турбо XML перенести, тот битый бекап развернуть бы где-нибудь...

(8) Ну у ТС другого варианта нет, если хочет достать данные, придется рыться

(9) один день некритичен. Только, если там нет маркированной продукции.

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

(12) Бэкап только средствами скуля. Выгрузка в ДТ это категорически не бэкап.

(12) dt через сеть не передавали? Может у вас сетевуха портит данные? Такое бывает, редко но случается.

(14) нет, выгружал на локальный диск.

(15) бэды на диске?

(16) не проверял, может быть. Это первый раз, когда дтшник битый на этом серваке создался, всегда всё нормально было.

(15) ну, причина понятна из (0). Нет места на диске С.

(12) 1С писала что порядка 1% ДТ не смог быть развернуты обратно

А что, интересно, 1С рекомендует для файловых баз? Копировать 1CD?

(20) именно

(20) Администрирование - Обслуживание - Резервное копирование и восстановление

Как говорти мой знакомый админы делятся на три категории, те кто делает бекапы, те кто не делает бекапы и те кто проверяет бекапы

(3) >> Конкретная задача - есть база SQL, нужно сделать копию в файловой базе.

И причем здесь создание архивных копий?

(24) Ни при чем.