- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
А сложные пути я понимаю, можно и из бекапов поднимать, можно и скопировать данные As is и грузится с sdb (В моем случае) но это все ведет к неизбежному даунтайму системы, который хотелось бы избежать...
К сравнительно небольшому даунтайму если использовать rsync и непосредственно перед перезагрузкой еще раз запустить rsync, потом быстро провести все операции для обеспечения загрузки с нового диска.
Если получится - то можно пробовать идти в казино и подуть на фишки
---------- Добавлено 18.09.2014 в 18:05 ----------
К сравнительно небольшому даунтайму если использовать rsync и непосредственно перед перезагрузкой еще раз запустить rsync, потом быстро провести все операции для обеспечения загрузки с нового диска.
Если в файле дата аналогичная в бекапе, а изменения только в содержимым - rsync этого не заметит, если не включать проверку по контрольной сумме
А с контрольной суммой он работает ОООчень долго
Если в файле дата аналогичная в бекапе
такого не бывает. linux всегда модифицирует время модификации. системного вызова для установки другого времени просто не существует.
такого не бывает. linux всегда модифицирует время модификации. системного вызова для установки другого времени просто не существует.
man 2 utimes
:)
iHead, угу. а если сравнить эту информацию с man 2 stat, то обнаружится, что есть еще и поле ctime, которое изменить через utimes нельзя.
хотя это неочевидно , но ctime тоже меняется автоматически.
По крайней мере в описанной ситуации, когда используются две локальные файловые системы линукса и все программы, кроме ssh останавливаются, rsync будет работать правильно.
Где-то там у Андрейки, вероятно, мог и не работать. но к чему он это вспомнил тут - не известно.
такого не бывает. linux всегда модифицирует время модификации. системного вызова для установки другого времени просто не существует.
А при чем тут модификация время к содержимому?
Есть 2 файла, с одинаковым временем и размером. Однако содержимое их разное - при dd нужный файл забит нулями.
Так вот - rsync скипнет этот файл без опции "-c"
А с этой опцией синк будет идти очень долго.
Есть 2 файла, с одинаковым временем и размером. Однако содержимое их разное - при dd нужный файл забит нулями.
Так их не будет. Я предлагаю не использовать dd, а запускать только rsync два раза.
физику проверяли? sata-кабели, питание?
физику проверяли? sata-кабели, питание?
проверяли и меняли, тоже самое :)
В общем все свершилось. Проделал следующее:
В общем профит таки есть, всем спасибо за советы!!!!
Очень важно, что перед началом сих деяний я плотно прошерстил интернет, наткнулся на кучу манов по теме и проделал массу разных манипуляций, в конечном итоге судя по всему ключевую роль сыграл разбор массива на отдельные винты с последующим write-sector в нужный....