А просто. Делаете rclone sync в Storj bucket, потом - либо rclone sync обратно на новый диск, либо используете cunoFS и запускаете узел.
Без второго - смысла немного делать бэкап узла, который устареет в момент его завершения, если он был онлайн. Но - возможно.
Правильная последовательность будет:
rclone sync пару раз пока узел работает
отключить узел и сделать ещё раз rclone sync
потом - если оно было в Storj bucket, надо всё либо на локальный диск rclone sync, или использовать cunoFS, причём, скорее всего - без mount и запустить узел.
Больше чем уверен - работать будет. Однако, тут надо считать, разница между ценами на использование bucket и оплатой узла - заметная. Работать, скорее всего - будет. Будет ли выгодно - скорее всего, - нет.
На сколько понял речь идёт про непосредственно использование продукта,
к моему стыду, за 4 года в статусе node оператора ни разу не удосужился попробовать платформу в качестве клиента, моё упущение исправлюсь.
Помимо параметра стоимости есть ещё параметр время.
На данный момент процесс переноса данных через rsync крайне утомителен и растянут, надеюсь получиться распараллелить через rclone sync - мощность машины позволяет и не пользоваться этим большой грех.
Условно 17 дней у меня заняло 1ое исполнение команды, сколько всего на перенос узла времени уйдёт - вообще не известно.
У меня 4 узла (из тех, которым нужен перенос) и большая мечта хотя бы в этом году это завершилось.
Всё вышенаписанное сводится к тому, что время дороже и подчас дешевле сделать быстрее, заплатить и двигаться дальше, чем висеть в одном процессе бесконечно, забывая к моменту следующего действия 70% того что делал до этого.
Верно. Но это - пока что не подтверждённая функциональность. Очень сильно зависит от производительности обоих систем. Поэтому пока что - не добавлена в документацию, как возможность сделать тоже самое, но - быстрее.
Если подтвердите, что такой способ для вас быстрее, мы обязательно это добавим в документацию (с оговорками, разумеется. rsync работает для всех платформ одинаково).
я думаю, что больше важно, когда снизится время для синхронизации. Я бы рекомендовал изменить объём предоставленного места ниже использованного (по dashboard), тогда новых загрузок не будет и синхронизация пройдёт гораздо быстрее.
Через пару часов должен закончиться 6 или 7 (уже сбился) синк и хочу запустить уже финальный с --delete
и как обычно осенило ещё раз посмотреть гайд по переносу узла на: https://storj.dev/node/faq/migrate-my-node
Там сказано что identity, orders, storage нужно копировать отдельными процессами.
Я лью одним куском как обычно делал на Windows, за исключением DB - они на отдельном диске.
Такое копирование не нанесёт вреда узлу после финального синка и запуска на другом диске?
Неважно как копировать, хоть одним куском хоть семидесятью. Главное чтобы последнее копирование было бы синхронизацией с выключенными узлом. Все пляски с копированием в восемнадцать этапов нужны только чтобы ускорить завершающую синхронизацию и сократить время в течении которого узел будет недоступен.
