5. Выполните предварительные задачи

Перед тем как начать перенос с помощью Google Workspace Domain Transfer Divestiture, в исходной и целевой среде необходимо выполнить подготовительные задачи.

После каждого пробного переноса команда, ответственная за перенос домена Google Workspace, предоставляет результаты, в которых указано, какие задачи не выполнены и как устранить эти проблемы.

Задачи, которые нужно выполнить до переноса

Шаг 1. Задачи в исходной среде

  1. Обновите лицензии (если применимо). В ходе переноса лицензии не перемещаются. Если в исходной и целевой среде используются разные версии Google Workspace, переведите исходную среду на версию, соответствующую лицензиям в целевой среде. Более подробные сведения о переносе лицензий приведены в разделе Задачи в целевой среде.

    Примечания

    • В исходной среде можно оформить лицензии пробной версии или льготного периода, чтобы избежать лишних расходов. Однако обратите внимание на следующее:
      • Такие лицензии препятствуют смене любого другого домена на основной. Смените основной домен до того, как инициализировать временные лицензии.
      • Если в целевой среде доступны полные лицензии, то после переноса пользователям будут назначены полные лицензии.
    • Пользователи в исходной среде, которым не назначены лицензии, все равно переносятся.
  2. Отмените подписки на неподдерживаемые лицензии. В некоторых случаях вам нужно удалить неподдерживаемые лицензии у переносимых пользователей, а пользователи, не подлежащие переносу, могут сохранить свои лицензии. В противном случае вам необходимо полностью отменить или удалить все неподдерживаемые лицензии. Пробный прогон позволяет определить, какие лицензии нужно отменить.

    Вы должны отменить подписку на Google Voice для всех пользователей. При отмене подписок могут возникать сложности. Если в исходной среде используется Google Voice, будьте особенно внимательны при выполнении этого шага. Подробная информация приведена в разделе Лицензии исходной среды.

  3. Назначьте новый основной домен, если вы хотите перенести текущий основной домен. Этот шаг необходим, только если вы хотите перенести текущий основной домен. Выполните замену домена, назначив любой другой домен новым основным доменом .Для этой цели можно использовать любой домен, который нельзя перенести.

    Подготовка к смене домена:

    Когда вы будете готовы изменить домен, перейдите к статье "Как изменить основной домен для Google Workspace".

    • Отмените все подписки для устройств, включая оборудование Google Meet и Chrome Enterprise.
    • Перед переносом может потребоваться удалить некоторые неподдерживаемые лицензии. Подробная информация приведена в разделе Лицензии исходной среды.
    • Если в исходной среде используются лицензии пробных версий, назначить формальный домен основным не удастся. Сделайте это до того, как инициализировать временные лицензии.
    • При изменении основного домена и использовании дополнительных доменов могут возникать некоторые известные проблемы. Узнайте, что можно сделать вместо смены основного домена.
    • После изменения основного доменного имени не переименовывайте переносимых пользователей или группы. Пользователи и группы должны оставаться в своих переносимых доменах.
    • Если у вас настроена система единого входа с помощью стороннего поставщика идентификационной информации и вы используете издателя, связанного с вашим доменом, утверждения SAML отражают изменение основного домена. Проверьте конфигурацию поставщика идентификационной информации, чтобы убедиться, что пользователи могут выполнить аутентификацию после смены основного домена. Подробнее о требованиях к утверждениям системы единого входа…
  4. Настройте правила хранения данных в Сейфе. Задайте специальные правила бессрочного хранения.

    Создайте по правилу для каждого из следующих приложений:

    • Gmail. В качестве значения параметра "Организационное подразделение" выберите корневое организационное подразделение.
    • Google Группы. В качестве значения параметра "Группы" выберите "Все группы".

    Создайте по два правила для следующих приложений:

    • Chat. Выберите Организационное подразделение > корневое организационное подразделение. Для второго правила выберите Все чат-группы Chat.
    • Диск. Выберите Организационное подразделение > корневое организационное подразделение. Для второго правила выберите Все общие диски.
    • Meet. Выберите Организационное подразделение > корневое организационное подразделение и включите параметр Включить файлы с общих дисков. Для второго правила выберите Все общие диски.
    • Сайты. Выберите Организационное подразделение > корневое организационное подразделение, а также включите параметр Включить файлы с общих дисков. Для второго правила выберите Все общие диски.

    Кроме того, прежде чем начинать перенос, система создает в целевой среде специальные правила бессрочного хранения. Дополнительные сведения приведены в разделе Бессрочное хранение данных в Google Сейфе в целевой среде. Подробнее о переносе данных Сейфа с помощью переноса домена…

  5. Создайте резервную копию объектов Сейфа и удалите ссылки на переносимые объекты. Скачайте и сохраните конфигурации и отчеты Сейфа для переносимых объектов, так как после переноса они могут быть недоступны в исходной среде. В эту информацию входят дела, запреты на удаление, поисковые запросы и экспортированные данные.

    После создания резервной копии удалите ссылки на объекты переноса из артефактов Google Сейфа. Если какие-либо объекты Сейфа содержат ссылки на переносимые объекты, Сейф возвращает ошибки и может быть недоступен.

    • Правила хранения и сохранения не применяются к объектам переноса, для которых не действуют запреты на удаление.
    • Удалите все ссылки на перенесенных пользователей, группы и общие диски из дел, общих списков, запретов на удаление и правил хранения. В Сейфе нельзя установить запрет на удаление в одном клиенте, который ссылается на объект в другом клиенте.
    • Чтобы сохранить запреты на удаление пользовательских данных переносимых пользователей в исходном клиенте, администраторы должны создать нового пользователя, не предназначенного для переноса, и скопировать все данные Gmail и Диска из переносимых пользователей с запретом на удаление новому пользователю. Затем заархивируйте новых пользователей, не подлежащих переносу, и убедитесь, что они относятся к домену, не подлежащему переносу. Вместо этого создайте аналогичные правила хранения Vault для нового пользователя, не подлежащего переносу, и удалите правила хранения для исходного переносимого пользователя.
    • Чтобы сохранить блокировки пользовательских данных при переносе в целевой клиент, используйте резервные копии, чтобы добавить эквивалентные блокировки в целевом клиенте после переноса.
    • Удалять косвенные ссылки не нужно. Косвенные ссылки относятся к организационному подразделению, в котором находится переносимый пользователь.
    • Удалять ссылки в завершенных поисках и экспортах не нужно. Эти ссылки скачиваются.
  6. Обновите запись SPF (если применимо) – если шлюз исходящей почты в исходной и целевой средах различается, добавьте в запись SPF исходной среды шлюз исходящей почты целевой среды.

    Примечание. Если вы используете DKIM, перенос не должен повлиять на правила DMARC. После переноса запись SPF будет применяться корректно, даже если DKIM временно не будет использоваться. Также не забудьте после переноса выполнить необходимые шаги в целевой среде.

  7. Оцените, как перенос может повлиять на связанную организацию Google Cloud (если применимо). Если вы работаете с Google Cloud, уведомьте администраторов этой платформы о возможных последствиях использования Google Workspace Domain Transfer Divestiture для Google Cloud. Если вам требуется помощь в оценке последствий и выполнении дальнейших действий, обратитесь к своему партнеру Google Cloud или контактному лицу в Google Cloud. Команда Google Workspace Domain Transfer Divestiture не предоставляет поддержку Google Cloud на этапе переноса домена.
  8. Уведомьте своего реселлера Google Workspace (при наличии). Сообщите запланированное время переноса домена и попросите не вносить изменения в аккаунт (например, не обновлять подписки) в период переноса.
  9. Зарегистрируйтесь во всех программах альфа- и бета-тестирования, в которых участвует исходная или целевая среда (при наличии). Регистрации в программах альфа- и бета-тестирования из исходной среды не переносятся. Аналогичным образом, исходная среда может быть зарегистрирована в программах, распространяющихся на объекты целевой среды. Чтобы и далее участвовать в этих программах, необходимо подать заявку и получить одобрение для той среды, которая ещё не зарегистрирована.
    Рекомендуем зарегистрироваться в программах альфа- и бета-тестирования до переноса, чтобы пользователи не лишились доступа к функциям. При этом для регистрации может потребоваться определенное время, или участие в программе могут не одобрить. Поэтому это требование не является обязательным.

  10. Как перенести устройства Chrome с автоматической настройкой
    1. В исходной среде отмените существующий токен предварительной инициализации и деинициализируйте все устройства. Сбросьте настройки устройств до заводских.
    2. В целевой среде создайте новый токен предварительной инициализации.
    3. Предоставьте новый токен своему авторизованному партнеру по предварительной инициализации, чтобы он предварительно инициализировал устройства в целевой среде.

    Устройства зарегистрируются автоматически после подключения к интернету. Статус устройства изменится на "Инициализировано".

    Подробнее об устройствах с автоматической настройкой…

  11. Обновите участие в группах. Удалите всех переносимых пользователей и группы из групп, не подлежащих переносу, и всех пользователей и группы, не подлежащие переносу, из переносимых групп. Например, удалите user@to-stay-insource.com и group@to-stay-insource.com из group@to-be-transfer.com.

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

  12. Удалите переносимых пользователей и группы из целевых аудиторий. Целевые аудитории не переносятся, поэтому после переноса администратор целевой среды не сможет управлять целевыми аудиториями исходной среды.

    Примечание. Этот шаг необязателен, поскольку целевые аудитории позволяют ссылаться на внешних пользователей и группы. У пользователей сохранится доступ к документам, которыми поделились с целевыми аудиториями.

  13. Обновите правила на основе групп. Удалите все правила на основе групп, которые ссылаются на группы переноса из исходного клиента.

    Важно! Если исходный клиент содержит правила на основе групп, которые ссылаются на группы переноса, правило на основе групп исчезает из консоли администратора и становится недоступным для редактирования. Он по-прежнему действует для всех пользователей, не подлежащих переносу, в группе переноса, но вы не можете его посмотреть или изменить. Это ещё одна причина удалить межклиентские группы на шаге 12.

  14. Настройте базовое управление мобильными устройствами – отмените инициализацию управления мобильными устройствами для переносимых пользователей или настройте базовое управление.

  15. Персонализированные каталоги. Известна проблема с персонализированными каталогами. Специальные каталоги не переносятся, и перед переносом необходимо удалить все группы переноса.

    Важно! Если не удалить группы переноса, каталог станет недоступен для редактирования и удаления, а его поведение может быть непоследовательным.

  16. Обновите членство в организационном подразделении. Убедитесь, что в исходной среде в одном организационном подразделении нет как переносимых, так и непереносимых пользователей. Переносимые и непереносимые пользователи должны находиться в разных подразделениях и не могут быть объединены в одном подразделении в исходной среде.

  17. Обновите автоматическое назначение лицензий. Для организационных подразделений, содержащих перенесенных пользователей, убедитесь, что автоматическое назначение лицензий отключено.

Шаг 2. Задачи в целевой среде

  1. Создайте целевую среду. Google Workspace Domain Transfer Divestiture не создает целевую среду Google Workspace автоматически. Его нужно создать заранее. В целевой среде необходимо настроить оплату и подтвердить право собственности на основное доменное имя.
  2. Лицензии не переносятся, поэтому подготовьте достаточно свободных лицензий Google Workspace для переносимых пользователей. При переносе пользователям в целевой среде назначаются те же лицензии, которые были у них в исходной среде, поэтому в момент переноса в целевой среде должно быть достаточно свободных лицензий того же типа.

    Если в целевой среде используется другая версия Google Workspace, обновите лицензии в исходной или целевой среде, чтобы обеспечить соответствие.

    Примечания

    • Google рекомендует перевести лицензии на версию с расширенной функциональностью, чтобы избежать процедуры удаления данных из сервисов.
    • Предоставьте недостающие лицензии, чтобы в целевой среде было несколько подписок. После переноса домена вы сможете при необходимости перевести отдельных пользователей на нужную версию лицензии. Учтите, что не все типы лицензий поддерживают выборочное лицензирование.
    • Убедитесь, что в целевой среде есть достаточно свободных лицензий. Необходимо учитывать новых пользователей (например, новых сотрудников), которые могут добавиться в период с даты начала до даты завершения переноса. Если выполняется несколько переносов, учтите также общее количество пользователей в них.
    • Пользователи в исходной среде, которым не назначены лицензии, все равно переносятся. Отслеживайте автоматическое назначение лицензий в целевой среде, чтобы им не были назначены лицензии.
    • При переносе домена не предлагаются специальные тарифные планы Google Workspace для приобретения свободных лицензий. Если лицензии в исходной среде предоставлены в рамках годового тарифного плана, они продолжают действовать и за них списывается плата до конца срока действия договора. Дополнительные вопросы о тарифных планах Google Workspace вы можете задать своему торговому представителю или менеджеру аккаунта.
  3. При наличии нескольких лицензий убедитесь, что они правильно назначаются переносимым пользователям. Некоторые конфигурации целевой среды могут влиять на то, как лицензии распределяются между переносимыми пользователями. В результате пользователям могут быть назначены неправильные лицензии. Конфигурации, при которых может возникать эта проблема: автоматическое назначение лицензий и сценарии переопределения автоматического назначения лицензий для отдельных организационных подразделений.

    Чтобы при переносе все лицензии были назначены правильно, выполните приведенные ниже действия.

    • Если в целевой среде для автоматического назначения лицензий выбран параметр "Отключено для всех" или есть только один тип лицензии, то ничего менять не нужно.
    • Если в целевой среде для автоматического назначения лицензий выбран параметр "Включено для всех" (например, для лицензий Google Workspace), то необходимо включить переопределение для некоторых организационных подразделений. Для перенесенного корневого организационного подразделения убедитесь, что автоматическое назначение лицензий отключено и нет переопределений для дочерних организационных подразделений.
  4. Создайте целевое корневое организационное подразделение, используя при необходимости структуру организационного подразделения в исходной среде. Оно будет использоваться в качестве родительского организационного подразделения для всех переносимых пользователей. После этого есть два варианта:

    • Не выполнять никаких действий. В процессе переноса домена будет воссоздана структура организационных подразделений из исходной среды в новом корневом организационном подразделении переноса. Для этого параметру "Предварительное воссоздание структуры организационного подразделения" необходимо задать значение "Нет". Все переносимые пользователи могут наследовать правила, примененные на уровне организационного подразделения.
    • Вручную воссоздать исходную структуру для целевого корневого организационного подразделения. При переносе домена проверяется, правильно ли воссоздана структура исходного организационного подразделения, прежде чем начинать перенос. Для этого параметру "Предварительное воссоздание структуры организационного подразделения" нужно задать значение "Да". Это необходимо, если вы хотите применить разные правила для разных дочерних организационных подразделений.

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

  5. Задайте подходящие правила и настройки в соответствии с требованиями исходной и целевой сред. Правила и настройки исходной среды не переносятся в целевую. Кроме того, после переноса домена на пользователей и их данные распространяются только правила и настройки целевой среды.

    Вам необходимо изучить правила и настройки целевой среды и сравнить их с исходной средой. Это касается как общих настроек, так и настроек перенесенного корневого организационного подразделения. Они должны охватывать все переносимые объекты и пользователей.

    Ниже приводится неполный список правил и настроек, которые необходимо проверить в процессе подготовки. Также необходимо провести полную проверку обеих сред, чтобы убедиться, что проанализированы все нужные разделы.

    • Включение сервисов (Включен/Отключен). Убедитесь, что сервисы, которые вы используете в исходной среде, включены в целевой среде и перенесенное корневое организационное подразделение работает правильно. Это особенно важно, если вы используете Google Сейф, так как правила Сейфа могут не применяться, если сервис отключен.
    • Gmail, расширенные настройки и записи MX. Проверьте маршрутизацию почты, правила соответствия, включение IMAP и делегирование. Подробнее о том, как активировать Gmail в Google Workspace…
    • Управление паролями. Убедитесь, что правила для паролей не противоречат политикам организации. Как только переносимые пользователи попадут в целевую среду, к ним начнут применяться ее правила управления паролями.
    • Двухэтапная аутентификация. Эта настройка определяет, разрешено ли пользователям добавлять конфигурацию двухэтапной аутентификации в свои аккаунты или она применяется принудительно. Если пользователи, для которых включена двухэтапная аутентификация, переносятся в целевую среду или организационное подразделение, где двухэтапная аутентификация отключена, администраторы целевой среды не смогут управлять такими пользователями. Чтобы решить эту проблему, администраторам необходимо переместить таких пользователей в другое организационное подразделение, где включена двухэтапная аутентификация, или удалить настройку двухэтапной аутентификации из их аккаунтов до переноса.
    • Настройки доступа. Определяют, могут ли сотрудники организации делиться своим контентом с внешними пользователями. Если в исходной среде внешний доступ заблокирован, а в целевой среде нет, то переносимый контент может стать доступным пользователям за пределами организации. Если в исходной среде внешний доступ разрешен, а в целевой заблокирован, то переносимый контент может стать недоступным для сотрудников организации. Подробнее о параметрах доступа для Google Диска и Google Календаря…
    • Защита от потери данных (DLP). Использует правила защиты данных, чтобы отслеживать конфиденциальную информацию и блокировать предоставление к ней доступа внешним пользователям. Если в исходной среде действуют правила DLP, а в целевой среде нет, то после переноса пользователи в целевой среде смогут делиться конфиденциальной информацией за пределами организации. Подробнее о правилах DLP и защиты данных и правилах соответствия содержания для Gmail…
    • История чата. Эти настройки определяют, включена или отключена запись истории чата, а также могут ли пользователи принудительно применять настройку для всех чатов или задавать параметр по умолчанию. Если в исходной среде разрешена запись истории чата, а в целевой среде она принудительно отключена, то история чата будет потеряна. Сервис Google Chat будет помечен как неподдерживаемый для переноса, но прямая переписка будет перенесена.
    • Страна или регион данных. Эта настройка определяет географическое местоположение, в котором сохраняются перенесенные данные. Для переносимых пользователей, чьи данные должны храниться в определенном регионе, нужно правильно задать эту настройку в целевой среде, чтобы данные случайно не оказались не в том регионе. Подробная информация приведена в статье Как выбрать регион хранения данных.
    • Менее защищенные приложения (доступные в разделе "Пароли приложений"). Если менее защищенные приложения включены в исходной среде, а в целевой – нет, то при подключении к такому приложению появится сообщение о превышении времени ожидания и приложение закроется. Время ожидания зависит от приложения, но обычно не превышает 60 минут. Дальнейшие запросы на доступ от небезопасных приложений блокируются. Подробнее о том, как управлять доступом к небезопасным приложениям…
    • Области действия OAuth, система единого входа для SAML, надежные приложения и расширения Chrome. Элементы управления OAuth определяют уровень доступа API, разрешенный пользователям и сторонним приложениям. Система единого входа для SAML, предоставляемая Google Workspace или реализованная в виде собственного приложения, позволяет пользователям получать доступ к другим приложениям и сервисам с помощью учетных данных Google Workspace. Надежными называются приложения, которые пользователи могут устанавливать из Google Workspace Marketplace или интернет-магазина Chrome. Этим приложениям также разрешено обходить ограничения OAuth. Подробнее о том, как управлять сторонними и внутренними приложениями, системой единого входа для SAML, приложениями из Google Workspace Marketplace, а также приложениями и расширениями Chrome…
    • Делегирование доступа к данным в домене предоставляет приложениям доступ к данным Google Workspace пользователей. Чтобы клиенты и области действия работали корректно, перед переносом настройте делегирование доступа к данным в домене в целевой среде.

    Важное примечание. Если настройки и правила заданы неправильно, это может привести к следующим последствиям:

    • Непреднамеренное предоставление доступа к данным пользователям за пределами организации (например, если в целевой среде меньше ограничений, чем в исходной).
    • Ограничение доступа к ранее доступным данным (например, если в целевой среде больше ограничений, чем в исходной).
  6. Примите в целевой среде соглашения, регулирующие обработку перенесенных данных: Поправку в отношении обработки данных (DPA), условие типового договора и Дополнение к соглашению между деловыми партнерами, касающемуся соблюдения требований HIPAA. Подробные сведения приведены в статье Соблюдение требований к конфиденциальности в Google Workspace и Cloud Identity.
  7. Включите Сейф, если он используется в исходной среде.
  8. Уведомьте своего реселлера Google Workspace (при наличии). Сообщите запланированное время переноса домена и попросите не вносить изменения в аккаунт (например, не обновлять подписки) в период переноса.
  9. Зарегистрируйтесь во всех программах альфа- и бета-тестирования, в которых участвует исходная или целевая среда (при наличии). Регистрации в программах альфа- и бета-тестирования из исходной среды не переносятся. Аналогичным образом, исходная среда может быть зарегистрирована в программах, распространяющихся на объекты целевой среды. Чтобы и далее участвовать в этих программах, необходимо подать заявку и получить одобрение для той среды, которая ещё не зарегистрирована.
    Рекомендуем зарегистрироваться в программах альфа- и бета-тестирования до переноса, чтобы пользователи не лишились доступа к функциям. При этом для регистрации может потребоваться определенное время, или участие в программе могут не одобрить. Поэтому это требование не является обязательным.

Важно!

  • При переходе на версии с ограниченной функциональностью некоторые сервисы Google Workspace и их функции могут стать недоступны. Прежде чем вносить изменения, внимательно изучите различия в версиях Google Workspace и проанализируйте последствия перехода на другую лицензию. Подробнее о версиях Google Workspace…
  • При переходе на версии с ограниченной функциональностью может быть запущена процедура удаления данных из сервисов, в результате чего перенос может быть отложен на срок до 90 дней.

Шаг 3. Другие задачи и рекомендации

  • Управление изменениями. В процессе переноса ни команда Google Workspace по переносу доменов, ни система не предоставляют пользователям информацию о его ходе. Настоятельно рекомендуем представителям исходной и целевой сред заранее сообщить пользователям о переносе и его возможных последствиях.

    На время переноса блокируются все возможности администрирования как в исходной, так и в целевой среде, включая доступ через API и консоль администратора Google. Настоятельно рекомендуем представителям исходной и целевой сред сообщить всем суперадминистраторам и уполномоченным администраторам домена о начале и завершении переноса.

  • Внешние зависимости. Если вы используете Google Cloud Directory Sync (GCDS), GAM (сторонний инструмент командной строки для администраторов Google Workspace, позволяющий управлять настройками доменов и аккаунтов пользователей) или систему единого входа от стороннего поставщика, проанализируйте последствия переноса. Также изучите, как объединение исходной и целевой сред в одной среде повлияет на вашу систему и временные рамки для переноса.

Бессрочное хранение данных в Google Сейфе в целевой среде

Google Workspace Domain Transfer Divestiture устанавливает специальные правила бессрочного хранения в целевой среде. Администраторам целевой среды не нужно выполнять никаких действий.

При переносе из исходной среды перемещается архив Сейфа для переносимых пользователей, но не правила хранения. Чтобы не ставить под угрозу данные Сейфа во время и после переноса, система создает в целевой среде перечисленные ниже правила хранения, прежде чем начинать перенос.

  • Gmail – специальное правило бессрочного хранения (область действия: целевое корневое организационное подразделение).
  • Google Calendar – специальное правило бессрочного хранения (область действия: перенесенное корневое организационное подразделение).
  • Google Chat – специальное правило бессрочного хранения (область действия: прямая переписка с переносимыми пользователями в перенесенном корневом организационном подразделении, но не в чат-группах).
  • Google Диск – специальное правило бессрочного хранения, не включающее общие диски (область действия: целевое корневое организационное подразделение).
  • Google Группы – специальное правило бессрочного хранения (область действия: корневое организационное подразделение). Оно распространяется на хранение данных во всех группах в целевой среде, даже тех, что не включены в перенос.
  • Google Meet – создаются два специальных правила бессрочного хранения:
    1. Не включающее общие диски (область действия: целевое корневое организационное подразделение).
    2. Включающее общие диски (область действия: корневое организационное подразделение).

      Это правило распространяется на хранение данных на всех общих дисках в целевой среде, даже тех, что не включены в перенос.

  • Google Сайты – создаются два специальных правила бессрочного хранения:
    1. Не включающее общие диски (область действия: целевое корневое организационное подразделение).
    2. Включающее общие диски (область действия: корневое организационное подразделение).

      Это правило распространяется на хранение данных на всех общих дисках в целевой среде, даже тех, что не включены в перенос.

  • Общие диски – специальное правило бессрочного хранения для всех общих дисков (область действия: корневое организационное подразделение). Это правило распространяется на хранение данных на всех общих дисках в целевой среде, даже тех, что не включены в перенос.

Важно! Правила хранения Сейфа в целевой среде не удаляются и не изменяются в процессе переноса, так как это может привести к необратимой потере данных.