Настройка Переезд на новый компьютер

Переезд на новый компьютер

Автор: Летописец, Дата: 2026-10-19

Проверено на одном реальном переезде (МОСТЕХ ОС, два ноутбука, прямой кабель, 19–20.10.2026): 137 ГБ и 336 тысяч файлов перенесены за час. Всё, что ниже помечено «проверено», взято из этого переезда; остальное — по документации.

Цель переезда — перенести данные и настройки, а не «всё подряд». Поэтому шаги идут в таком порядке: сначала посмотреть, что вообще есть, потом сеть, потом файлы, потом пакеты, потом настройки приложений. И отдельно — то, что переносить нельзя.

Стенд: два ноутбука, МОСТЕХ ОС (форк РОСА), прямой кабель, пользователь tumanov на обоих. Старый ноутбук — источник, новый — приёмник.

Шаг 0. Инвентаризация (на старом ноутбуке, до всего остального)

# что за система и рабочий стол — записать
$ cat /etc/os-release | head -3
$ uname -r
$ echo "$XDG_CURRENT_DESKTOP"

# менеджер пакетов и служба SSH — записать, что нашлось
$ command -v dnf urpmi zypper apt
$ systemctl list-unit-files | grep -i ssh

# пользователь и его UID — записать ОБА числа (на старом и новом)
$ id tumanov

# какие каталоги вообще есть в домашнем каталоге
$ ls -la ~

# что занимает место: крупные каталоги
$ du -h --max-depth=1 ~ 2>/dev/null | sort -h | tail -20

# отдельно — каталоги, которые создал сам (глазами по списку выше)

Записать: сколько всего данных, какие каталоги нужны, какие нет, UID на обеих машинах (они могут различаться — в семействе Mandriva первый пользователь часто 500, в других 1000).

Шаг 1. Список установленных приложений

Не «скопировать все пакеты», а снять список и потом выбрать нужное.

# вариант 1: пакеты, которые ставил пользователь (у dnf)
$ dnf repoquery --userinstalled 2>/dev/null | sort > ~/packages-user.txt

# вариант 2: вся история установок dnf
$ dnf history userinstalled 2>/dev/null | sort > ~/packages-history.txt

# вариант 3: вообще всё установленное (работает всегда)
$ rpm -qa | sort > ~/packages-all.txt

# вариант 4: инструменты ROSA/Mandriva, если dnf не подходит
$ urpmq --list 2>/dev/null | sort > ~/packages-urpmi.txt

Записать: какая из команд дала осмысленный результат. Файл потом переедет вместе с домашним каталогом, если положить его в ~/.

Отдельно выписать то, что важно и не ставится из репозиториев: программы из tar.gz, AppImage, Flatpak (flatpak list), Steam-игры, локальные сборки.

Шаг 2. Сеть: кабель напрямую

Кабель обычный (кроссовер не нужен). Проверить, что линк поднялся:

# на обоих
$ ip -br link
enp3s0   UP   ...     # UP — кабель виден, DOWN — смотреть разъём и порт

Адреса задаются руками — DHCP в такой сети нет:

# что вообще есть: имя подключения и имя интерфейса — РАЗНЫЕ вещи
$ nmcli con show

# старый ноутбук (источник)
$ nmcli con add type ethernet ifname enp3s0 con-name direct ip4 192.168.1.1/24
$ nmcli con up direct

# новый ноутбук (приёмник)
$ nmcli con add type ethernet ifname enp3s0 con-name direct ip4 192.168.1.2/24
$ nmcli con up direct

# проверка
$ ping -c 3 192.168.1.2

Проверено на МОСТЕХ ОС: в настройках интерфейса там адрес задаётся по имени подключения, а не по имени интерфейса — оно выглядит как «Проводное подключение 1». То есть команда для правки существующего профиля такая:

$ nmcli con mod "Проводное подключение 1" ipv4.addresses 192.168.1.2/24
$ nmcli con up "Проводное подключение 1"

Если подставить enp3s0 вместо имени профиля, система ответит, что такого подключения нет, — это не ошибка ввода, а разница между профилем и железом.

Про адреса. В примерах выше 192.168.x.x — специальный диапазон для внутренних сетей. В проверенном переезде использовались адреса вида 192.168.1.x: это публичный диапазон, и на изолированном кабеле он работает, но если машина одновременно в Wi-Fi с интернетом, маршрут к таким адресам может уйти не туда. Для двух ноутбуков берите 192.168.x.x или 10.x.x.x.

Записать: имя интерфейса, что показал ip -br link, получился ли ping с первого раза.

Шаг 3. Приёмник: доступ и место

На новом ноутбуке:

# 1. Сервер SSH на МОСТЕХ ОС уже установлен и запущен — ставить не нужно
$ systemctl status sshd --no-pager | head -3
$ ss -tlnp | grep ':22'                       # слушает ли SSH

# 2. rsync может отсутствовать — проверить и, если нужно, поставить
$ command -v rsync || sudo dnf install rsync

# 3. Место на приёмнике
$ df -h /home

Проверено: на МОСТЕХ ОС openssh-server стоит по умолчанию. Первым делом проверять systemctl status, а не устанавливать пакет.

Брандмауэр — самая частая причина «пинг идёт, а SSH не отвечает»:

$ systemctl is-active firewalld ufw            # что вообще установлено
$ sudo firewall-cmd --add-service=ssh --permanent && sudo firewall-cmd --reload

Записать: имя службы SSH (sshd или ssh), чем управляется брандмауэр, пришлось ли что-то разрешать.

Шаг 3а. Если пинг идёт только в одну сторону

Самая неприятная ситуация: новый ноутбук видит старый, а старый новый — нет. Симптом в выводе ping выглядит так:

From 192.168.1.1 icmp_seq=32 Destination Host Unreachable

Unreachable здесь приходит от вашей же машины — значит, на пакет не ответили даже на уровне «кто здесь» (ARP). Сеть в порядке, адреса верные, кабель тот — а пакеты гасит что-то на самом приёмнике.

Что это было в проверенном переезде: клиент ViPNet (программа защиты/защищённой сети). Он поднимается при входе в систему и по умолчанию закрывает входящие, включая ping и SSH. Признаки, по которым его видно:

пинги шли во время загрузки и пропали, как только появилось окно входа — значит, включилась служба, а не «сломался кабель»;
ssh подключается, но вместо приглашения печатает что-то вроде «Вы подключились к устройству с ViPNet» и висит — это защитный клиент встаёт в середину сессии;
vipnetclient stop без sudo пишет, что «что-то отключил», а пинг не возвращается.

Что помогло:

$ sudo vipnetclient stop            # именно с sudo — остановка настоящая
$ sudo systemctl disable <служба-клиента>   # чтобы не поднимался при старте
$ systemctl reboot

После отключения автозапуска пинги пошли и не пропадали после входа — тогда же заработал и SSH.

Общее правило, а не про конкретную программу: если после входа в систему что-то перестаёт отвечать, а до входа отвечало — ищите службу, которая стартует при входе. Так ведут себя клиенты ViPNet, Secret Net, антивирусы с сетевым экраном, корпоративные агенты. Смотреть, что появилось:

$ systemctl list-units --type=service --state=running | head -30
$ sudo ss -tulpn | head -20

И то же самое стоит держать в голове при обратном переезде: на новой машине защитный клиент может мешать не сети, а копированию — «SSH подключается, но сессия пустая» это он.

Шаг 4. Перенос файлов

Сначала прикидка — она ничего не меняет:

# на СТАРОМ ноутбуке
$ rsync -aHAX --dry-run --info=progress2 \
    ~/Документы ~/Загрузки ~/Проекты \
    tumanov@192.168.1.2:/home/tumanov/

Каталоги перечислить явно — то, что нужно, — и добавить остальные из инвентаризации. Если каталог лежит на отдельном разделе (внешний диск), добавить -x, иначе rsync уйдёт копировать и его содержимое.

Затем настоящий перенос:

$ rsync -aHAX --info=progress2 \
    ~/Документы ~/Загрузки ~/Проекты \
    tumanov@192.168.1.2:/home/tumanov/

Правила:

копировать от имени tumanov, не от root — тогда владельцем на приёмнике станет он сам, и разница в UID не будет иметь значения;
если SSH-сессия может оборваться (долгий перенос), запускать внутри tmux или screen: тогда обрыв связи не убьёт копирование;
оборвалось — та же команда снова: rsync продолжит, а не начнёт заново;
второй проход — в самом конце, перед тем как отдавать ноутбук: он донесёт то, что изменилось за день.

# финальный проход (уже с удалением лишнего — но только если уверен в путях)
$ rsync -aHAX --delete --info=progress2 \
    ~/Документы ~/Загрузки ~/Проекты \
    tumanov@192.168.1.2:/home/tumanov/

Проверенный результат (реальный переезд): 137 ГБ, 336 464 записи (из них 295 409 файлов), 58 минут, средняя скорость 37 МБ/с. Два файла не перенеслись — оба config.toml в ~/Проекты/CICD/..., принадлежали root (их создали контейнеры Docker). rsync под обычным пользователем их просто не прочитал:

rsync: [sender] send_files failed to open ".../config.toml": Permission denied (13)
rsync error: some files/attrs were not transferred (see previous errors) (code 23)

Код возврата 23 — это не «упало», а «перенеслось не всё». На него не надо смотреть как на провал: надо прочитать, что именно пропущено, и добрать. Что и было сделано: chown на эти два файла, затем повторный запуск той же команды — rsync досинхронизировал только их, а не всё заново.

Почему 37 МБ/с, а не ~110. Гигабитный канал даёт около 110 МБ/с на крупных файлах, но здесь было 300 тысяч мелких: скорость упирается в количество файлов и метаданные, а не в провод. 295 тысяч файлов за 58 минут — это около 100 файлов в секунду. Тот же объём одним файлом поехал бы в разы быстрее. Поэтому при переезде домашнего каталога ориентир — не «гигабит», а «сотни тысяч файлов»: считайте часом, а не минутами.

Если файлы, принадлежащие root, нужны вместе с их владельцем, копировать надо от root (и тогда --numeric-ids имеет смысл):

$ sudo rsync -aHAX --numeric-ids /home/tumanov/ tumanov@192.168.1.2:/home/tumanov/

Для домашнего каталога это обычно не нужно: достаточно один раз поправить владельца, как и было сделано.

Шаг 5. Настройки приложений

Здесь главное — не тащить всё, а знать, что где лежит и что дешевле получить заново.

Что	Где лежит	Как переносить
Настройки большинства приложений	`~/.config`, `~/.local/share`	Копировать целиком разумно, но выборочно: там и кэши
Приложения под GTK	`~/.config/dconf`, `~/.config/gtk-3.0`	Копировать
Терминал, оболочка	`~/.bashrc`, `~/.profile`, `~/.ssh/config`	Копировать (это просто текст)
Ключи SSH	`~/.ssh`	Копировать осознанно, затем проверить права `600` на приватные ключи
Ключи GPG	`~/.gnupg`	Копировать, тогда подписи и пароли от почты продолжат работать
Браузер (закладки, пароли)	`~/.mozilla`, `~/.config/google-chrome` и подобные	Лучше входом в аккаунт: синхронизация надёжнее копирования профиля
Почта	`~/.thunderbird`, `~/.local/share/evolution`	Входом в аккаунт; при копировании — вместе с настройками серверов
Менеджер паролей	зависит от программы	Разобраться до переезда: без него остальные пароли придётся восстанавливать
Шрифты, темы	`~/.fonts`, `~/.local/share/fonts`, `~/.themes`	Копировать

Записать: какие приложения реально использовались и что из них не перенеслось.

Шаг 6. Пакеты на новом ноутбуке

Список привезён заранее (положить файл в домашний каталог — он переедет вместе с ним).

# посмотреть, чего из старого списка нет на новом
$ comm -13 <(rpm -qa | sed 's/-[0-9].*//' | sort -u) <(sed 's/-[0-9].*//' ~/packages-all.txt | sort -u)

Ставить не всё: список с прошлой машины — это и старьё, и запчасти для другого железа. Разумный порядок: сначала то, чем пользуешься ежедневно (браузер, редактор, терминальные утилиты), потом остальное по необходимости.

# пример: поставить нужное списком (имена проверить)
$ sudo dnf install $(cat ~/packages-need.txt)

Записать: сколько пакетов было всего и сколько реально понадобилось; чего не нашлось в репозитории.

Шаг 7. Чего переносить нельзя

Это самая полезная часть: здесь не «нельзя», а «что именно сломается».

Что	Почему нельзя	Что будет, если скопировать
`/etc/machine-id`	Уникальный идентификатор машины	Две машины с одним «именем»: путаница в DHCP, журналах, systemd
`/etc/ssh/ssh_host_*`	Ключи хоста SSH	Предупреждения о подмене у всех, кто подключается; придётся чистить `known_hosts`
Драйверы и DKMS-модули	Собраны под конкретное железо	Модули не загрузятся, при худшем раскладе — система не поднимется
Профили Wi-Fi	Привязаны к железу	Не подключаются; завести заново
Сопряжения Bluetooth	Привязаны к адаптеру	Не работают; заводить заново
`/etc` и правки в нём	Половина настроек относится к конкретной установке	«Необъяснимые» поломки, которые ищут неделю
Лицензии и активации ПО	Привязаны к машине или установке	Активация слетит или потребует сброса

Записать: не забыть про ключи хоста — на новом они должны быть свои (создаются сами при установке openssh-server).

Шаг 8. Проверка после переезда

Число файлов совпадает: find ~/Документы -type f | wc -l на обеих машинах
Открылись выборочно: документ, фото, архив
SSH-ключи работают: ssh сервер без пароля
GPG видит ключи: gpg --list-secret-keys
Браузер и почта: вход выполнен, закладки и письма на месте
Менеджер паролей открылся
Печать и сканер, если пользовался
Внешние диски и монтирование, если были
Старый ноутбук не отдавать, пока список выше не закрыт

Проверять не глазами по каталогам, а числами и запуском: «выглядит похоже» — самый дорогой способ проверки.

Что подтвердилось, а что осталось открытым

Проверено на реальном переезде (МОСТЕХ ОС, 19–20.10.2026):

SSH-сервер стоит по умолчанию — устанавливать не нужно;
адрес сети задаётся по имени подключения, а не по имени интерфейса;
защитный клиент (ViPNet) может гасить входящий ping и перехватывать SSH-сессию; лечится sudo-остановкой и отключением автозапуска;
rsync по SSH перенёс 137 ГБ (336 тыс. записей) за 58 минут;
файлы, принадлежащие root, дают Permission denied и код 23; лечится chown и повторным проходом;
скорость на множестве мелких файлов ограничена их количеством, а не каналом.

Осталось непроверенным:

установка пакетов из списка (dnf/urpmi) и перенос настроек приложений — в этом переезде не понадобились;
работа без прямого кабеля (через роутер) и по Wi-Fi;
разные UID на машинах — здесь пользователь на обеих был один;
брандмауэр: в этом переезде мешал не он, а клиент защиты.

Источники

man 1 rsync, man 1 ssh, man 5 sshd_config, man 5 ssh_config.
man 1 nmcli, man 5 nm-settings — настройка проводного соединения вручную.
man 1 dnf, man 8 rpm — списки пакетов (на МОСТЕХ/РОСА команды проверить: семейство RPM, но инструменты могут отличаться).
Оформление шагов опирается на уже написанное: «rsync: синхронизация файлов», «Перенести домашний каталог».

Оценка статьи 0