How to migrate the storagenode Windows to Linux

I have the storagenode in Windows and it runs on Docker. The disk filesystem is NTFS.

I need to migrate to Linux Debian and not to loose the node.

What should I do in this case?
Can I simply get the HDD from Windows PC and put the disk to a different machine on Linux or I should make a migration with some specific instrument on different machine with different disk via lan?

Linux can read NTFS, but can be safer to copy over network from windows host to linux host.

  1. NTFS is MS proprietary filesystem, and while linux can read and write it, if there is anything wrong with it, it may not be as well equipped to handle it as windows.
  2. If the disk is old – it is not unheard of (old) disks failing to spin up or developing bad sectors after years of flawless operation, due to some minor stresses during move. It has happened to me repeatedly – take old disk from a perfectly working array, 0 bad sectors, with monthly scrubs, just as part of maintenance, attach to another machine, scan – and bam, multiple bad sectors.

Alternatively, you can run chkdsk on a disk, to correct all possible inconsistencies in the filesystem and then move the disk to linux computer… but I would still feel safer letting the proprietary OS deal with its proprietary FS.

1 Like

I would add, if your Windows is Windows 10/11, it uses deduplication and encryption features of NTFS by default. You may have issues with this disk on Linux, because Linux doesn’t support these features out of the box, so your node may start to failing audits, because it cannot read deduplicated/encrypted data. NTFS working noticeable slower under Linux, so your node will start to use much more RAM. The integrated tools to check NTFS disk under Linux is not fully compatible, so to check and fix the filesystem you would need to reconnect this disk to the Windows PC and check it there.
So, either disable deduplication and encryption for this disk, check the filesystem and try to use it under Linux keeping in mind all limitations or migrate data to the ext4 disk.

1 Like

Got it. I have a small amount of HDDs for insurance on warehouse so I will go with migration to the ext4 disk.
Thanks to arrogantrabbit and Alexey for solving my questions.

PS please look for
problem-with-pulling-storagenode-image-to-docker
topic.
I’m trying to keep the nodes alive while I’m experimenting with migration and avoid silly moves in haste.

1 Like

Добрый день!
Возник вопрос по команде копирования rsync:
Какой флаг в команде нужно использовать для копирования файлов, чтобы значения owner и permissions менялись при копировании автоматически на owner и permissions директории в которую производится копирование?

На текущий момент команда выглядит так:

sudo rsync -aP -e "ssh -p XX" -v /mnt/g/identity/storagenode/ user@192.168.1.X:/var/storj/storagenode1/identity

файлы копируются с owner user:user.
у директории owner user:docker.

Также если создать новую поддиректорию в /var/storj/ через mkdir из под пользователя, присваивается user:user, хотелось бы чтобы при создании получало `user:docker’.

-a это тоже самое что -rlptgoD, где

 -p, --perms                 preserve permissions
 -o, --owner                 preserve owner (super-user only)

Если вы не хотите чтоб копировался владец и разрешения — не указывайте эти флаги.

https://linux.die.net/man/1/rsync

А зачем? Права на файлы и директории соответвсут тому кто их создал. Можно конечно вот с этим поиграть, иногда даже работает: linux - How to set default file permissions for all folders/files in a directory? - Unix & Linux Stack Exchange

Эти флаги не указывал - они будут бесполезны при переносе с windows в linux.
Часто бывало что переносе узла с одного диска на другой (в Windows) возникал конфликт прав и владельцев, поэтому пытаюсь понять как сделать так,
чтобы файлы при копировании записывались с параметрами директории.

У меня нет базовых знаний, поэтому всё читаю и анализирую в процессе в рамках очередного кейса.
Часто мои предположения и выводы далеки от того что должно быть на самом деле:)
В данном случае:
если я создал директорию var/storj с -o user:docker,
значит для дальнейшей корректной работы узла после его запуска
у файлов в этой директории должны быть те же параметры.
Чтобы user и docker могли rwd и exec все файлы в директории.
Или это ошибочно и user:user в качестве владельца будет достаточно?

права выглядят так:

ls -l /var/storj/storagenode1/data
total 68
drwxr-xr-x 2 user user  4096 Sep 27 10:43 bin
-rw------- 1 user user  8533 May 20 21:07 config.yaml
drwx------ 4 user user  4096 Feb 24  2021 orders
drwxr-xr-x 2 user user  4096 Sep 30 02:40 retain
-rw------- 1 user user 32768 Sep 30 10:45 revocations.db
drwxrwxrwx 7 user user  4096 Sep 30 15:00 storage
drwx------ 2 user user  4096 Sep 30 15:02 storagenode
-rw------- 1 user user   933 Sep 30 10:45 trust-cache.json

если бы вы не указали -p ( косвенно, через -а), то результат бы был точно как вы хотели:

New files get their “normal” permission bits set to
the source file’s permissions masked with the
receiving directory’s default permissions (either
the receiving process’s umask, or the permissions
specified via the destination directory’s default
ACL), and their special permission bits disabled
except in the case where a new directory inherits a
setgid bit from its parent directory.

полный текст
       --perms, -p
              This option causes the receiving rsync to set the
              destination permissions to be the same as the source
              permissions. (See also the --chmod option for a way to
              modify what rsync considers to be the source permissions.)

              When this option is off, permissions are set as follows:

              o      Existing files (including updated files) retain
                     their existing permissions, though the
                     --executability option might change just the
                     execute permission for the file.

              o      New files get their "normal" permission bits set to
                     the source file's permissions masked with the
                     receiving directory's default permissions (either
                     the receiving process's umask, or the permissions
                     specified via the destination directory's default
                     ACL), and their special permission bits disabled
                     except in the case where a new directory inherits a
                     setgid bit from its parent directory.

              Thus, when --perms and --executability are both disabled,
              rsync's behavior is the same as that of other file-copy
              utilities, such as cp(1) and tar(1).

              In summary: to give destination files (both old and new)
              the source permissions, use --perms.  To give new files
              the destination-default permissions (while leaving
              existing files unchanged), make sure that the --perms
              option is off and use --chmod=ugo=rwX (which ensures that
              all non-masked bits get enabled).  If you'd care to make
              this latter behavior easier to type, you could define a
              popt alias for it, such as putting this line in the file
              ~/.popt (the following defines the -Z option, and includes
              --no-g to use the default group of the destination dir):

                  rsync alias -Z --no-p --no-g --chmod=ugo=rwX

Зависит от реализации демона на виндоусе и как производится копирование - через rsync транспорт или сетевые диски.

Если вы копируете на сетевой диск то права будут такие же как и у соединения. Если через rsync транспорт — то может быть что угодно.

Тут куча ньюансов. Права и владельцы должны действительно быть настроены так чтобы storagenode могла читать и писать файлы, это не значит что владелец должен совпадать. Можно просто дать группе Everyone r/w доступ, и тогда вообще будет неважно кто владелец.

В документации тут написано Storage Node - Storj Docs что можно передать user id и group id через параметр

--user $(id -u):$(id -g)

Тут берется значие текущего пользователя, кто запускает docker run и узел будет запущен от имени этого пользователя. (Это не значит что численное значение id внутри и снаружи контейнера будет одинаковым!)

Теоретически, можно копировать данные как угодно, и потом передать в --user UID и GID владельца файлов. Практически, работоспособность этого будет зависеть от наличия SELinux или AppArmor на машине. Если они запущены, то пространство имен внутри контейнера и хоста разные. Пользователь 313 на хосте может будет соответствовать пользователю 100312 внутри контейнера. Потому так вот назначать права не получится.

Самый надежный способ – это скопировать c какими попало владельцем (или указать владельца через --chown) но дать права читать/писать всем через аргумент --chmod, например, так

rsync -a --chmod=ugo=rwX

Затем запустить контейнер, запустить новый Шелл в контейнере и перезаписать владельца на все файлы изнутри контейнера на пользователя который запускает узел. После этого можно убрать права на g и o, и оставить только u=rw, и получится как права на config.yaml тут:

Можно, конечно, не заморачиваться и оставить как есть, с o=rwX (как сейчас стоит на storage:)

Нюанс тут:

Эта команда с хоста или внутри контейнера? “user:user” на хосте может не соответствовать ничему в конетейнере. Потому нужно это проверять из оболочки изнутри контейнера.

Подъитоживая:

  1. rsync -a --chmod=o=rwX ...
  2. docker run -it <container name or id> /bin/sh
  3. подсмотреть кто владеет config.yaml: stat config.yaml
  4. назначить рекурсивно того-же владельца на storage: sudo chown -R meow:woff /mnt/storage/blobs
  5. Убрать доступ группе g и o – sudo chmod -R 600 /mnt/storage/blobs
2 Likes

Это команда через терминал на хосте.

так как команда уже запущена и копирование идёт около 7 часов, сейчас уже ничего трогать не буду.
по окончании через Х дней, сделаю chown и chmod, поменяю характеристики при повторном запуске.

1 Like

Поправка:

Должно быть как выше по тексту

1 Like

Не быстрая история - перегнать по локалке 2,5TB.
За 19 часов примерно 6% (130GB).

Предполагаю что 4 узла с примерно +/- 2,5TB будут копироваться месяц.

“Хорошо” что объём данных на узлах снизился, было в среднем 8TB/диск.

Надеюсь что повторные синхронизации на порядок меньше времени займут.