Обновление до Zmanda 4.1.3: мощная система резервного копирования корпоративных данных

Обновление до Zmanda 4.1.3 | Резервное копирование данных

В Zmanda мы, как правило, выпускаем основные версии обновлений, чтобы предоставить нашим клиентам лучшее решение для управления корпоративными данными. Мы сделали это снова, на этот раз добавив последний строительный блок к нашей платформе в виде выпуска Zmanda 4.1.3, и это БОЛЬШОЕ!

Представляем Zmanda 4.1.3: Power Plus Power.

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

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

Как перейти со старой версии на Zmanda 4.1.3?

Вот краткий обзор различных способов обновления, которые позволят вам перейти на последнюю версию Zmanda.  

Текущая версияПуть обновления
4.1.2.84.1.2.8 -> 4.1.3.10
3.63.6 -> 4.1.3.10
Свежая установка4.1.3.10

Обновление ZMC и Backup Server с 4.1.2.8 до 4.1.3.10 

1. Удалите 4.1.2.8 Резервное копирование двоичных файлов сервера и ZMC в системах на основе RPM и Debian с помощью приведенных ниже команд.

RPM Based :  #yum remove zmanda-platform-shared 

Debian Based : #apt remove zmanda-platform-shared

2. Только если вы являетесь пользователем Debian, вам нужно выполнить следующие команды, прежде чем переходить к шагам 3 и 4,

#mkdir /var/lib/amanda/ae_service

#cp /var/lib/amanda/backup/db.sqlite3 /var/lib/amanda/ae_service/db.sqlite3

 3. Затем скопируйте 4.1.3.10 ZMC и двоичные файлы сервера резервного копирования на соответствующие серверы и предоставьте права на выполнение.

#chmod +x zmanda-zmc-4.1.3.10-x64.run

#chmod +x zmanda-backup-server-4.1.3.10-x64.run

4. После копирования установите ZMC 4.1.3.10 и двоичные файлы сервера резервного копирования, запустив их с правами суперпользователя. 

#./zmanda-zmc-4.1.3.10-x64.run

#./zmanda-backup-server-4.1.3.10-x64.run 

Пожалуйста, обратите внимание:  

  1. Обязательно выполните шаг 2, чтобы выполнить обновление в системах на основе Debian.
  2. Для систем на базе rpm шаг 2 не требуется.  
  3. Необходимо обновить как Backup Server, так и ZMC. 

Миграция с 3.6 на 4.1.3.10 

Выполните указанные ниже шаги для перехода с Amanda Enterprise 3.6 на 4.1.3.10.

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

1. Важные примечания

Вот некоторые из важных вещей, которые следует учитывать перед обновлением:

  • Значение поля «Ленточное устройство» на странице «Резервное копирование» набора резервных копий, связанного с ленточным устройством, не будет перенесено. Не забудьте обновить его вручную после миграции. 
  • Если какие-либо файлы конфигурации в /etc/zmanda/zmc/zmc_ags/device_profiles/ или /etc/amanda были изменены вручную или были изменены расширения любого файла в этих каталогах, то их миграция может быть неудачной. Пожалуйста, проверьте после переноса. 
  • Zmc_migrate script следует запускать только после обновления до 4.1.3.10. Пожалуйста, следуйте инструкциям в разделе «Миграцияраздел внимательно.

2. Удалите 3.6

Перед удалением 3.6,

  • Обновите значение автоматической метки до «только пустой или ошибка ввода/вывода» на странице «Место резервного копирования». [Только для наборов резервных копий, связанных с лентами]
  • Удалите Zmanda 3.6 с помощью /opt/zmanda/amanda/uninstall, сохранив все файлы конфигурации.
  • (Необязательно) Если вы используете машины Debian/Ubuntu, удалите Zmanda-предприятие-резервный-сервер package, выполнив следующую команду, чтобы миграция прошла гладко. Если нет, пропустите этот шаг. 
    #apt удалить amanda-enterprise-backup-server 

3. Шаги перед миграцией  

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

  • Скопируйте каталоги набора резервных копий из / и т.д. / Аманда и YAML-файлы устройств от / и т.д. / zmanda / zmc / zmc_ags / device_profiles в любой каталог по вашему выбору. 
  • Скопируйте файл .am_passphrase из /var/lib/amanda, чтобы сохранить ключ шифрования сервера.
  • Если миграция уже была предпринята и не удалась, удалите все перенесенные конфигурации из консоли Zmanda [Не требуется, если выполняется в первый раз].    
  • Затем выполните следующие команды:  
  1. Перейти в каталог / и т.д. / Аманда:
ls [config backup dir]|xargs rm -rf; cp -R [config backup dir]/*/ ./; chown -R amandabackup *; chgrp -R amandabackup *

2. Перейдите в каталог / и т.д. / zmanda / zmc / zmc_ags / device_profiles:  

rm -rf *.yml; cp [config backup dir]/*.yml ./; chown amandabackup *.yml; chgrp amandabackup *.yml

[config backup dir] – path of the directory where the backup set directories and device yaml files have been backed up to.  
  • Запустите следующий cmd [необязательный шаг]: 
    кошка zmc_migrate_fix>/usr/sbin/zmc_migrate 
  • Чтобы перенести устройства AWS с установленным классом хранения ONEZONE_IA или STANDARD_IA, внесите следующие изменения, чтобы перенести такие устройства и связанные наборы резервных копий: 
  1. Перейдите в — /etc/zmanda/zmc/zmc_ags/device_profiles 
  2. Откройте файл yml, соответствующий соответствующему устройству AWS. 
  3. Обновить значение поля S3_STORAGE_CLASS в STANDARD or REDUCED_REDUNDANCY. 

4. миграция    

Все указанные ниже операции должны выполняться от имени пользователя root. 

1. Установите двоичные файлы 4.1.3.10 как для сервера AE, так и для ZMC UI, следуя Руководство по установке  

[Примечание: Mt-st необходимо установить перед установкой двоичных файлов сервера, чтобы использовать хранилище на лентах. Если mt-st будет установлен позже, обязательно запустите утилиту «setup-aee» от имени пользователя root] 

  • Скопируйте 4.1.3.10 ZMC и двоичные файлы сервера резервного копирования и предоставьте права на выполнение. 
#chmod +x zmanda-zmc-4.1.3.10-x64.run

#chmod +x zmanda-backup-server-4.1.3.10-x64.run

Установите двоичные файлы ZMC и Backup Server соответственно с разрешениями суперпользователя.

#./zmanda-zmc-4.1.3.10-x64.run

#./zmanda-backup-server-4.1.3.10-x64.run 

2. Войдите в консоль Zmanda, загрузите лицензию и добавьте в кластер IP машины, на которой установлены бинарники сервера.  

[Обратите внимание, что скрипт миграции не будет работать, пока не будет загружен файл лицензии]  

[Внимание: лицензия должна соответствовать функциям, поддерживаемым лицензиями 3.6]  

3. Запустите команду – 

  • zmc_migrate  
  • Входные данные [вводить в таком порядке]: 

→ Имя пользователя уровня администратора 

→ Пароль для пользователя 

→ IP машины, на которой присутствует консоль Zmanda 

→ Порт этой машины 

→ Идентификатор кластера, соответствующий серверу, на котором выполняется сценарий миграции. 

5. Ожидаемое поведение 

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

  • Мигрированное хранилище: AWS S3, библиотека смены лент, V-Tapes, Disk/SAN/NAS [Миграция для любого другого типа хранилища не поддерживается]. Устройство хранения будет перенесено, только если оно связано хотя бы с одним набором резервных копий. 
  • Перенесенные наборы резервных копий. Любой набор резервных копий, связанный с устройством хранения, должен быть перенесен. Если он не связан с каким-либо устройством хранения, он будет пропущен. 
  • Перенесенные источники: будут перенесены источники всех типов. Если одинаковый источник был создан для нескольких наборов резервных копий, то в 4.1 будет создан только один экземпляр такого источника, который будет связан с каждым из наборов резервных копий, с которыми он был связан в 3.6. Объединение тел запросов возможно для всех типов источников, кроме типов источников 14, 15, 17 и 10, поскольку эти типы источников не поддерживают связывание нескольких наборов резервных копий в версии 4.1. 
  • Сценарий миграции может быть перенесен на любую консоль пользовательского интерфейса при условии, что компьютер, на котором выполняется миграция, зарегистрирован в разделе «Кластер» консоли пользовательского интерфейса.  
  • Сценарий миграции не будет переносить конфигурации хранилища, промежуточного хранения и расписания любого набора резервных копий. 
  • Сделайте резервную копию, где и как будут перенесены конфигурации, за исключением нескольких полей, для которых должны быть назначены значения ZMC 4.1 по умолчанию. 
  • Данные в промежуточной области и данные хранилища будут недоступны после переноса.
  • После завершения миграции данные, сохраненные в консолях 3.6, можно восстановить с консолей 4.1 при условии, что конфигурации DLE, резервная копия которых была сохранена, не были изменены. 

6. После миграции         

Для успешного завершения миграции необходимы следующие операции/редактирования: 

  • Страница «Перейти к резервному носителю» набора резервных копий, который привязан к ленточное хранилище и нажмите на Слоты сканирования для синхронизации сведений о слоте (Применимо в случае использования ленточных накопителей)
  • Hyper V: «Открыть заново» и выберите вариант, который был выбран ранее. 
  • CIFS: Добавьте правильное значение в поле «Сетевой домен» и введите правильное имя пользователя и пароль. 
  • NDMP: добавьте правильного поставщика и пароль. 
  • VMware: «Повторно открыть» и выбрать вариант, который был выбран ранее. 
  • MS Exchange: «Повторно открыть» и выбрать вариант, который был выбран ранее. 
  • MS SQL Server: «Повторно открыть» и выбрать вариант, который был выбран ранее. 

7. Сообщить об ошибке         

В случае сбоя миграции укажите временную метку, которая печатается прямо над частью, где вам предлагается ввести «имя пользователя», или ту, которая печатается в конце миграции. 

8. Восстановление зашифрованной резервной копии на стороне клиента         

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

Свежая установка — 4.1.3.10 [ZMC и Backupserver]

Пожалуйста, обратитесь  инструкция по установке подробные инструкции по установке 4.1.3.10. 

Подводя итог

Готовы к тестированию? Обновите нашу новую и мощную версию Zmanda 4.1.3. Для получения дополнительной помощи создайте заявку в службу поддержки на своем Сеть Zmanda портал или напишите в наш отдел продаж по адресу sales@zmanda.com. Наши службы поддержки ориентированы на то, чтобы помочь вам максимально эффективно использовать Zmanda.

Дополнительные сведения о новых функциях и улучшениях в этом выпуске см. Примечания к выпуску Zmanda 4.1.3.

Вы еще не являетесь клиентом Zmanda? Запросить демонстрация и приступить к работе. 


Исследуйте другие темы