anton13ms, тут проблема в разнице системных понятий: ты о говоришь о хорошей машине, мы говорим об отличиях дезеля/бензина, АКПП/МКПП и т.д.
я вижу два варианта
вариант1: скрипт работает только во время ssh-сессии. т.е. изменил скрипт, зашел глянуть на выхлоп его запуска на сервере
вариант2 - скрипт работает постоянно 24/7 вне зависимости от наличия ssh-сессии. но после редактирования нужно перезапустить юнит и посмотреть его работоспособность через просмотр его выхлопа через ssh-консоль.
в твоем запросе нет точного указания что конкретно хочешь.
full_stack_newbie, знаю про screen/tmux. как то находил команду которая позволяет перехватывать отключенную консоль, типа chvt но кажись другое.
тут надо выяснить что хочет вопрощающий.
RU268, да, может.
для отрыва электронов от холодного катода понадобится больше энергии, сиречъ надо будет подать больший потенциал на анод.
сколько это "точно в граммах" не скажу, ибо зависит от конструкции и размеров самой трубки.
если есть нить нагрева, то лучше использовать ее - конструктор трубки не дурак и просто так ничего не замудрит.
АртемЪ, ты путаешь систему бекапа и интерфейс программы.
у многих крупных коммерческие бекаперов такое есть. к примеру вот погуглил чутка - бекапер с граф.интерфейсом с восстановлением файлов с выборкой версий из бекапа. https://help.2brightsparks.com/support/solutions/a...
клиент восстановления обращается по собственному протоколу к серверу хранения бекапов и делает выборку версий файлов леэащих в хранилище, отображает спиосок пользователю и потом производит запрос необходимой версии файла для восстанолвения на клиентской машине.
все возможно - было бы желание сделать :)
опять же ограниченность ваших используемых средств ограничивает горизонт познания.
все возможно. инкрементальный бекап не тяжел, ибо в инкремент уходит небольшой объем только лишь изменнного, и поэтому его можно делать весьма часто.
но вам этого судя по всему не понять.
пардон что занял ваше время.
на статоре могут быть и простые магниты, только поставлены таким образом чтобы в центре образовывалась "потенциальная яма" в которой зависает летающий магнит.
самая простая конфигурация кольцевой магнит от динамика, дырка посередине дает "провал" в магнитном поле. к нему неодимовый магнит к которому сбоку приклеен груз чтобы магнит не переворачивался. игрались как-то.
чтобы понять что там еще накручено надо разобраться в конструкции и применении.
мне кажется проблема в том что ты бекап понимаешь как то монструзоно :) это что такое большое с админами, операторами и т .д. от того мощное и тяжелое и неповоротливое.
но это не так (по моему мнению)
файловый бекап можно и своими силами сделать. даже без рута и прочих прав.
скрипт сжатия раром/7зипом (с инкрементами по вкусу) и отправка в облако. скрипт в планировщик заданий. и ок.
и таких статеек в тырнете навалом.
кстати в нтфс есть отличная штукенция - бит архивности. и рар отлично с ним работает. так что инкременты делаются однострочником.
АртемЪ, zfs, btrfs - снапшот на уровне блоков файловой системы, CoW встроен в саму архитектуру файловой системы.
а не отдельной прослойкой на уровне драйверов операционной системы.
в теневой копии создается копия индекса занятых блоков фс и отметка что эти блоки защищены от записи. при попытке записи в занятый блок, с фс затребуется новый блок, в него скопируется информация со старого и в индекс фс (не снапшота) запишется указатель на этот блок, после чего с блоком можно делать что угодно.
старые данные сохранятся в старых блоках указатели на которые будут прописаны в индексах файла в снапшоте. все ок.
опять "сложно, дорого и неудобно" это потому что ты так придумал/недодумал :)
для больших объемов как раз и придуманы инкрементально-дифференциальные системы бекапа.
в твоем терабайте наврядли меняется весь терабайт документов сразу, весь и каждый день.
десятки-сотни активно редактируемых документов составляют проценты от этого объема, который недвижимым грузом лежит все время.
вот только эти изменяющиеся и бекапят в инкрементальный бекап. он получается маленьким и быстро создаваемым.
а уж весь террабайт можно и раз в месяц пожать. долгая операция, но редкая.
при полном восстановлении тож проблемм нет - развернул полный бекап, а потом на него сверху наложил дифференциальный, либо последовательно весь набор инкрементов. и ок.
но обычно и этого не требуется, тут уж зависит от потребностей. обычно хватает доступа к старым версиям.
если у тебя в данном терраюайте куча похожих документов то зачем дубли хранить ??
Saboteur, кстати да, для монитроинга изменений файлов настроить мониторинг потока изменений файловой системы.
приходилось пользоваться утилитой от Руссиновича Process Monitor. все кажет все пишет, но только гуй.
АртемЪ, все регламенты ты придумываешь сам - ну а как уж замудрил систему, так тебе и -тся :)
знаю что такое теневые копии на нтфс :) костыль-прокладка в системе, имитирующая действия снапшотов на фс с CoW :)
на бтрфс в качестве изучения системы строил систему cовмещающую все твои доводы. там все просто и логично.
каждые полчаса делался снапшот системы.
каждую ночь делался дифференциальный к месячному бекап файлом на отдельную машину.
каждый месяц полный бекап файлом на отдельную машину.
снапшоты старее двух дней еженочно удалялись.
еще была мысль сделать ежечасный/получасный инкрементальный бекап файлом на отдельную машину, чтобы точно ничего не терять при порче носителя, но забил.
получвилось достаточно быстро эффективно и устойчиво к воздействиям.
бекап это создание копий для восстановления, на случай порчи файла.
даже если ты вручную делешь копии, это уже простейший бекап :)
все замудрения с иерархией взаимоотношений и бюрократией по восстановлению к бекапу имеет нулевое отношение ибо это не технические детали.
дай доступ в р/о к архиву пароленных бекапов и многие проблемы уйдут.
Damian Lewis, дык это и есть файловый бекап системного раздела. если загрузчик есть на железке, то обратное раворачивание не составит трудов.
еще можно поиграться с снапшотами в CoW fs
Damian Lewis, зависит от "замусоренности" свободного места. можно к примеру забить пустое место нулями.
как чуть более сложный вариант можно делать файловый бекап.
но для восстановления его работспособности системного раздела после его разворачивания на чистый раздел надо будет восстановить boot запись grub.
если раздел уже был системным (к примеру восстанавливаешь на очищенный системный раздел) то восстанавливать boot-раздел не понадобится, он уже будет.
в принципе, файловый бекап системного раздела можно производить и в онлайн. все системные файлы и настройки меняются только при обновлении пакетов, а это достаточно редкое действие.
могут накрыться или быть не полными динамически записываемые файлы: логи, кеши, и прочее наполнение /var
позвонить в тех.поддержку - описать ситуацию желательно технически грамотно, а не как алкаш из подворотни.
если не поможет, то прочитать договор услуг и оформить заявление в прокуратуру.
как вариант оформленное заявление перед прокуратурой можно скинуть менеджерам провайдера.
разумный провайдер дорожит своей репутацией и очень активно на такое среагирует.
я вижу два варианта
вариант1: скрипт работает только во время ssh-сессии. т.е. изменил скрипт, зашел глянуть на выхлоп его запуска на сервере
вариант2 - скрипт работает постоянно 24/7 вне зависимости от наличия ssh-сессии. но после редактирования нужно перезапустить юнит и посмотреть его работоспособность через просмотр его выхлопа через ssh-консоль.
в твоем запросе нет точного указания что конкретно хочешь.