После года разработки Антонио Диаз Диаз (Antonio Diaz Diaz) сформировал новый выпуск утилиты ddrescue 1.23 (https://www.gnu.org/software/ddrescue/), предназначенной для восстановления данных со сбойных носителей информации. Утилита выполняет копирование содержимого файла или блочного устройства на другой носитель, пытаясь по возможности сохранить сохранившиеся данные в условиях возникновения ошибок при чтении. При наличии нескольких повреждённых копий с разными сбойными областями (например, при восстановления бэкапов с нескольких CD или иных носителей), ddrescue предоставляет функцию их слияния и, если сбойные области не пересекаются, в итоге можно восстановить целостность файла. Утилита поставляется под лицензией GNU GPLv2.В новой версии исправлены накопившиеся ошибки, обновлена документация и добавлены две опции: "--same-file", позволяющая входному и выходному файлам быть одним файлом, и "--shift" для ddrescuelog, сдвигающая все позиции блоков на (opos - ipos).
URL: https://www.gnu.org/software/ddrescue/
Новость: https://www.opennet.ru/opennews/art.shtml?num=48144
Ага, с неделю назад: https://packages.altlinux.org/ru/Sisyphus/srpms/ddrescue/cha... -- соответственно уже в http://altlinux.org/rescue
Странно, я думал что это немецкое название - Alt (старый) Linux :)
Ну таки Альтлинух относительно весьма немолод...
Местами так и есть. Только, в отличие от дебиана с его бэкпортами и тестингами, установка пакетов из сизифа приводит к каше зависимостей.
Сизиф - это не бэкпорты. Альт уже не использую, но раньше бэкпорты были отдельно.
> Местами так и есть. Только, в отличие от дебиана с его бэкпортами
> и тестингами, установка пакетов из сизифа приводит к каше зависимостей.Э... давайте попробуем расхлебать образовавшуюся кашу понятий.
sisyphus можно сравнить с тем же debian sid -- если его смешивать со stable, получится примерно такой же ай-яй-яй.
А вот в чём отличие sisyphus от sid -- в нынешнем альте в принципе нет unmet'ов из-за того, что они запрещены в транзакционной сборочнице.
backports когда-то были, но давно упразднены в пользу размещения пакетов непосредственно в стабильных репозиториях (этакий rolling).
PS: минусаторы, как всегда, радуют -- "мы будем злить их и дальше" (ц) RT ;-)
> backports когда-то были, но давно упразднены в пользу размещения пакетов непосредственно в стабильных репозиториях (этакий rolling).А можно поподробнее — вот если пакет X древнючей версии, где его искать, какой такой rolling?
>> backports когда-то были, но давно упразднены в пользу размещения
>> пакетов непосредственно в стабильных репозиториях (этакий rolling).
> А можно поподробнее — вот если пакет X древнючей версии, где его
> искать, какой такой rolling?В архиве, если правильно Вас понял.
> PS: минусаторы, как всегда, радуют -- "мы будем злить их и дальше" (ц) RT ;-)Казалось бы новость про неплохую программу. Но нет - вместо этого высеры про альт, сотни симпатий и какой-то флудоспам. И инициатором является конечно же модератор. Весьма в духе RT, что сказать.
p.s. это был автор #14. Заметьте, #14 рейтинг совсем иной. А вот обещать повторить это я не буду, видя такое свинство. Пусть лучше ваш спам читают, чтоли.
>И инициатором является конечно же модератор.Нихрена не так! Модератор делает дистрибутив, и абсолютно по делу вставил о том, что что вот эта, самая новейшая, хорошая программа у них уже есть - пользуйтесь!
Заметь - оно не само там выросло, а появилось в результате приложения рук и голов из команды написавшего.
Для меня - это нормально, это показывает отношение команды к своему детищу. Но я - старпёр из тех времён, когда мужики любили женщин, а не друг-дружку :-р
> Нихрена не так! Модератор делает дистрибутив,При том рекламного спама от него исходит больше чем всего остального. Я конечно понимаю что сам себя не похвалишь - никто не похвалит. Но когда это в стиле RT - в дистре останутся только т...е м...ки, из которых разработчики обычно очень уж "не очень".
> уже есть - пользуйтесь!
При том в виде который вызвал флейм и зрительские симпатии.
> Заметь - оно не само там выросло, а появилось в результате приложения
> рук и голов из команды написавшего.А еще у этих команд прибавилось зрительских симпатий, отраженных в красной циферке. И на месте фирмы и команды я бы на это обиделся, потому что по сути подстава.
> Для меня - это нормально, это показывает отношение команды к своему детищу.
Да, это показывает. И очень хорошо характеризует альтлинукс. Выбор старперов которым хватает телевизора УЛПЦТ в который они сами тыкают паялом раз в месяц.
> Но я - старпёр из тех времён, когда мужики любили женщин, а не друг-дружку :-р
А по коментам и не скажешь.
> При том рекламного спама от него исходит больше чем всего остального.Если это User294 -- не от Вас ли был упрёк альту, что, мол, не рассказываете о том, что делаете?
Или "почему в шапке"?
>PS: минусаторы, как всегда, радуютэто импотенты. Таких злит когда другие - могут! :)
>-- "мы будем злить их и дальше" (ц) RT ;-)+100500!!! Удачи вам в этом деле! :)
слушай, а зачем под каждой новостью рапортовать о том, собрал ли ты пакет для альта? ну вот допустим я сижу на альте. Я что, уведомления о доступных обновлениях не получу? То есть твой рапорт бесполезен даже для пользователей альта.
томушо реклама, ну
Да, реклама. Ну дык время такое.
> слушай, а зачем под каждой новостью рапортовать о том, собрал ли ты
> пакет для альта?Нуу отчасти это подначивание гентушников и кто там ещё любит рапортовать, что _другие_ собрали объявленную версию для используемого ими дистрибутива.
В данном разе это была ещё ссылка на altlinux.org/rescue, который и впрямь содержит сабж -- в этом плане автор #25 оказался прав. :)
...гентушники с недоверием смотрят на Шигорина
> ...гентушники с недоверием смотрят на ШигоринаКстати, мой коллега по разработке alt/e2k заодно gentoo developer, спасибо за такого профессионала!
Потому что обновления для альта доставляются через opennet
Да её тоже скачал в исходниках ещё по выходу. Но чё-то посмотрел за праздники, - вроде и народу на форуме много, а новостей один хрен мало. Ждал-ждал-ждал новые новости, потом вспомнил, что сам когда-то был рупором свободы в этом мире удивительного и интересного Свободного Программного Обеспечения и написал их сам про то, что я знаю/умею мне важно/интересно. :-)P.S. А так то, даже за праздники, в мире СПО послучалось довольно много интересных событий. Но так как с оплатой интернета у меня пока проблемы и он почти ворованный, то я имею мопедную скорость, не все протоколы (крайне тяжко без VCS (git/cvs/svn/e.t.c.)... В общем у меня пока дохера проблем и не до оперативного ньюсмейкерства. :-)
Чувак, смотрю любишь ты провоцировать и ловить минуса. Ну вот зачем ты это сделал?
> Чувак, смотрю любишь ты провоцировать и ловить минуса.
> Ну вот зачем ты это сделал?Помимо "нормальной" реакции на "кто-то что-то взял и сделал", здесь ещё водится стопка обиженных мной в качестве комодератора за различные нарушения здешних правил -- среди них кто-то склонен к чисто детсадовскому выражению своих эмоций накруткой минусов, которые здесь ничего по существу не значат (кроме внимания, которое по модулю считается).
Не обращайте вминания :)
Я когда новость открыл было -32. На момент написания -25.
Это говорит о том, что Россию населяют не только лишь одни гов*юки :)
Правда они могут внезапно кучей навалиться и минут 10 наслаждаться "пэрэмогой! ;-)
... а топом их бьют :))))
Полезная утилса для снятия образов осыпающихся винчей.
Штуки три полумертвых уже вытащил. Важные моменты: первый проход запускать обязательно с "-n", опционально с "-K1M"; последний проход с "-d -r3". Если образ снимается на USB-диск, то добавлять "-D", это делает скорость записи равномерной, и ddrescue лучше соображает.
Можно еще myrescue использовать. В любом случае идея такая что сперва снимается грубый образ с быстрым уходом из битых областей, а потом дочитываем пока читается более дотошно. Более наивные подходы чреваты тем что пациент умрет до построяния хотя-бы приблизительного образа и это будет полный облома.
> Штуки три полумертвых уже вытащил. Важные моменты:Ещё один: операции по восстановлению данных стоит проводить на _копии_ вытащенного образа.
> Ещё один: операции по восстановлению данных стоит проводить на _копии_ вытащенного образа.На reflink - лучше. Не тратится время на копирование и места надо только на отличия. Потому что хранить дважды и копировать какой-нибудь терабайт можно опупеть.
Где можно почитать (желательно на русском) гайд для новичков по ddrescue? Смотрю в каментах выше бывалые спецы, дают советы как делать лучше, чтобы окончательно не просрать данные. Но хотелось бы почитать именно хорошую статью с пояснениями для каждого типа носителей: HDD/SSD/USB... - как лучше начинать, сколько проходов, какие ключи... чтобы все по полочкам разложить, как говорится!
> Где можно почитать (желательно на русском) гайд для новичков по ddrescue? Смотрю
> в каментах выше бывалые спецы, дают советы как делать лучше, чтобы
> окончательно не просрать данные. Но хотелось бы почитать именно хорошую статью
> с пояснениями для каждого типа носителей: HDD/SSD/USB... - как лучше начинать,
> сколько проходов, какие ключи... чтобы все по полочкам разложить, как говорится!Usb флехи и ssd предмет простой: или прочлось или нет. Шансов что при повторной попытке не читавшийся сектор прочтется - мало. Если заряд в флехе утек, то утек. Если там что-то более системное, слет таблиц трансляции, кончина (фирмвари) контроллера и проч - ddrescue опять же не поможет. Это или спецутилиты под конкретный контроллер или подпайка к NAND и вычитывание на программаторе. Сам не сделаешь с такими вопросами.
HDD - интереснее, механика мрет разнообразно. Довольно часто с цатой попытки чтение нестабильного сектора все же проскакивает. Если наивно монтировать диск средствами ОС, ядро наткнувщись на read error быстро сдастся, файлов не получишь, если не прочлось по быстрому что-то важное типа суперблока, таблиц разделов и проч. А если построить образ за несколько проходов - может выйти довольно живым, монтируемым и с доступными файлами, плюс-минус то что не прочлось совсем.
Идея такая что проходов чтения несколько:
1) Параметры 1-го прохода - при ошибке чтения пропускаем большой кусок, чтобы физически проблемную область обойти. Активное тормошение сбойной области может добить нестабильную механику или вызвать фатальные глюки прошивки диска. Будет у тебя половинка образа - потеряешь как друак большинство файлов.
2) Когда образ из 1) готов, дочитываем более дотошно, с повторными попытками и прочими камасутрами, например реверс направления чтения или что еще, в надежде что чтение все же проскочит. Количество "уточняющих" проходов - пока не задолбаешься, или пока не перестанут вычитываться сектора. Или как вариант пациент может умереть на очередной итерации, но это уже похрен, образ уже достаточно хороший, это была минимизация потерь. Насколько получится - столько и будет. Чем больше тем лучше, но HDD может решить иначе. Если не идиотничать, получишь большинство файлов в целости и сохранности.Некоторые моменты:
1) Читать имеет смысл по размеру блока ECC. У старых винчей 512 байтов. У новых ("advanced format") - 4096 байтов. Чем меньше блок тем медленнее чтение. Прочлось-не прочлось индивидуально для ECC-блока ("hardware sector"). Необоснованно крупные блоки увеличивают потери данных. Если читать блоком мегабайт - даже если не прочтется 1 сектор, чтение завалится для всего мегабайта и потеряется целиком. А если это 512 байтов сектора и не прочелся 1 сектор а остальные ок - мы получим почти мег данных, кроме 1 сектора. Разница однако. Особенно если это партишн или суперблок, без которых так сходу ФС вообще не смонтируется.2) При желании этим заниматься неплохо бы узнать кто такие UNC, IDNF, defect lists, атрибуты smart и проч, чтобы хотя-бы примерно понимать на что нарвался и перспективы (pending sectors, ...). Неплохо бы понимать логи/битмап чтения используемой софтины. По крайней мере чтобы не напортачить. Например если при разных попытках использовать разные размеры блока - есть риск ушатать образ, когда утилита читанет очередные сектора в неправильное смещение образа, считая не тот размер блока который реально был. Do not use force, try to think, Luke.
3) В тяжелых случаях может потребоваться подкрутить таймауты ядра на link reset, число попыток и все такое прочее. Иначе ядро разочаруется в HDD и потеряет его. "Насовсем" - до ребута. Но это лечится - можно вручную пересканировать и найти пропавший винч.
4) Перезагружать и особенно выключать комп с нестабильным винчом - хучшая идея на свете. Если винч не стартанет - облом стопроцентный, после этого данные сможет вынуть только серьезный специалист. Необдуманный ресет может облегчить кошелек на очень круглую сумму. Если винч все-же потерялся, как в 3) - гуглишь как вызвать рескан винчей, изучаешь /sys и заново ресканишь свой винч. Через минутку-другую после отвала. Фирмварь в это время может вкалывать пытаясь ремапнуть проблемный сектор, ядро же думает что винч повис и пытается link reset устроить. Фирмвара может думать довольно крепко, не ответит даже на IDENTIFY пока не закончит. В этом случае ядро очень огорчается и считает девайс мертвым. Так что подождать немного до того как ресканить. Никаких ребутов и выключений питания - после них винч может не запуститься совсем.
5) Если бэдов всего несколько штук, можно записать в них что-нибудь, винч проверит читается ли это и если нет - переназначит на резервные. Но это имеет смысл только если бэдов не больше 3-5 штук. Со стукнутым винчом это или самообман или западло для тех кому его всучишь, разрушения на этом не закончатся, по мере разлета пыли бэдов станет больше.
6) Если порушено много - осторожно! После того как у винча закончится grown defect list (таблица ремапа, типично винч может перенести 2000-4000 проблемных секторов) - может случиться все что угодно. WD уходят в что-то типа safe mode, считая девайс слишком дохлым, и обычными способами уже ничерта не получишь. ATA командами "read sector" - читается. Но вот всякие NCQ и READ MULTI отваливаются, ядро так с наскока получает от ворот поворот и видит сплошные read error. Наверное можно переубедить, заставив забить на NCQ и читать по 1 сектору, но - лучше не нарываться.
А где же классический совет про вычитывание лежащего в холодильнике (не в морозилке) винча (ну, юсб-боксом, например)? Была же такая байка: мол, меньше теплового шума - меньше вероятность ошибки чтения? Или это бред сивой кобылы/неактуальный в нынешних реалиях метод?А для автоматизации 5) в сети встречается вот такой скрипточек:
Не бред, оживил так на время 20 гигабайтный сигейт, положил ненадолго в морозильную камеру, предварительно упаковав в полиэтиленовый мешок.
Если хотите по настоящему ходить на диск из питона под линуксом то стоит сюда посмотреть: https://github.com/kazenniy/atapt
А дергать из питона hdparm это онанизм.
> А где же классический совет про вычитывание лежащего в холодильникеКак-то не требовалось. Народ утверждает что работает, но лично не проверялось. Может и работать, температурные деформации могут немного менять как трек размещен, пыль с блина может отлипнуть, etc. Так что может прочитаться что-то новое. Особенно актуально если служебка не читалась, без чего винч не запустится.
> https://github.com/unxed/fixhdd/blob/master/fixhdd.py
Не, чувак, чинить винчи БИДОНОМ я точно не буду. У меня на такие случаи есть болваночка на си, из которой я за 10 минут допилю что мне будет надо здесь и сейчас. По крайней мере это не тормозит, чекает ошибки IO и не падает с стектрейсами от того что версия питона не та.
Есть смысл пользоваться ddrescue в комплексе с partclone.* и ddru_ntfs* для создания файла битовой карты по занятому месту (чтоб не читать весь диск) и примерного анализа (в случае NTFS) полученных логов, что прочлось, что нет. К сожалению, ddru_ntfsfindbad не умеет в ATTRIBUTE LIST, поэтому если есть подозрение на очень фрагментированные файлы (какие-нить субд или 1с там) для понимания, какие файлы битые, а какие нет, лучше по получению образа заполнить непрочитанные куски каким-нить шаблоном типа BADBADBADBAD через ddrescue --fill и потом искать содержащие этот шаблон файлы уже в замонтированном образе (если ФС не пострадала, а только файлы) или после пофайлового восстановления при помощи, например, r-studio.
> Есть смысл пользоваться ddrescue в комплексе с partclone.* и ddru_ntfs* для создания
> файла битовой карты по занятому месту (чтоб не читать весь диск)Я не занимаюсь DR профессионально. Немного системной магии случается по дружбе, для знакомых. Поэтому обычно для подубитых линуксные ФС.
> и примерного анализа (в случае NTFS) полученных логов, что прочлось, что нет.
Как по мне пусть виндохомяки идут в лабу к спецам и платят более другие деньги. Мне проблемы виндовых ФС не интересны, как и проприетарные инструменты.
> в замонтированном образе (если ФС не пострадала, а только файлы) или
> после пофайлового восстановления при помощи, например, r-studio.Мне пох. Для линуксоидов могу посоветовать юзать btrfs и нахаляву вытаскивать файло "btrfs restore" если все зашло так далеко. Там аналог утилей такого плана - часть тулкита ФС. Без гадской проприетари и левых утилит. Еще и чексумы, сразу видно что побито. А на однодисковой ФС еще и две копии метаданных по дефолту. Что очень повышает шансы достать файло если бэд под важные метаданные попал.
Кстати для храрения образов btrfs тоже рулит, можно cp --reflink создать рабочую копию образа которая весит почти ничего. И измываться над ней. А если не получилось - ну, стереть и попробовать еще раз. Не трогая полученный с таким трудом оригинал образа. И таки забавно когда у меня пяток образов "якобы по терабайту" на винче 2Тб :).
>> Есть смысл пользоваться ddrescue в комплексе с partclone.* и ddru_ntfs* для создания
>> файла битовой карты по занятому месту (чтоб не читать весь диск)
> Я не занимаюсь DR профессионально. Немного системной магии случается по дружбе, для
> знакомых. Поэтому обычно для подубитых линуксные ФС.У всех знакомых линукс? Ну-ну. Более того, partclone.* включает утили для страшной пачки ФС, включая ext[234].
>> и примерного анализа (в случае NTFS) полученных логов, что прочлось, что нет.
> Как по мне пусть виндохомяки идут в лабу к спецам и платят
> более другие деньги. Мне проблемы виндовых ФС не интересны, как и
> проприетарные инструменты.Чем больше таких васянов, тем больше нам хлеба ;)
Очень интересно! Большое спасибо!
Не поделитесь ссылками / ключевыми словами для углубления в эту тему?
зы: не обязательно на русском.
Прям на отдельную статью в https://www.opennet.ru/tips/sml/ тянет.
> Прям на отдельную статью в https://www.opennet.ru/tips/sml/ тянет.Вот и перенеслы бы туда вместо тупого спама в стиле RT, чтоли.
>> Прям на отдельную статью в https://www.opennet.ru/tips/sml/ тянет.
> Вот и перенеслы бы тудаНаписал Максиму.
> вместо тупого спама в стиле RT, чтоли
Эт ещё что, с утра разместил три присланных перевода на ANNA-News (два ролика и фильм про Маядин). Трепещите, или добро пожаловать домой ;-)
PS: а давайте как-нить познакомимся живьём?
-> https://www.opennet.ru/tips/3054_disk_bad_sector_ddrescue.shtml
Бла-бла-ба ни о чем. Технически все правильно. Но полезной инфы для вопрошающего = 0. Одно общее словоблудие.
> Где можно почитать гайдЧитай доки. How-to до добра не доведут
> Читай доки. How-to до добра не доведутЛучше голову использовать. Получить примерное понимание как это работает и что хочется получить. И дальше использовать мозг, по ситуации. Как будто блин универсальные решения есть на все случаи.
Так то не приходилось ничем таким заниматься. Я обычно бэкапы делаю вовремя, но всяко может пригодиться!
>...Я обычно бэкапы...Как показывает опыт - чаще всего ddrescue применяется к принесённым домашними пользователями дискам.
интересно, если бы программу разрабатывал не "Antonio Diaz Diaz" а "Meow Ludo Disco Gamma Meow Meow"
как называлась бы программа ? =)
mmrescue? Вроде ничего особенного.
> mmrescue? Вроде ничего особенного.Вообще-то ее имя есть производная от классической 'dd' (http://www.gnu.org/software/coreutils/dd)!
кстати это имя реальное
https://www.theguardian.com/australia-news/2018/feb/15/bioha...австралийский киборг, которого натянули на 200 австралийских $ за то что он вживил чип от проездного =)
Хорошая, работающая программа
Лучше чем R-Studio для Винды?
GetDataBack тоже неплох
Опять же для Винды. А в линуксе есть лучше чем R-Studio и GetDataBack. Вот вопрос
> Опять же для Винды. А в линуксе есть лучше чем R-Studio и
> GetDataBack. Вот вопросНовосибирцы одни свои софты (ведущие в своём классе, как обычно) продавали как линуксовый LiveCD -- вот ответ.
PS: имечко вот уже забыл, давно эту штуку в руках покрутить давали...
> Опять же для Винды. А в линуксе есть лучше чем R-Studio и
> GetDataBack. Вот вопросНа whdd можешь посмотреть. Умеет ATA командами читать и вообще, такой закос под "викторию", только под линух вместо доса. К сожалению логика чтения дубовая и ворочает крупными блоками, что обеспечивает субоптимальные потери. Если это для рубилова денег может топорная работа и сойдет, а для себя - есть риск нагреть себя на часть доставабельных файлов.
Можно починить - сорц есть. Но мне проще myrescue или ddrescue для чтения использовать. Хоть это и может иногда обеспечить сношения если ядро Linux и фирмварь диска будут разных мнений о том что они хотят.
> Опять же для Винды. А в линуксе есть лучше чем R-Studio и
> GetDataBack. Вот вопросЕсть r-studio под линукс. Со своими косяками, конечно, но есть и работает.
> Лучше чем R-Studio для Винды?В btrfs нечто подобное вообще сразу в штатные тулсы встроено. Так что читануть нужные файлы с порушеной ФС можно не монтируя ее. Очень мило, если ситуация оказалась отлична от идеала. Ну там на 1-дисковом стораже бэды вылезли, например.
оно лучше чем photorec из testdisk? или немного о другом?
> оно лучше чем photorec из testdisk? или немного о другом?А прочитать описание влом?!
Они совсем разные и работают на разных уровнях представления данных.
Это немного о другом.И, на самом деле, ddrescue - это новодел на C++. :-D :-D :-D
Есть ещё dd_rescue за авторством Курта Гарлоффа ((или, правильней Гарлоу?) Kurt Garloff), обычно используется в связке с bash-скриптом dd_rhelp (автор - LAB Valentin). Написан на Си.
Они прекрасно уживаются в этом мире СПО находясь в здравой конкуренции и постоянном развитии. И они предоставляют вам последнюю надежду, когда все другие варианты уже перепробованы.
Что dd_rescue, что ddrescue по принципу работы аналогичны dd. Они ничего не знают о том, что они тянут. Они тянут байты, объединённые в блоки. А уже на вытянутый дамп можно натравить и photorec/testdisk, если вытягивание прошло не слишком успешно.
Полезные ссылки:
http://www.garloff.de/kurt/linux/ddrescue/ - Домашняя страница dd_rescue;
https://sourceforge.net/projects/ddrescue/ - dd_rescue на SF.net. Есть возможность скачать самые свежие срезы.
http://www.kalysto.org/utilities/dd_rhelp/index.en.html - Домашняя страница dd_rhelp.
> Полезные ссылки:
> Есть ещё dd_rescue за авторством Курта Гарлоффа ((или, правильней Гарлоу?) Kurt Garloff),
> обычно используется в связке с bash-скриптом dd_rhelp (автор - LAB Valentin).
> Написан на Си.Есть myrescue. Прост как тапка и умеет все необходимое. Написан тоже на си и зависит аж от целого libc. И еще у него тривиальный формат bitmap с результатом чтения. Если ситуация сильно отлична от идеала, распарсить его битмап может любой кто понимает что такое битмапы.
> оно лучше чем photorec из testdisk? или немного о другом?При восстановлении сначала делается образ диска, потом с него вытаскиваются файлы. Сабж для первой задачи (при проблемах с железом, когда dd не справляется), photorec и testdisk — для второй.
Ну вот как все любят писать, что делается образ диска и все операции проводятся на нем. А ниче, что у меня например два терабайтника было, потом я новый 4ТБ купил, перелил все на него и ч/з две недели он сыпаться стал? Снять образ с него ч/з ddrescue это мне теперь на 6ТБ минимум винт нужен. Мне его покупать, чтобы с неизвестной долей вероятности восстановить данные с 4-х терабайтника и сдать его потом по гарантии? Офигительно. Все рекомендации правильные, но настолько от жизни оторваны... Писателей-ликуксоидов развелось, как собак.
Есть аналог лучше?
> Есть аналог лучше?Читай выше.
Выше о виндовых аналагах.
В линуксе то есть лучше этой?
А чем тебе не нравится эта?
> Выше о виндовых аналагах.
> В линуксе то есть лучше этой?https://www.opennet.ru/openforum/vsluhforumID3/113652.html#35
Т.е. обсуждаемый сабж лучший.
Можно сделать такой вывод, пусть и относительный? ))
> Т.е. обсуждаемый сабж лучший.
> Можно сделать такой вывод, пусть и относительный? ))в RTK GNU/Linux и в S.C.R. я запиливал обе + dd_rhelp. :-)
> Выше о виндовых аналагах.
> В линуксе то есть лучше этой?Вот такие персонажи порой обижаются на зачистку своего флуда вида "не читай, писай".
А такие персонажи как вы, кроме болтовни что то можете сказатиь по существу?
> А такие персонажи как вы, кроме болтовни что то можете сказатиь по существу?Он умеет пиарить альтлинукс в стиле RT. Пусть потом не обижается что и пользователи остались как у RT - бесполезные агрессивные бакланы.
О - кое у кого подгораяет от RT :-) Молодцы - хороший канал! :)))
> О - кое у кого подгораяет от RT :-)Да, у автора #14.
> Молодцы - хороший канал! :)))
Обычный корм для глупых агрессивных динозавров. И главное сколько ни рыкай, а эволюция свое дело сделает.
>>Обычный корм для глупых агрессивных динозавровдолгое ношение кастрюль не по размеру до добра не доведет.
>>эволюция свое дело сделает
Да, видим, что "эволюция гидности", хорошо сдобренная госдепопеченьками, сделала с Южмашем, КБ Антонова...