Acronis Cloud Backup #789889

Навернулась база. Бэкапы делались автоматически с помощью Acronis Cloud Backup - образ диска. После восстановления запускаться не хочет - говорит, база повреждена. Попробовал поиграться с другими базами (рабочими) - версии из бекапа какие-то работают, какие-то нет. Причём симптомы разные. Некоторые с помощью chdbfl вроде лечатся, в конфигуратор заходит, но при попытке выгрузить или открыть предприятие - вылетают с ошибкой а-ля "повреждена таблица const1234". На некоторых и chdbfl выдаёт ошибку почти сразу. Нашёл вчерашний бекап базы, которая не менялась. Сравниваю жиаой и восстановленный 1Cv8.1CD. Время изменения и размер вплоть до байта одинаковый. Но посимвольное сравнение выдаёт достаточно много отличий. Вопросы. 1. Сталкивался ли кто? Можно ли восстановить такую восстановленную акронисом базу? 2. Подскажите инструменты, с помощью которых можно попробовать восстановить.

Вот сделал пару скриншотов. Попытка зайти в базу после бэкапа: Лечение chdbfl Попытка открыть предприятие после chdbfl Непонятно. Может акронис как-то где-то кодировку меняет или что ещё? Из-за чего такая фигня возможна и как лечить?

Может спросить у Акрониса?

Акроникс придумал теневое копирование, и даже последние его реализации в Windows сделаны по их идеям. Смысл теневого копирования в том, что система запоминает состояние диска на определённый момент времени, а всё, что после - пишет в другие сектора, обеспечивая целостность и неизменность теневой копии. Но, если в процессе копирования 1С не была закрыта, то система теневого копирования ничего не знает о страницах с данными в памяти 1С. Причём, может оказаться, что часть страниц успела записаться, а часть - нет. В результате, будут или неполные данные или, в худшем случае, несогласованные части файла. Но, если из MD доставать данные по блокам, то можно отследить, что менялось.

Судя по всему у вас SQL база, а бэкап SQL базы делается исключительно средствами SQL, если вы делаете его акронисом - это в принципе нормально что он не восстанавливается. И проблема тут не в акронисе, а в SQL. Ахренть. >>Акроникс придумал теневое копирование, и даже последние его реализации в Windows сделаны по их идеям. Это пять! Теневое копирование - штатная функция файловой системы NTFS. Реализована разработчиками NTFS. Используется для резервного копирования как штатными механизмами Windows, так и сторонними разработчиками софта под windows - всякими акронисами, кобианами, и.т.п. Даже я в своих скриптах ее использую.

С файловой 1с теневое копирование работает отлично. Насчет акрониса не знаю как у них там реализована работа с ним, но штатное теневое копирование прекрасно копирует файловые базы. Открыта база или нет - значения не имеет. Перед созданием теневой копии все буферы сбрасываются на диск принудительно, сама копия создается мгновенно. В результате база всегда рабочая. А вот данные запись которых производилась могут оказаться неверными - прервали запись. На саму структуру базы и ее работоспособность это не влияет.

Ни в какой NTFS изначально никакого копирования вообще не было. То, что потом в Windows придумали отдельную службу и изменения в драйвер, не означает, что NTFS проектировалась сразу с возможностью BackUp-а. В NTFS, как и в любой нормальной системе у файла может быть несколько потоков данных, а также на один файл можно ссылаться из нескольких мест. P.S. не забываем, что Norton Unerase был сделан ещё до того, как NTFS вышла в серию, и успешно делал некоторые попытки аналогии с теневым копированием на FAT32, только через перехват обращений к диску.

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

>>И если кто-то верит, что журналирование, заявленное в NTFS как-то спасает данные.. А с каких это пор журналирование стало спасать данные? Задача журналирвоания - содержать файловую систему в рабочем состоянии, невзирая на всякие катаклизмы, вроде внезапных сбоев питания.

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

Акронис вещь в себеЯ бы не стал ему доверять в критичных моментах

не угадали. Базы файловые. В я же пишу - сравнивал файлы 1Cv8.1CD Лучше посоветуйте, что теперь делать.

понять и простить

Начнем с начала. Какого вообще вам бэкап потребовался? Что у вас такого случилось что за бэкап схватились? Диск исдох? Так может база уже давно была с проблемами? Пробуйте восстановить из более ранних копий.

Спасибо. Да, вероятно, база уже какое-то время была с проблемами. База накрылась при обновлении. Перед обновлением выгрузилась в dt без проблем. При попытке восстановить из только что сохранённого dt вылезает ошибка, что не все данные загружены. И действительно многих данных нет. После этого решили восстановиться из акронисовских бэкапов. Т.е. сейчас есть dt, который наполовину грузится и есть бекап файловый базы 1Cv8.1CD, который не работает (описание выше) Мне показалось, что проще пробовать разбираться с акронисом, чем с битым dt. Но если есть инструменты для отладки загрузки dt, подскажите, буду рад попробовать. п.с. То, что база была проблемная уже какое-то время не связано с косяками акрониса - т.к. попробовали бекапы акрониса здоровых рабочих баз - они тоже не работают. ппс. Попробовали подоставать разные бекапы акрониса - на октябрь 2016 работает, но это огромный массив потерянной информации.

Повторю основные вопросы сообществу: 1. Сталкивался ли кто с проблемой использования Acronis Cloud Backup, если да, то нашли ли решение проблемы. 2. Есть ли инструменты/механизмы для работы напрямую с dt или 1Cv8.1CD - может можно открыть 1CD в каком-нибудь редакторе, где-то там кодировку сменить и EOL добавить/убрать - и всё заработает.

А у вас кроме баз что-нибудь бэкаптися? Другие данные восстанавливать пробовали? Может акронис тупо портит данные? Храните бэкап локально? Диск с бэкапами, и диск на который восстанавливаете проблем не имеют?

Утилита Acronis Cloud Backup Бэкапы делаются в облако, бекапится целиком раздел жесткого диска. Восстанавливать можно как весь раздел целиком, так и отдельные файлы. Пробовали восстановить раздел целиком - эффект тот же. Может и тупо портит.

Попробуй пообщаться с техподдержкой акрониса. Вот эта фраза - "Сравниваю жиаой и восстановленный 1Cv8.1CD. Время изменения и размер вплоть до байта одинаковый. Но посимвольное сравнение выдаёт достаточно много отличий. " наводит на нехорошие мысли.

наводит, да. До акрониса дозвонились. Общался не я. Со слов человека, который общался - ничем помочь не могут

Так а поддержка акрониса что говорит? Т.е. деньги получили, а работает-не работает?

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

Нашёл клёвую статью по восстановлению битых баз Попробовал утилиту Tool_1CD.exe - тоже ноль, не открывает.

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

есть ли методы обратной раздедедупликации?)

Дедупликация это хорошая нормальная метода, когда читаешь - читается все что было записано. Но в некоторых реализациях дедупликации до сих пор находят глюки. Вызывающие порчу данных. Например в виндовой дедупликации которую я плотно использую, я почти сразу нарвался на грабли - портила файлы VHDX при попытке их дедуплицировать, все сотальные файлы при этом читались нормально, а VHDX убивались в хлам. Слышал что подобный косяк с определенными данными был у NetAPP. В общем бывает.

У меня сейчас практически все локальные архивы 1с и документов дедуплицированы,

Ставил я этот Acronis (лицензионный). После его установки винда перестала загружаться. Еле снёс

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

Не понял сути, можно более развернуто?

Акронис не укры делали? Которые выкопали черное море, придумали колесо и шэдоу копи?

в случае полной копии это неактуально. а что там у автора? каким методом копии писались?

Создание резервной копии основано на том, что система при записи в файл перераспределяет его пространство, чтобы запись шла в новое место. При этом, остаётся как бы две версии файла, но у них общий кусок. Когда пишут несколько процессов, то одновременно могут писаться несколько кусков файла - понятно, что диск один и все записи попадут в очередь, но никто не обещает, что запись в первую часть файла окажется ранее, чем запись во вторую. Соответственно, система должна перераспределить файл, но при этом, также должен быть обновлён кеш в памяти, что, скорей всего, не делается, и в памяти остаётся старая часть файла, а другой процесс записи, её читает и перезаписывает, что приводит к попаданию в файл неверных данных. То есть проблема, скорей всего, в том, что файловый драйвер меняет расположение блока в файле.

У автора, скорей всего, был просто побитый файл, и как бы он не писался, он из побитого целым не станет.

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

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

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

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

Сервис Acronis Cloud Backup, без понятия, как он там делает копии. нет, потом для интереса попробовали разные файлы разных баз - рабочих. Я описывал в подробно. То, что эта технология изменяет файлы - факт.

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

Спасибо.

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

Мы акронисом еще версии 6.0 делали образ системного раздела Windows 2000 Server. Когда сначала сделали встроенной архивацией, то даже с галочкой Системные данные восстановленная Windows начинала глючить и всякие сыпались ошибки. Стали пробовать все подряд попробовали акронис, пробовали упорно - все работало. Пользовались лет десять, за это время раза три приходилось восстанавливать сервер из резервного образа - все разы успешно. Я же обжегся не раз на этих резервных копиях. Один раз с только с копией трех дневной давности развалился РАЙД в субботу вечером. Нашел по инету контору, восстанавливающую райды, отвезли им диски часов в 23 вечера, к утру часам к 11 они скопировали всю информацию с райда. К слову тогда райд все-таки запустился с исходных дисков, но лучше было подстраховаться. Поэтому лучше забить на все, но удостовериться, что бакапы делаются и все с них восстанавливается.

Ну у меня получается нормально восстанавливать из резервных копий самой винды, неоднократно и в реальных условиях. Так же делается образ диска "на лету" Хотя работа с бэкапами у винды несколько специфична, и не так красиво и удобно сделана как у акрониса. Тут с непривычки можно и не разобраться. Но если разобрался - все легко, удобно, стабильно и совершенно бесплатно. Из минусов - хранение предполагается локальное - на другом диске, сетевой шаре, СХД. А вот если надо бэкапить в облако, да по узкому каналу - приходится извращаться.

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

Отправьте файл в 1с. Они могут помочь с восстановлением базы.

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

ЭЭЭ. Ты о чем? Что за проверка корректности? И коим боком она к сабжу?

Главный вывод из этой истории: виноват админ, который делал бэкапы, но не проверял их работоспособность.

в моем посте есть ссылка кому и чего я говорю, смотри

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

Ничего по ссылке не нашел. Какая нафиг проверка корректности, где она проводится? И какое отношение это имеет к архивации скулем?

Бэкап файловых баз делается методом копирования файла базы. Бэкап SQL проводится штатными механизмами SQL. Других корректных вариантов архивации нет. Выгрузка в DT используется исключительно для переноса баз из файлового варианта в SQL.

Ладно, рассказываю. Товарищ пишет, что в ДТ выгружать нельзя ибо сама 1с не гарантирует сохранность данных(я это тоже читал). Однако, в версии 8.3.8 добавили проверку целостности базы при выгрузке в ДТ. Если делать бекап средствами скуля - никакой подобной проверки нет. Сам я лично видел, как серверная база отказалась выгружаться в ДТ, потому что одна из служебных таблиц (вроде "Files", не помню) имеет поле неправильной длины (читай, похерены данные).

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

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

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

В моем случае два варианта - или прямая правка в скуле проблемных таблиц или перенос через выгрузку загрузку всей инфы со сбойной базы в чистую копию

толк от проверки целостности = "здоровье" твое базы;)

Эта проверка всего лишь не позволит выгрузить базу в .dt, но никак ее не вылечит. Опять же чтобы не тащить в sql ошибки. Только полная копия .1cd позволит сохранить базу в неизменном виде и запустить (даже битую базу) если она работала до бэкапа.

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

ага, это так кажется... с теневыми копиями вообще все мутно

волшебное слово Comodo Time машин

что там с базой восстановили?

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