Добрый день.
Была настроена регулярная синхронизация с лэптопа на NAS через Synology Drive.
В какой-то момент на лэптопе начал сыпаться диск. Некоторые файлы перестали читаться, но NAS честно отрабатывал и воспринимал испорченные файлы как изменившиеся и синхронизовал их по новой. В итоге когда я обнаружил неполадку на лэптопе, на NASe уже не осталось читабельных версий.
Что посоветуете? Как избежать такого сценария?
Заранее спасибо.
Добрый день.
Была настроена регулярная синхронизация с лэптопа на NAS через Synology Drive.
В какой-то момент на лэптопе начал сыпаться диск. Некоторые файлы перестали читаться, но NAS честно отрабатывал и воспринимал испорченные файлы как изменившиеся и синхронизовал их по новой. В итоге когда я обнаружил неполадку на лэптопе, на NASe уже не осталось читабельных версий.
Что посоветуете? Как избежать такого сценария?
Заранее спасибо.
Просто. Кроме автоматической ежедневной синхронизации рабочего NAS в NAS для backup, я делаю изредка ручную синхронизацию в тот же backupNAS в другую папку.
Недавно старый диск этого backupNAS умер. И я понял, что остался без обоих версий backup. Но так и должно быть --- мой способ backup должен обеспечивать актуальную или устаревшую версию. Есть еще другие хранители backup, из-за сидения дома обновляются крайне нерегулярно.
А вопрос ваш очень акутальный.
Мне интересно: как Drive смог прочитать и сохранить на NAS битый файл, если он по определению не должен был прочитаться: контрольная сумма блока-то не совпадёт?
Мне интересно: как Drive смог прочитать и сохранить на NAS битый файл, если он по определению не должен был прочитаться: контрольная сумма блока-то не совпадёт?
Пример - jpeg, как фото уже не открывается, скорее всего поврежден заголовок. Но Windows их копирует, детали отображает. Поэтому и Drive читает. Думаю так.
Просто. Кроме автоматической ежедневной синхронизации рабочего NAS в NAS для backup, я делаю изредка ручную синхронизацию в тот же backupNAS в другую папку.Недавно старый диск этого backupNAS умер. И я понял, что остался без обоих версий backup. Но так и должно быть --- мой способ backup должен обеспечивать актуальную или устаревшую версию. Есть еще другие хранители backup, из-за сидения дома обновляются крайне нерегулярно.
А вопрос ваш очень акутальный.
То есть у вас backup backup'а реализован, если правильно понимаю. Но ведь здесь битая версия и дальше по цепочке передастся?
Хотелось бы чтобы NAS распознал, что файл в источнике поврежден. А далее восстановил бы битый. Ну или хотя бы запросил пользователя.
Мне интересно: как Drive смог прочитать и сохранить на NAS битый файл, если он по определению не должен был прочитаться: контрольная сумма блока-то не совпадёт?
Что тут странного? Данные читаются с диска блоками, передяются по сети пакетами. Вероятно диск источника при чтении файла натыкается на bad block. Важно данные не исказить.
При переустановке DSM запускаю долгое копирование всех сохраненных данных. Задание новой расшаренной папки либо расшиние поддержки SMB до версии 1.0 процесс копирования прерывает. Получаю сообщение об ошибке только от проводника Win. Далее я могу открыть файл rar-архив в NAS под нужным именем, в котором будет доступна часть файлов.
То есть у вас backup backup'а реализован, если правильно понимаю. Но ведь здесь битая версия и дальше по цепочке передастся?Хотелось бы чтобы NAS распознал, что файл в источнике поврежден. А далее восстановил бы битый. Ну или хотя бы запросил пользователя.
Нет. Раньше я всегда работал с локальными файлами ПК, NAS служил средством сиинхронизации между ПК дома и офиса. А сейчас в основном дома нахожусь. В локальной сети с данными можно работать прямо в NAS. Была проблема возможного отваливания старого NAS DSM5.2 от win10. Оказалась проблема в разных версиях SMB.
Рабочий NAS хранит исходные данные и сам занимается backup в старый NAS. Backup обычный полный не инкрементальный, называется rsync.
Коллеги, но ведь это же бред: ПО обрабатывает заведомо битые файлы и в ус не дует. Неужели нет никакого механизма проверки? Или теперь надо накатывать в Windows отдельную утилиту, которая будет елозить данные регулярно?
Смысл в синхронизации, например, домашних фото - отпадает тогда. У меня тоже синхронизируются файлы с NAS. Не через Drive, сторонним ПО, но смысл от этого не меняется. Какие есть соображения? Создавать аналог CRC-хранилища? Эдакая "банка в банке". То что должно делаться на уровне ОС, мы теперь будем лечить припарками, так?
Коллеги, но ведь это же бред: ПО обрабатывает заведомо битые файлы и в ус не дует. Неужели нет никакого механизма проверки? Или теперь надо накатывать в Windows отдельную утилиту, которая будет елозить данные регулярно?Смысл в синхронизации, например, домашних фото - отпадает тогда. У меня тоже синхронизируются файлы с NAS. Не через Drive, сторонним ПО, но смысл от этого не меняется. Какие есть соображения? Создавать аналог CRC-хранилища? Эдакая "банка в банке". То что должно делаться на уровне ОС, мы теперь будем лечить припарками, так?
Сам был в шоке когда столкнулся. Сейчас перехожу на новый NAS и хочу настроить по-новому. Если в течение 2-3 дней не найдем ответ, напишу в поддержку.
А зачем для бэкапов использовать Drive?
Он немного для другого предназначен.
Используйте Active Backup. Он сохраняет все версии файлов.
А зачем для бэкапов использовать Drive?Он немного для другого предназначен.
Используйте Active Backup. Он сохраняет все версии файлов.
Вы меня извините, задним числом все умные.
На автомате я использую ежедневный "rsync copy (single-version)" из рабочего NAS в старый.
И вручную иногда синхронизую прочие копии.
Легко проверить целостность всех архивов, включая автоматический. В моих архивах нет никакого мусора.
И если что то потребуется уничтожить, я легко это сделаю в backup.
Тот же rsync в версии backup будет многоверсионным и вероятно в виде файлов, в которые влезть из стороннего ПК сложно.
Так тут речь идёт о том, что из Windows данные копируются на NAS. И не обязательно это делается через Drive. Копируются ошибочные, замещая в случае синхронизации ещё "живые", поскольку на HDD они стали битыми. И что это не единичный случай и как бы это победить. Не о Active Backup речь.
Не о Active Backup речь.
Интересный вопрос. Второй раз бить нельзя ?
В штанах полно, полез в active . (Наверное самая популярная программа сегодня).
Там как попасть в homes?
Так тут речь идёт о том, что из Windows данные копируются на NAS. И не обязательно это делается через Drive. Копируются ошибочные, замещая в случае синхронизации ещё "живые", поскольку на HDD они стали битыми. И что это не единичный случай и как бы это победить. Не о Active Backup речь.
Я использую заготовку "rsync copy (single version)" в новом NAS. В старом NAS получаю ту же структуру папок и файлов, что и была.
А далее смотрю описание команды rsync, и нахожу все удобные опции
--del an alias for --delete-during
--delete delete extraneous files from destination dirs
--delete-before receiver deletes before transfer, not during
--delete-during receiver deletes during the transfer
--delete-delay find deletions during, delete after
Вероятнее всего удаление файла перез записью новой версии или после зависит от ОС.
Windows всегда сперва удлалает, а потом пишет новую копию.
На автомате я использую ежедневный "rsync copy (single-version)" из рабочего NAS в старый.И вручную иногда синхронизую прочие копии.
Для этого я использую Hyper Backup...
Лично у меня реализовано следующим образом:
Рабочие виндовые машины раз в час инкрементно бэкапятся на NAS посредством Active Backup. Оттуда потом легко вытащить любую версию файла за любой промежуток времени. Можно даже целиком виндовый диск восстановить. Но это я пока не пробовал.
Сам NAS (нужные папки) раз в сутки посредством Hyper Backup инкремнтно бэкапится на внешний диск и другой NAS который физически находится в другом городе.
А драйв для бэкапа... Он ведь именно для синхронизации а не для хранения разных версий. Файл изменился - значит он и останется...
Для этого я использую Hyper Backup...
Лично у меня реализовано следующим образом:
Рабочие виндовые машины раз в час инкрементно бэкапятся на NAS посредством Active Backup. Оттуда потом легко вытащить любую версию файла за любой промежуток времени. Можно даже целиком виндовый диск восстановить. Но это я пока не пробовал.
Сам NAS (нужные папки) раз в сутки посредством Hyper Backup инкремнтно бэкапится на внешний диск и другой NAS который физически находится в другом городе.
А драйв для бэкапа... Он ведь именно для синхронизации а не для хранения разных версий. Файл изменился - значит он и останется...
Так я тоже нашел свой "rsync copy (single-version)" в наборе Hyper Backup рабочего NAS.
Написал скрипт в старом NAS для дальнейших локальных backup посредством rsync, собрался включать мусорную корзину для хранения старых версий.
Нашел даже возможности rsync удаления до или после копирования, и думаю: нафик нужны еще автоматические копии? Запутаюсь.
Хватит одной автоматической копии, а дополнительные backup продолжу делать руками и в старый NAS, и в подсоединяемый USB диск.
Для этого я использую Hyper Backup...
Лично у меня реализовано следующим образом:
Рабочие виндовые машины раз в час инкрементно бэкапятся на NAS посредством Active Backup. Оттуда потом легко вытащить любую версию файла за любой промежуток времени. Можно даже целиком виндовый диск восстановить. Но это я пока не пробовал.
Сам NAS (нужные папки) раз в сутки посредством Hyper Backup инкремнтно бэкапится на внешний диск и другой NAS который физически находится в другом городе.
А драйв для бэкапа... Он ведь именно для синхронизации а не для хранения разных версий. Файл изменился - значит он и останется...
А как ваше решение помогает решить проблему? Извините, не понимаю.
Если участок диска на виндовой машине начал сыпаться, а на этом участке папка, которой я редко пользуюсь. То найду я этот проблемный участок допустим через месяц после очередного скандиска. В вашем варианте за это время 24 час * 30 дней = 720 бэкапов прошло и 720 версий этого битого файла создалось. Откуда и как "потом легко вытащить" небитую версию файла? Вы реально храните 720 версий?
Получается наоборот чем реже синхронизация и/или бэкап, тем выше шансы для этого конкретного случая. Но редкий бэкап не есть хорошо для всех остальных сценариев.
Программа должна перед синхронизацией проверять CRC что ли. В эту сторону мне кажется искать надо.
P.S. Драйв у меня для синхронизации и используется, не для бэкапа - прочитайте первое сообщение.
Вы реально храните 720 версий?
Даже больше. Месяца за 4-6
Он ведь инкрементный, так что места занимает не так много.
Правда было подозрение что бэкап сильно нагружает виндовые машины и временно бэкаплю раз в сутки. Но похоже что бэкап грузит их не так сильно как думали)
Даже больше. Месяца за 4-6Он ведь инкрементный, так что места занимает не так много.
Правда было подозрение что бэкап сильно нагружает виндовые машины и временно бэкаплю раз в сутки. Но похоже что бэкап грузит их не так сильно как думали)
Минус вашего инкрементально backup, если я правильно понял, это свой формат в отличие от single version backup.
Я делаю последний и могу убедиться, что файлы сохранены.
А насчет многоверсионности-инкрементальности можно писать скрипт rsync и включать мусорную корзину.
Извиняюсь, rm мусорную корзину не замечает, вероятно rsync тоже.
Я насчет хорошего backup пас. Делать инкрементальный и еще single version (с простым доступом) будет слишком запутанно.
Оставлю автоматом single version, иниогда ручной backup. В итоге либо источник, либо какая то версия данных (старая) будет в наличии.
Почитал про rsync. У него есть опция, которая создаёт на обоих сторонах хеши файлов и сверяет эти хеши при передаче данных + время изменения смотрит. Но нигде не сказано, что со стороны клиента как-то контролируется изменение хеша файла, если не изменилось время его модификации: что по сути означает повреждение данных.
По своему принципу нужна утилита, что считает и пишет в свою базу хеш сохраняемого файла. Если пользователь изменяет файл - утилита пересчитывает для него хеш и снова его сохраняет.
В итоге, перед тем как отдать файл в резервирование/зеркалирование - утилита должна перечитать его хеш заново и сравнить с тем что в базе. Довольно ёмкая процедура, если архив данных большой.
Далее, в зависимости от настроек, копируем то что уцелело или выдаём юзеру "AHTUNG!!!".
Кто-то видел такое? Поделитесь ссылкой. Желательно под Windows.
Установил и поюзал Active Backup, пока что для одного ПК. При резервировании системного раздела Windows - размер получившегося образа равен размеру раздела. Он посекторно скопировал без сжатия, что ли? Ещё и каталог какой-то рядом создал в 30ГГБ. До флешки с утилитой восстановления системы пока не добрался, утилита создания просит чё-то доустановить, не до того сейчас.
Минус вашего инкрементально backup, если я правильно понял, это свой формат в отличие от single version backup.Я делаю последний и могу убедиться, что файлы сохранены.
А насчет многоверсионности-инкрементальности можно писать скрипт rsync и включать мусорную корзину.
Я тоже сначала использовал single version backup, пока не пришёл к тому же выводу, что и Radiohead
Инкрементный архив прекрасно читается и из него можно выбрать данные за разный период, если в систему установить тот же Hyper Backup. И да, он действительно занимает не много.
Конечно, инкрементный архив не годится для простой задачи зеркалирования, я его исключительно для бекапов юзаю. Потому у меня 2 задачи в Hyper Backup: инкрементный архив на n-версий и сингл.
Почитал про rsync. У него есть опция, которая создаёт на обоих сторонах хеши файлов и сверяет эти хеши при передаче данных + время изменения смотрит. Но нигде не сказано, что со стороны клиента как-то контролируется изменение хеша файла, если не изменилось время его модификации: что по сути означает повреждение данных.По своему принципу нужна утилита, что считает и пишет в свою базу хеш сохраняемого файла. Если пользователь изменяет файл - утилита пересчитывает для него хеш и снова его сохраняет.
В итоге, перед тем как отдать файл в резервирование/зеркалирование - утилита должна перечитать его хеш заново и сравнить с тем что в базе. Довольно ёмкая процедура, если архив данных большой.
Далее, в зависимости от настроек, копируем то что уцелело или выдаём юзеру "AHTUNG!!!".
Кто-то видел такое? Поделитесь ссылкой. Желательно под Windows.
Установил и поюзал Active Backup, пока что для одного ПК. При резервировании системного раздела Windows - размер получившегося образа равен размеру раздела. Он посекторно скопировал без сжатия, что ли? Ещё и каталог какой-то рядом создал в 30ГГБ. До флешки с утилитой восстановления системы пока не добрался, утилита создания просит чё-то доустановить, не до того сейчас.
1. Типичный ПК имеет два backup: голая система 1.5 GB, система с софтом 19 GB без данных пользователя, т.е. хранить можно где угодно, версионность не нужна.
2. Среди данных пользователя есть то, что не требует частого backup, и есть то что надо сохранять ежедневно.
Загонять все под инкрементальный backup не целесообразно. Данные пользователя вообще целесообразно расположить в NAS.
Я тоже сначала использовал single version backup, пока не пришёл к тому же выводу, что и RadioheadИнкрементный архив прекрасно читается и из него можно выбрать данные за разный период, если в систему установить тот же Hyper Backup. И да, он действительно занимает не много.
Конечно, инкрементный архив не годится для простой задачи зеркалирования, я его исключительно для бекапов юзаю. Потому у меня 2 задачи в Hyper Backup: инкрементный архив на n-версий и сингл.
Большое спасибо за свой опыт, вероятно для основной папки со своими проектами придется сделать еще инкрементальный backup.
Загонять все под инкрементальный backup не целесообразно. Данные пользователя вообще целесообразно расположить в NAS.
После перечитанного, я уже не знаю как правильно. Я теперь и в NAS не уверен. 
У нас на домашних ПК хранится куча доков, исторически. Это всё синхронизируется на NAS, через FreeFileSync, просто зеркалирование. Чувствую себя на мине с замедленным действием: у меня на ПК винчестер сильно "подгулявший".
Да, под Windows есть замечательная утилита Cobian Backup, которая делает почти то же самое, что и Hyper Backup. Только она не прячет инкрементный архив в один файл, а создаёт копию того, что изменилось. Можно ещё ей указать ZIP'ом всё пожать. И всё, просто версионность, когда делать инкремент и когда полный, сколько сохранять версий. Но винчестер-то на NAS не резиновый. И когда "прилетит", как угадать? Потому я выше и заговорил про базу хешей.
После перечитанного, я уже не знаю как правильно. Я теперь и в NAS не уверен.У нас на домашних ПК хранится куча доков, исторически. Это всё синхронизируется на NAS, через FreeFileSync, просто зеркалирование. Чувствую себя на мине с замедленным действием: у меня на ПК винчестер сильно "подгулявший".
Да, под Windows есть замечательная утилита Cobian Backup, которая делает почти то же самое, что и Hyper Backup. Только она не прячет инкрементный архив в один файл, а создаёт копию того, что изменилось. Можно ещё ей указать ZIP'ом всё пожать. И всё, просто версионность, когда делать инкремент и когда полный, сколько сохранять версий. Но винчестер-то на NAS не резиновый. И когда "прилетит", как угадать? Потому я выше и заговорил про базу хешей.
Я тоже не знаю. Помимо ручного копирования с подсоединением накопителей, сделал ежедневный single copy в backupNAS и еще вручную в отдельую папку в него же всего содержимого новго NAS, включая видео. В один из дней старый диск backupNAS умер. Я понял, что нет обоих backup, но либо оригинальные данные, либо старые backup в моей схеме остаются.
А что делать с вирусами и обнаружением битых файлов в процессе автоматического копирования я еще не решил. Но на всякий случай в рабочем NAS сделал зеркало. С зеркалом в рабочем NAS иногда полезно не обновлять single copy backup, т.е. можно иногда выключать backupNAS.
Но винчестер-то на NAS не резиновый. И когда "прилетит", как угадать? Потому я выше и заговорил про базу хешей.
В моем backupNAS HDD можно сказать резиновый в сравнении с зеркалом рабочего NAS. Но чем резиновее данные, тем хуже при кончине большого диска. Мне было обидно, когда умерли обе резервные копии. Хотя без инкрементальных backup я вообще ничего не потерял, кроме времени на ручную сихронизацию.
Я тут подумал: синхронизация производится по времени изменения файла. Если время не изменилось, то синхронизация не выполняется. В итоге, для статических данных, не изменяемых годами, это не страшно. Это касается домашнего видео, фото и т.п.
Самая жуть происходит, когда что-то меняем в рабочем файле или удаляем что-то в зеркале, тогда туда подтягивается файл из "битого" источника и "всё пропало". Для этого в Hyper Backup и Cobian например есть функция "заморозки" копии, которая никаким изменениям уже не подвергается и не удаляется никуда.
В 28.12.2020 в 13:15, kucher сказал:Я тут подумал: синхронизация производится по времени изменения файла. Если время не изменилось, то синхронизация не выполняется. В итоге, для статических данных, не изменяемых годами, это не страшно. Это касается домашнего видео, фото и т.п.
Самая жуть происходит, когда что-то меняем в рабочем файле или удаляем что-то в зеркале, тогда туда подтягивается файл из "битого" источника и "всё пропало". Для этого в Hyper Backup и Cobian например есть функция "заморозки" копии, которая никаким изменениям уже не подвергается и не удаляется никуда.
Мы с вами немного усложнили задачу.
Я решил попробовать инкрементальный backup основного NAS в rsync сервер из старого Synology (не single-version) посредством HyperBackup. Оказалось, если в старом NAS установить HyperBackup той же версии DSM, то автономно имеется доступ ко всем версиям архива в старом NAS. У кого нет старого Synology в качестве хранилища backup, может использовать программу Synology для win-ПК. Т.е. многоверсионный backup можно читать независимо от источника данных.
Теперь о проблеме порчи данных. Я сделал несколько версий копий backup (8 штук). Если на диске в источника возникает дефект, то HyperBackup отрапортует о проблеме обновления backup. Придется данные вытаскивать из предыдущей (старой) версии backup. Иных вариантов нет. А если возникнет вирус-шифровальщик, то надо успеть его заметить до порчи всех версий backup. Тут тоже без вариантов.
Относительно минусов многоверсионного backup в сравнении с rsync single-version.
1. Вы уже написали, вероятно Hyperbackup сравнивает название, размер и даты файла и имеющейся копии. Побайтное сравнение содержимого получилось бы очень затратным. Single-version будет понадежнее, особенно для хранения запакованных архиватором данных.
2. Многоверсионная версия backup помедленнее single-version и в некоторых случаях повторного запуска Hyperbackup не хочет запускаться (возможно надо ждать удаления устаревшей версии в архивном NAS).
3. Не очень понимаю, что получится в backup при остановке основного NAS до завершения процесса? В случае single-version backup теряется только пересылаемый файл. В многоверсионном backup пересылаются упакованные данные (т.е. много новых файлов не запишется). И в конце есть процедура удаления устаревшей версии, вероятно есть возможность подпортить весь backup.
Вероятно надежнее делать по расписанию два автоматических backup, чередую их по дням. Но у меня сейчас данных без видео 400 GB (бэкап фильмов делаю только вручную) --- рука не поднимается делать по расписанию две версии backup 400 GB.