|
Падение бекапа, ошибка General Write
|
|||
---|---|---|---|
#18+
Добрый день, коллеги! Пожалуйста, подскажите в чем проблема. Есть Cache for Windows (x86-64) 2015.2.1 (Build 705U) Настроен полный backup одной БД (50гб) - один раз в день. Инкремент - раз в час. Есть два диска: С - на нем свободно 90гб, D - свободно 200гб. Backup настроен на диск D. Задача падает с ошибкой ОШИБКА #7327: BACKUP^DBACK завершилась неудачей (см. лог внизу) Причем на диске D файл появился (50гб) (выполнялась операция 30 минут как и в хорошие времена). Через час выполняется инкрементальный - и почему-то тоже весит 50гб и падает с ошибкой и вся система в это время тормозит (выполняется не за минутку, а тоже где-то 30 минут). Инкремент с полным не пересекаются по времени. Такое повторяется раз в месяц, ребут помогал раньше, сегодня что-то нет... как дальше жить Лог: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28.
... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2016, 17:33 |
|
Падение бекапа, ошибка General Write
|
|||
---|---|---|---|
#18+
Алексей М.Ф., Судя по логу было записано примерно 53ГБ в бекап, предположу, что бэкап то выполнился полностью, только с завершением файла возникли проблемы. То что инкрементальный большой, с одной стороны не удивительно, когда полный по мнений Caché не выполнился. Я не знаю, что у вас за диск D, с учетом такой необходимости бэкапить, предположу что это внешнее хранилище, SAN какой-нибудь (надеюсь, иначе какой вообще смысл). Тогда нужно смотреть логи системы, на наличие ошибок контроллера, в общем всего что может быть связано с этим диском, может быть он отваливается. Я конечно понимаю, сохранность данных превыше всего, и поэтому наверно есть смысл в таких бэкапах. Но может, если так все серьезно стоило было задуматься о зеркале. Несколько попроще с восстановлением по крайней мере было бы. ну или хотя бы просто автоматически файлы журналов просто бэкапить. Их будет достаточно для восстановления данных при наличии ежедневного бэкапа, и файлов журналов после его выполнения. Просто накатываются из них после восстановления базы. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2016, 19:35 |
|
Падение бекапа, ошибка General Write
|
|||
---|---|---|---|
#18+
DAiMor, Раньше был просто диск С на него же всё и делалось, т.е. путь по умолчанию использовался для бэкапов. А потом утилита одна перебрасывала на сетевой диск это всё. База раньше была меньше, места хватало. Ошибка с бэкапом тоже была. Потом админ прикрутил второй физический 300гб (D), теперь на него бэкапится и оттуда куда-то на сетевой потом уходит всё. Зеркало вроде будет, но в следующем году... Куда копать... Вот выйдет 2016.2 - поставлю, может полечится. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2016, 09:30 |
|
Падение бекапа, ошибка General Write
|
|||
---|---|---|---|
#18+
Алексей М.Ф.Куда копать...Исходники DBACK/DBACKC.int открыты. Например, ошибке с текстом "General Write" соответствует код -2, он же RCOUTERR, возвращаемый $zu(32,...). Проверьте железо и БД/[файл CACHE.DAT] на предмет ошибок. Промониторьте процесс бэкапирования: Monitor Backup or Restore Progress Using ^BACKUP PS: 13653070 , и конечно WRC. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2016, 11:49 |
|
Падение бекапа, ошибка General Write
|
|||
---|---|---|---|
#18+
Если посчитать скорость бэкапа, получается около 25MB/s. Это очень медленно, даже для обычного SATA-диска. Наводит на мысли, что действительно надо пристально смотреть, что с ним не так, конкретно с этим диском. У меня когда-то было подобная ошибка, но в другой ситуации: сетевой диск, расшаренный через самбу, неверно возвращал информацию о свободном пространстве. Давно это было, уже не помню, как выкрутились; кажется, перешли на локальный бэкап с последующим rsync. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2016, 16:14 |
|
|
start [/forum/topic.php?fid=39&fpage=9&tid=1556427]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
54ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
49ms |
get tp. blocked users: |
2ms |
others: | 281ms |
total: | 434ms |
0 / 0 |