АртемЪ, zfs, btrfs - снапшот на уровне блоков файловой системы, CoW встроен в саму архитектуру файловой системы.
а не отдельной прослойкой на уровне драйверов операционной системы.
в теневой копии создается копия индекса занятых блоков фс и отметка что эти блоки защищены от записи. при попытке записи в занятый блок, с фс затребуется новый блок, в него скопируется информация со старого и в индекс фс (не снапшота) запишется указатель на этот блок, после чего с блоком можно делать что угодно.
старые данные сохранятся в старых блоках указатели на которые будут прописаны в индексах файла в снапшоте. все ок.
опять "сложно, дорого и неудобно" это потому что ты так придумал/недодумал :)
для больших объемов как раз и придуманы инкрементально-дифференциальные системы бекапа.
в твоем терабайте наврядли меняется весь терабайт документов сразу, весь и каждый день.
десятки-сотни активно редактируемых документов составляют проценты от этого объема, который недвижимым грузом лежит все время.
вот только эти изменяющиеся и бекапят в инкрементальный бекап. он получается маленьким и быстро создаваемым.
а уж весь террабайт можно и раз в месяц пожать. долгая операция, но редкая.
при полном восстановлении тож проблемм нет - развернул полный бекап, а потом на него сверху наложил дифференциальный, либо последовательно весь набор инкрементов. и ок.
но обычно и этого не требуется, тут уж зависит от потребностей. обычно хватает доступа к старым версиям.
если у тебя в данном терраюайте куча похожих документов то зачем дубли хранить ??
Saboteur, кстати да, для монитроинга изменений файлов настроить мониторинг потока изменений файловой системы.
приходилось пользоваться утилитой от Руссиновича Process Monitor. все кажет все пишет, но только гуй.
АртемЪ, все регламенты ты придумываешь сам - ну а как уж замудрил систему, так тебе и -тся :)
знаю что такое теневые копии на нтфс :) костыль-прокладка в системе, имитирующая действия снапшотов на фс с CoW :)
на бтрфс в качестве изучения системы строил систему cовмещающую все твои доводы. там все просто и логично.
каждые полчаса делался снапшот системы.
каждую ночь делался дифференциальный к месячному бекап файлом на отдельную машину.
каждый месяц полный бекап файлом на отдельную машину.
снапшоты старее двух дней еженочно удалялись.
еще была мысль сделать ежечасный/получасный инкрементальный бекап файлом на отдельную машину, чтобы точно ничего не терять при порче носителя, но забил.
получвилось достаточно быстро эффективно и устойчиво к воздействиям.
бекап это создание копий для восстановления, на случай порчи файла.
даже если ты вручную делешь копии, это уже простейший бекап :)
все замудрения с иерархией взаимоотношений и бюрократией по восстановлению к бекапу имеет нулевое отношение ибо это не технические детали.
дай доступ в р/о к архиву пароленных бекапов и многие проблемы уйдут.
Damian Lewis, дык это и есть файловый бекап системного раздела. если загрузчик есть на железке, то обратное раворачивание не составит трудов.
еще можно поиграться с снапшотами в CoW fs
Damian Lewis, зависит от "замусоренности" свободного места. можно к примеру забить пустое место нулями.
как чуть более сложный вариант можно делать файловый бекап.
но для восстановления его работспособности системного раздела после его разворачивания на чистый раздел надо будет восстановить boot запись grub.
если раздел уже был системным (к примеру восстанавливаешь на очищенный системный раздел) то восстанавливать boot-раздел не понадобится, он уже будет.
в принципе, файловый бекап системного раздела можно производить и в онлайн. все системные файлы и настройки меняются только при обновлении пакетов, а это достаточно редкое действие.
могут накрыться или быть не полными динамически записываемые файлы: логи, кеши, и прочее наполнение /var
позвонить в тех.поддержку - описать ситуацию желательно технически грамотно, а не как алкаш из подворотни.
если не поможет, то прочитать договор услуг и оформить заявление в прокуратуру.
как вариант оформленное заявление перед прокуратурой можно скинуть менеджерам провайдера.
разумный провайдер дорожит своей репутацией и очень активно на такое среагирует.
mIka01, нет.
шаговый двигатель отличается тем что в качестве ротор использует постоянный магнит, который поворачивается под действием магнитного поля статора до совпадения полюсов. переключая ток в обмотке ты перемещаешь магнит.
в асинхронном двигателе магнита с четким полем в роторе нет и как следствие нет четкой привязки между магнитным полем статора и положением ротора.
вот принципиальная схема шагового двигателя.почувствуй отличия как говорится :)
Вячеслав Суховей, вся тонкость в том что стоимость производства одной микросхемы копеешная, а вот стоимость разработки и внедрения в производство очень и очень большая.
поэтому вкладываются в разработку проца с встроенными модулями (будь то память, али аппаратный кодер видео, али еще что) будет экономически выгодно если таких процов будет наштамповано и продано десятки-сотни тысяч.
те же системы наблюдения, в которых на одном кристалле стоит простенький арм-проц управления и десяток мощных аппаратных кодеков видео, продаются как пирожки и во внедрения производства такой сборки стоит вкладываться.
в иных случах, к примеру, в разработку однокристального решения проц+память+hwnat+ethernet+чтото_еще для роутеров почему-то никто не вложился. значит почему-то сие не выгодно...
Nightmare1, нормально.
накодить настройки проги с граф.интерфейсом.
к примеру вхожу через графический интерфейс putty на ssh-сервер по ключу, который в файле.
не уверен что авторы проги задумывались над продолжением работы после внезапной остановки. это лишний код, лишние доп.файлы, по которым можно восстановить прерванную работу.
в некоторых такое сделано, типа ddrestore, но это дополнительная функция и гемор для разраба.
а не отдельной прослойкой на уровне драйверов операционной системы.
в теневой копии создается копия индекса занятых блоков фс и отметка что эти блоки защищены от записи. при попытке записи в занятый блок, с фс затребуется новый блок, в него скопируется информация со старого и в индекс фс (не снапшота) запишется указатель на этот блок, после чего с блоком можно делать что угодно.
старые данные сохранятся в старых блоках указатели на которые будут прописаны в индексах файла в снапшоте. все ок.
опять "сложно, дорого и неудобно" это потому что ты так придумал/недодумал :)
для больших объемов как раз и придуманы инкрементально-дифференциальные системы бекапа.
в твоем терабайте наврядли меняется весь терабайт документов сразу, весь и каждый день.
десятки-сотни активно редактируемых документов составляют проценты от этого объема, который недвижимым грузом лежит все время.
вот только эти изменяющиеся и бекапят в инкрементальный бекап. он получается маленьким и быстро создаваемым.
а уж весь террабайт можно и раз в месяц пожать. долгая операция, но редкая.
при полном восстановлении тож проблемм нет - развернул полный бекап, а потом на него сверху наложил дифференциальный, либо последовательно весь набор инкрементов. и ок.
но обычно и этого не требуется, тут уж зависит от потребностей. обычно хватает доступа к старым версиям.
если у тебя в данном терраюайте куча похожих документов то зачем дубли хранить ??