На тестовом прогоне так и было. В данном случае проблема возникла когда дежурный специалист решил не копипастить команду, а просто изменить параметры предыдущей.
Также при большом кол-ве операций и сжатых сроках (например, dry-run только 1 операции проходит часа за 3-4), выполнять каждый раз перед выполнением проверку — не дозволенная роскошь при окне на все работы в пару часов. Для этого есть тестовый стенд/прогон и пр.
grep — это инструмент, по-сути, фильтр. А вот выбор критерия фильтрации и анализ результатов — это другое дело. Тоже самое с --dry-run. Например, если из 1 млдр. файлов после нескольких итераций/фильтров будет получен 1 млн., то человеку все равно тяжело проанализировать.
Это я к тому, что все надо с умом применять. Где-то конкретный инструмент покажет потенциальную проблему, а где-то нет. Тут надо думать про «защиты от дурака»/человеческого фактора на другом уровне.
«Правильное решение» в данном случае должно было быть на административном уровне, а не техническом ибо все мы люди и человеки, но любой косяк технаря должен быть предусмотрен заранее.
На техническом можно было развернуть резервную систему в ОЗУ и при необходимости переключиться на нее. Вот только там могли быть другие косяки и другие ветви развития событий…
В данному случае даже новую сессию открыть не получалось (дубликат текущей, из-за отсутствие библиотек) + для sshfs требуется fuse, который не входит в минимальную установку. Если же работает запуск отдельных сессий, то проще scp/rsync использовать.
Вариантов решения много, но главная проблема — транспорт.
Зависит от задачи. Частенько бывало и такое (например, когда репликация не возможна, а объём десятки-сотни Гб). Естественно, финальный прогон когда база остановлена.
Сейчас есть другие средства миграции/конвертеры и пр., которые позволяют более-менее мигрировать без головной боли.
Про dry-run — см. выше, он не всегда уместен. Попробуйте проанализировать результат на часто меняющихся данных с множеством файлов (например, кеш с много млрд файлов или огромный массив изменяемых данных (бд)).
Про геройство — кто бы спорил :) Но факт остаётся фактом, ни кто не застрахован от ошибок. Главное из любой ситуации важно выйти и сделать выводы, чтобы в будущем подобные ситуации не повторялись.
Бекапы приклада. ОС можно восстановить в любом случае и довольно быстро.
Да, думали на эту тему, решили, что быстрее и надёжнее будет восстановить все как было + на static-linked пришлось потратить время на поиск/закачку и пр. Но как вариант это сработает.
Сертификация как результат не важна. А вот подготовка — другое дело. Опыт не всегда перекрывает все темы разом и, как правило, без системный.
Прогон rsync -n не всегда уместен с т.з. результата ибо данные могут меняться во время синхронизации рабочей систему, а могут и нет.
Человеческий фактор не всегда предугадаешь. После того случая — только копипаст уже отработанного.
Ситуация — частный случай, telnet, busybox и еще пару утилит работали (проверяли методом перебора, rsync удаляет не сразу все). В основном были удалены библиотеки, что приводило к ошибке вида:
XXX: error while loading shared libraries: libXXXX.so: cannot open shared object file: No such file or directory
Да, в каждой ситуации свой подход (иногда человеческий фактор приводит к интересным ситуациям… с точки зрения восстановления). Разница в дискам не важна: все можно подправить после ребута, в том числе таблицу разделов. Главное чтобы диск и сеть были видны новой ОС.
Желательно менеджмент порт на удаленных площадках. Либо второй хост с PXE и управление питанием.
Интересный вариант. Видимо, в шахте особо ограничений на канал нет :)
Как альтернатива:
локально сделать «эталон» (учитывая специфику железа, особенно контроллер и сеть). Естественно, диск разбить с LVM, но так, чтобы потом можно было растянуть на весь диск;
используя связку dd/nc залить образ на диск по сети;
отправить в ребут (можно тем же способом);
пойти поставить свечку и молиться, чтобы не пришлось заказывать вертолёт до объекта;
растянуть LVM как требуется;
перенести приклад.
Очень знакомая тема, выполнялось такое многократно.
Про связь оборвалась — был подобный опыт, выкрутиться можно, но седые волосы появятся.
Также при большом кол-ве операций и сжатых сроках (например, dry-run только 1 операции проходит часа за 3-4), выполнять каждый раз перед выполнением проверку — не дозволенная роскошь при окне на все работы в пару часов. Для этого есть тестовый стенд/прогон и пр.
Это я к тому, что все надо с умом применять. Где-то конкретный инструмент покажет потенциальную проблему, а где-то нет. Тут надо думать про «защиты от дурака»/человеческого фактора на другом уровне.
На техническом можно было развернуть резервную систему в ОЗУ и при необходимости переключиться на нее. Вот только там могли быть другие косяки и другие ветви развития событий…
Вариантов решения много, но главная проблема — транспорт.
Сейчас есть другие средства миграции/конвертеры и пр., которые позволяют более-менее мигрировать без головной боли.
Про геройство — кто бы спорил :) Но факт остаётся фактом, ни кто не застрахован от ошибок. Главное из любой ситуации важно выйти и сделать выводы, чтобы в будущем подобные ситуации не повторялись.
Да, думали на эту тему, решили, что быстрее и надёжнее будет восстановить все как было + на static-linked пришлось потратить время на поиск/закачку и пр. Но как вариант это сработает.
Сертификация как результат не важна. А вот подготовка — другое дело. Опыт не всегда перекрывает все темы разом и, как правило, без системный.
Человеческий фактор не всегда предугадаешь. После того случая — только копипаст уже отработанного.
Желательно менеджмент порт на удаленных площадках. Либо второй хост с PXE и управление питанием.
Как альтернатива:
Очень знакомая тема, выполнялось такое многократно.
Про связь оборвалась — был подобный опыт, выкрутиться можно, но седые волосы появятся.