DataDobi Certified Professional 5 v2: Notes

on

A place to put some notes on DataDobi certification (otherwise I'll forget everything - alas, my memory isn't super!)

Note: Only DataDobi certified Professional Services resources can deliver migration projects using the DataDobi migration tool.

Email support to get a login:

training@datadobi.com

Training link:

https://training.datadobi.com/login/index.php

Support:

https://support.datadobi.com/s

Certified Professional 5 v2 Course covers:

  • DobiMigrate Introduction
    • DobiMigrate Concepts
    • Prerequisites
  • DobiMigrate Installation
    • DobiMigrate Core Installation
    • DobiMigrate Proxy Installation
    • License Capacity
  • DobiMigrate Configuration
    • Add Edit Remove Users
    • Email Home
    • Global Settings
  • Configure Storage Environment
    • Add/Edit File Servers
    • File Server Threads and Proxy Bandwidth
  • Set up Migrations
    • UID-GID-SID Mapping Video
    • Add/Edit/Monitor Migration Path
    • Multiprotocol Migrations
    • Bulk Import
    • Migration Options Part 1
    • Migration Options Part 2
    • Selective error retry
  • Switchover
    • Shares and Exports
    • Dry runs and Switchovers Part 1
    • Dry runs and Switchovers Part 2
  • Maintenance
    • Upgrade DobiMigrate
    • Collect Log Files

Notes
  • DobiMigrate Introduction
    • DobiMigrate Concepts
      • 2 major components: DobiMigrate core and proxies
        • Proxy: Update metadata for files, copy files from source to target, scan a source file server...
        • Core: Calculate which data needs to be migrated, manage the workflow, gather scan results...
      • Migration Flow:
        • First scan > First Copy > Steady State > Dry run or Switchover > Finished
    • Prerequisites
      • Core: 4CPU, 16GB RAM, 1 or 10 GbE, 1GB disk space per million files/objects
      • Proxy: 4CPU, 8GB RAM, 1 or 10 GbE, 16+GB disk space
      • Red Hat rpm install does not come with pre-allocated disk space
      • Deploy proxies as close as possible to the target
      • Email Home needs an SMTP host with capability to send external emails
  • DobiMigrate Installation
    • DobiMigrate Core Installation
      • Run nmtui to set static IP
      • Timestamps are used to compare data between source and target file servers
      • Correct time zone and timestamps help correlating logfiles
      • Advise to not change time zone unless a specific need
    • DobiMigrate Proxy Installation
      • Editing the proxy config is mandatory
        • The core IP or device DNS name needs to be added to this file
    • License Capacity
      • DobiMigrate does not check if data is part of a redundancy strategy.
      • DobiMigrate will give a warning message when 80% of license is utilized.
      • The source scan results determine how much of the license capacity is consumed.
      • If we remove and re-add a file server, it will be considered to be a different file server.
      • If we remove and re-add a migration path, it will not consume additional license capacity if the added path is exactly the same as the removed path.
      • New Scan Result > Previous Scan Result = new result will replace the previous value and available license capacity is updated.
      • Insufficient license capacity = Migrations will stop until a new license key is uploaded
  • DobiMigrate Configuration
    • Add Edit Remove Users
      • DobiMigrate core default Administrator user, is required to configure the migration environment, and to create the needed Experts and Users
      • User - can monitor existing migrations and pause and resume them
      • Expert - can do everything a user can do, and also create and remove migrations
      • Admin - can do everything an expert can do, and also control the DobiMigrate setup and configuration
      • Export and Admin - can execute dry runs and switchovers
    • Email Home
      • Email home sends out different status reports to a set of email-addresses, on a chosen regular basis.
      • The detailed migration report provides a detailed activity overview for each configured migration path.
    • Global Settings
      • Lockout Threshold defines the number of unsucessful login attempts a DobiMigrate user gets before being locked out.
      • Discovery Schedule defines at which moment DobiMigrate will query the file server to discover any new changes in the configuration of these file servers.
      • Iteration Schedule defines the moment steady state migrations will start their next iteration.
      • Digest Algorithm is used for the verification of the copied data and to calculate the checksum mentioned in the 'Chain of custody' report.
  • Configure Storage Environment
    • Add/Edit File Servers
      • Validate Configuration: The file server configuration is checked for settings that will impact the migration.
      • SMB credentials: Local users or domain users
      • SMB credentials: Local Administrator and Backup Operators groups
      • Automatic mapping for an SMB share: DobiMigrate will automatically create a new migration share with a new, unique name and will provide full access to the previously entered SMB user.
      • (API) Integrated wizard allows the following share and export mapping types: Automatic, Manual, None
      • Automatic mapping for an NFS export: DobiMigrate will update the existing export or create a new one if needed, and will add the proxy IP addresses to the export root and R/W lists to allow full access.
      • Test connection: A check is done to see if the selected proxies can successfully connect to the configured NFS and SMB addresses.
    • File Server Threads and Proxy Bandwidth
      • Thread Configuration
        • Drawing time blocks to apply business/non-business hours.
        • Drawing time blocks to apply certain proxy bandwidth values during the day.
        • File server  thread count too high - can have a negative impact on the migration as the file server can be stressed too much.
        • File server thread config - defines how many concurrent scans and concurrent operations will be able to be run.
        • Proxy Bandwidth Limitation - allows us to define per proxy how much network bandwidth can be used during certain periods of the day.
        • No upper Proxy bandwidth limitation if it is not set.
        • Bandwidth limitation only applies to the actual copy of data.
        • To completely stop migration activity, put file server's scan and operations threads to zero as well.
        • Scans are server specific:
          • Source file server 40 scan threads, target 80 threads = 40 scan threads will run on the source file server, and 80 will run on the target.
        • The number of operations on the source file server will define how much operations will be used for migrations from this file server.
  • Set up Migrations
    • UID-GID-SID Mapping Video
      • SID mapping allows us to map source SIDs to corresponding targets SIDs for a data migration using the SMB protocol:
        • Map a SID on the source to a SID in a different domain on the target
        • Map an obsolete SID to an active SID on the target
        • Revoke an invalid SID
      • 5 types of SID mappings:
        • Map original SID to new SID
        • Map original SID to domain user
        • Map original SID to local user
        • Map original username to new username
        • Map a SID or username to 'REVOKED' (at the target, any ACE with this SID will be removed)
      • UID-GID Mapping allows us to map source users or groups to corresponding target users or groups for a data migration using the NFS protocol
        • Useful where you have local users or groups from a source that need to be mapped to local users or groups on the target
      • 3 types of UID-GID mapping:
        • Map owner or group name to new owner or group name
        • Map owner or group ID to new owner or group name
        • Map owner or group ID to new owner or group ID
      • UID-GID Mapping notes:
        • UID and GID number and name mapping is available for 7-Mode, CDOT and Isilon.
        • VNX and Unity only support UID and GID number mapping
        • It is also possible to map NFSv4 names
      • How to use SID-UID-GID Mapping File
        • This is an excel or CSV file
        • Can be uploaded for new or running migration via Options button
        • To see details: Configuration > User Mapping > Select File > Details
    • Add/Edit/Monitor Migration Path
      • Add a new migration: Migration Dashboard > New Migration Button > 
        • Migration setup wizard:
          • Select Source Server & choose path we want to migrate
          • Select Target Server & path
          • Review (including protocol to be used)
          • Migration options can be changed after setup
          • Precheck results: Click Finish
            • Purpose of these checks is to verify the migration environment is correctly configured for the migration to run.
      • Actions we can perform for path once migration is running:
        • Pause or resume migration path
        • Manually start a new iteration
        • Change migration options
        • Change migration protocol
        • Remove migration path
      • Pausing:
        • Can leave a path paused, or start a new iteration.
        • Resume before 7 days, the migration will resume the scan and continue where it left off.
        • To resume a path that has been paused for more than 7 days, a confirmation is required.
        • A path paused for more than 14 days is not possible to resume.
      • The option to change the migration protocol is only available if a migration using the new protocol would be possible for the selected migration path and this starts a new iteration.
      • Remove migration
        • NB: This will not remove or clean any migrated data on the target location. Only removes migration path in DobiMigrate.
        • NB: Switchover is the proper way to end a migration.
      • The purpose of the Planning tile is to get an overview of all the paths on our source file server, and to see the paths that have been migrated/are being migrated/have not been migrated yet.
    • Multiprotocol (MUP) Migrations
      • A dataset is multiprotocol when:
        • That data has both an SMB share and an NFS export
        • Files in the set are accessed by both Windows and Linux clients
      • To enable MUP in DobiMigrate, a license extension is needed.
      • Multiprotocol implementations:
        • Example: Synthetic permissions might depend on the account that requests the permission (through user mapping), so might not reflect the correct permissions after the migration. In this case, DataDobi advise not to use MUP migrations.
        • NB: Due to vendor specific MUP implementations, migrations between different storage platforms can lead to unexpected results on the target.
      • How is MUP handled in DobiMigrate:
        • 1. Scan the data via both SMB and NFS protocols
        • 2. Data copy to target using NFS protocol
        • 3. Both protocol's security information applied to target files as SMB and NFS metadata copy operations.
        • Note: When using Migrate files and directories using NFS, SMB security descriptors and alternate data streams will not be copied.
      • Protocol - NFS, SMB or:
        • If "Multiprotocol" option is not listed, check if multiprotocol is added to your DobiMigrate license key.
        • SMB + symlinks over NFS: DobiMigrate copies files and directories only over SMB. For symbolic links, NFS is used to create them and then SMB metadata is applied.
        • Protocol: NetApp 7-M Mixed -> Isilon: DobiMigrate will choose the most appropriate copy protocol.
      • Common issues:
        • The SMB protocol does not support files with unsupported characters, or files having the same name but a different case.
          • The way files are translated will vary depending on the systems involved, but generally a ~ along with a number are added to the filename, and underscores will replaced unsupported characters.
      • Advanced MUP options:
        • Invalid SMB filenames:
          • Generate errors: DobiMigrate will report the errors, but takes no corrective actions. The file is not migrated.
          • Migrate files using NFS only, generate error for directories: DobiMigrate will report error for directories, and will fail back to an NFS only copy for files. SMB security descriptors and alternate data streams will not be copied.
          • Migrate files and directories using NFS only: DobiMigrate will fail back to an NFS only copy for files and directories and the complete subtrees below them. SMB security descriptors and alternate data streams will not be copied. **CAUTION**
        • Symbolic links:
          • Normal symbolic link handling
          • Create over NFS, apply metadata over NFS and SMB (for when we have file servers that don't support the creation of symbolic links over SMB but support symbolic links for all other operations)
          • Create and apply metadata over NFS
      • When does the chosen Invalid SMB filenames option kicks in?
        • During a dry run or switchover the chosen Invalid Filenames option kicks in, and DobiMigrate then handles the errors.
    • Bulk Import
      • The bulk import functionality provides a way to quickly add multiple migration paths in DobiMigrate for one or more source-target server pairs, using a common set of migration options:
        • The Full Import allows us to import migrations for multiple source-target server pairs. For each migration path, we need to define the source and target server in the import file. We also need to set the migration protocol to use per migration path.
        • The Paths Only import is an easy way to import multiple migration paths for one specific source-target server pair. We just have to enter the source and target paths in the import file. The files servers, and the migration protocol can be selected during the import.
      • Fields:
        • Full Import: Source File Server Name, Destination File Server Name, Migration Source Path, Migration Destination Path, Protocol, NFS version on Source and Destination
        • NB: NFS versions field is optional - NFSv3 will be used by default.
        • Paths Only Import: Migration Source Path, Migration Destination Path
      • Migration options:
        • The General options apply to all the imported paths.
        • The NFS and SMB options apply to the imported NFS and SMB paths respectively.
      • Correct steps to execute a bulk import in DobiMigrate?
        • Start a New Migration. Download, fill in and upload the import template. Set the migration Options. Start the migration.
    • Migration Options Part 1
      • 1. We can set up the migration options during the configuration of a newly created migration, by following the configuration wizard.
      • 2. We can also change these options in the running migrations.
      • NB: Not all options are available for running migrations (e.g. Workflow Type)
      • 3. The options can also be configured via: Configuration > Global Settings
      • NB: Global settings includes things like: Iteration Schedule, Minimum Age ...
      • NB: Any change done her will become the default value for these options on any migrations.
      • Migration options: General options: Iteration schedule = defines then migrations will run (default - the migrations will start an iteration at midnight)
      • NB: If a migration path is still running when its next iteration is scheduled, it will ignore the schedule at that point. It completes the current run before falling back to the schedule.
      • Migration options: General options: Minimum age = defines a minimum amount of time a file needs to be unmodified before it will be taken into account for the next iteration.
      • NB: Useful option to prevent constant changing files taking up value bandwidth. During a dry run or switchover, all data will be migrated regardless of the minimum age setting.
      • Migration options: General options: Root directory handling = Determines if and how security settings and direct children of the migration root directory are handled.
        • Don't copy security (root directory permissions are not copied to the target side, as in some cases it is not possible to: read source root directory permissions / apply permissions on target root directory)
        • Copy security (Default setting: Root permissions will be copied as-is)
        • Convert inherited security to explicit (security is copied as-is, but the inherited flag is stripped from each ACL. This is useful in situations where the the root folder of the migration on the source has an ACL containing ACE's that are inherited from a parent folder)
        • Consolidate root folder
          • NB: DobiMigrate has built-in detection mechanisms for consolidation when setting up migrations. Appropriate messages to apply consolidation will be shown where needed.
          • NB: When using the consolidate option, files in the source root folder will not be migrated. Only directories in the root folder are migrated.
          • Blocking errors shown when we have subfolders with the same name: Use:
        • Consolidate sub folders (Same functionality as Consolidate root folder. It allows to run the consolidation for the root folder and its direct subfolders - consolidate root level and root level + 1)
          • NB: The root security and files from the source root folder, and its sub folders will not be migrated.
      • Migration options: General options: Excluded path patterns = Define which files and folders are excluded from the migration. Filtered out files or folders will not be migrated at all.
      • Migration options: General options: Skipped file patterns = Define which files and folders are excluded during the first scan, first copy and steady state. Once you start a dry run or switchover, the skipped files will be migrated as well. 
      • NB: The correct syntax and examples can be found in the DobiMigrate online help.
      • Migration options: General options: Allowed operations = define operations that are allowed for a file on the destination:
        • All operations allowed (default)
          • Deletes and updates are allowed on the destination - it will be kept in sync with the source
          • Files and folders on the destination will also be deleted if they don't exist on the source
        • No deletes
          • Deletes on source are not synced to destination
        • No deletes or updates
          • Deletes on source are not synced to destination
          • Updates on source are not synced to destination
      • Migration options: General options: Preserve access times on source = Keeps track of the access timestamp of source files and will put the access time of a source file back to its original value once it has been migrated. Make sure that DobiMigrate has write access to the source to perform access time updates.
        • NB: A small performance impact might happen as an additional write operation per file is performed on the source.
    • Migration Options Part 2
      • Advanced General options: Chain of Custody = The CoC Contains the needed information to track a migrated item on the source to the target system.
        • It is used to verify that there is an exact copy of the source item on the target. This is done at switchover. The CoC information proves that the data on the target matches the data on the source when the migration is complete.
        • The CoC result file containing this information will be generated when a migration is switched over and will be stored in the drop-zone on the DobiMigrate core. One result file is generated per migration path.
        • Options: None / Migrated data / Full
        • Full: Calculates the CoC for every file in the target migration folder. Any pre-existing data in this folder will be validated by comparing it with the source.
          • NB: Can be expensive if there is a lot of pre-existing data on the target.
        • Migrated data: Calculates the CoC only for the files that are part of the current migration.
        • Chain of custody states:
          • In sync (S): The item is the same on source and destination.
          • Excluded (E): The item was migrated. Then an exclude filter was applied for migration. Item deleted on the destination due to this. If item = directory, only the directory itself will be listed as excluded. Files and subdirectories in this directory will not be separately listed as excluded in the CoC file.
          • Retained (R): No deletes option enabled. Item retained on the destination due to this.
          • Out of sync (O)*: A change on the source was not propagated to the destination.
          • Unknown (U)*
          • *See info field in DobiMigrate for more details. Intermediate state: subsequent iteration, dry run or switchover should bring the item back in sync.

      • Advanced General options: Source read-back verification = When enabling this option, each source file's integrity is checked an additional time after it has been migrated to the target.
        • This is very useful to ensure data integrity when the source system could potentially supply corrupted data. There will be a performance penalty when enabling this option, as the source data needs to be read an additional time.
      • Migration options: NFS options: Copy owner & Copy group & Copy permissions: Enabled by default. If we deselect any of these the target system will apply its default owner, group or permissions to the migrated data.
      • Migration options: General options: Copy access control list (ACL): This option can be used if you want to copy the POSIX ACL's from the source. If this option is checked, DobiMigrate translates it to an NFSv4 ACL on the target. For an NFSv4 migration, this option is also enabled by default.
      • Advanced NFS options: UID map & GID map:  This allows us to map source users and groups to target counterparts. The option is useful in cases where no automatic user and group mapping  exists between source and target.
        • NB: UID GID number and name mapping is available for NetApp 7mode, CDOT and Isilon. VNX and Unity only support UID and GID number mapping.
      • Migration options: SMB options: Copy owner and Copy Group owner are enabled by default. If we deselect any of these, the target system will apply its default owner and group owner to the migrated data. We have the option to override them as well with a custom value.
      • Migration options: SMB options: Copy discretionary access control list (DACL): DobiMigrate copies the SMB security to the target. Otherwise the target system will apply its own default SMB security.
      • Migration options: SMB options: Copy system access control list (SACL): DobiMigrate migrates the system ACLs. These contain entries related to data access attempts for auditing purposes.
      • Migration options: SMB options: SID map: Allows mapping source SIDs to their target counterparts. Useful in cases where no automatic user and group mapping exists between source and target, or when we have historical SIDs on the source side that we want to map to SIDs on the target.
      • Migration options: SMB options: SID Map: Clean invalid security descriptors: When migrating data, it is possible we copy over SIDs that are not known to the target server. Some servers cannot cope with this and will throw errors, or even block the migration. With the option enabled, DobiMigrate gathers the invalid SID responses from the target and removes them from the data during the migration. Useful to cleanup orphaned SIDs during the migration.
      • Migration options: SMB options: SID Map: Replace "Creator Owner" and "Creator Group" in effective ACEs: CO and CG are well-known SIDs which can be applied to data. Some file servers cannot handle these SIDs, leading to errors during the migration. By enabling this option, DobiMigrate will lookup the actual file owner and group, and replace the CO and CG SIDs with the actual values before migrating the data.
      • Advanced Multiprotocol options: Invalid SMB filenames and Symbolic links (see in MUP above)
    • Selective error retry
      • A selective error retry is a special migration iteration where we can retry a selected amount of migration items which had errors during the last iteration
        • We can retry a subset of errors seen during the previous iteration.
        • Quickly an implemented error fix, without having to run the whole migration path.
      • The scan details display the activity that happened for the migration during source and destination scan.
      • The Command details display the activity during the copy phase.
      • The Error details aggregate the errors from the Scan and Command Details and provide error categorization.
      • Migration Details > Start > Retry items with errors
        • NB: Limited to 5000 items. If we have a large amount of errors, the best way forward is to first test the error fix by retrying a small amount of errors, and if this succeeds, start a new normal iteration to retry everything.
  • Switchover
    • Shares and Exports
      • 2 places where shares and exports can be changed:
        • In the Shares and Exports tab
        • During switchover time
      • Shares and exports tiles:
        • 1. Number of issues
          • This value represents the number of shares or exports that are flagged as having issues that could impact the migration.
        • 2. A X/Y mathematical function
          • X is number of shares or exports that are resolved.
            • Resolved = The shares or exports are part of a migration on the source or have an existing share or export on the destination, and have no issues reported for them {OR} The shares or exports are Marked as resolved in the DobiMigrateGUI.
          • Y is total number of shares or exports found on the source. It is the sum of:
            • number of issues +
            • number of resolved shares or exports +
            • number of undecided shares or exports
        • 3. Number of Undecided
          • Value represents number of shares or exports for which no migration exists yet (it is not decided yet if they should be migrated or not.)
      • Tile colors:
        • Green: All found issues are resolved and no undecided shares or exports are found - no actions required.
        • Orange: Typically ... there are Undecided shares or exports found but no issues.
        • Red: Issues have been found!
      • Troubleshooting:
        • Modify source access is typically used during switchover time (e.g. set source to to read only)
        • Restore source access
        • Mark as Resolved typically used when the end user will change shares and exports on the file servers, and wants to show in the DobiMigrate UI that the share or export as been dealt with.
        • NB: Please note that  these buttons can also be used to resolve or unresolve "Undecided" shares or exports.
        • Fix: Can be handy to create a RO access for the end users on the target so they can check the target data ahead of the switchover, without being able to change it.
          • NB: The Fix button is a great way to automate the target share and export creation so they match the user permissions from the source.
      • Other buttons:
        • Export Exports to CSV file:
          • Can be handy if there are a lot of shares or exports that we want to change outside of DobiMigrate and we want to have a list of all the available shares and exports in DobiMigrate that are not yet fixed.
        • Rescan: If a share was changed manually, a rescan will update the share information in the DobiMigrate UI.
        • Show resolved settings: If actions were taken for certain shares or exports, like fixing them, or marking them as resolved, they will disappear from the UI. Only the shares and exports with issues will be visible.
    • Dry runs and Switchovers Part 1
      • A switchover is a step in the migration flow during which a final scan of the data is done, and any changes are copied one last time from source to target.
        • Source shares and exports can be put to read only to prevent changes to the source during switchover time.
        • Target shares and exports can be automatically configured by applying the source shares and exports settings on the target.
        • A switchover can only be done for migration paths that are in steady state.
        • Once the switchover is complete, no further steady state iterations will happen for the paths that were part of the switchover. They are now in a Finished state.
        • The Minimum Age setting will not be applied for the migration paths that are part of the switchover.
        • Any skipped files will be migrated during the switchover.
        • A switchover is a mandatory step to ensure that all the source data is copied over completely during the migration.
        • It is possible to set shares to read only on a source generic SMB file server in DobiMigrate.
        • It is possible to apply the source share settings on a target generic SMB file server in DobiMigrate.
        • It is not possible to set the exports to R/O on a source generic NFS file server in DobiMigrate*
        • It is not possible to apply the source export settings on a target generic NFS file server in DobiMigrate*
        • *The needed API calls are not present to do so.
      • A dry run is a simulation of a switchover. A scan and copy of the changes is done for the paths that are part of the dry run, but no shares or exports are altered.
        • Once the dry run is finished, the paths are moved back to steady state.
        • The main goal of a dry run is to know how long the final scan and copy of a given migration set will take, so the switchover can be planned accordingly.
        • A dry run can only be done for migration paths that are in steady state.
        • The Minimum Age setting is not applied for migration paths in the dry run.
        • Any skipped files will be migrated during the dry run.
      • A switchover group is a logical entity that contains all the needed information to perform the switchover, like: Planning details, migration paths that are part of the switchover, and dry run information.
        • Parallelism - which defines how many paths will be scheduled at the same time during the switchover event - can be left at the default (16)
        • If the migration paths we want to dry run are part of a switchover group, and if a dry run is scheduled under Upcoming Events, it will automatically start at the selected start time, run its course, and finish.
      • Any path that is part of the dry run will be scanned and any changes copied from source to target.
      • During a dry run / switchover, all migrations that are not part of the event are paused, until it is complete, so as to maximize the available resource for a dry run or switchover.
      • A switchover execution is more or less the same as a dry run. If the migration paths we want to switchover are port of a switchover group, the switchover will either automatically start once the start time is reached, or it can be manually started via Current event > Start selected event.
      • Current Switchover tiles: Summary > Candidates > Shortlist > Scheduled > Copy Completed > Share Settings > Export Settings
        • 1. To prevent the source data from being changed during the switchover, we can set the end users source shares and exports to read-only.
          • NB: Disconnecting the active (SMB) sessions will potentially result in application or user-side errors if there are still applications or users actively using the source.
        • 2. Move the migration paths from the Shortlist to Scheduled
        • 3. A final scan and copy will be executed and the completed paths will move to Copy Completed.
        • 4. Update the shares & exports on the target server (with Fix button)
          • NB: Updating the target shares and exports process can't be reverted via DobiMigrate, so make absolutely sure that the switchover is executed successfully and the target is verified before doing the updates.
        • 5. Acceptance testing can be done (outside of DobiMigrate) to verify that the users have access to all their shares and exports.
        • 6. Close the switchover window (Summary Tile > Close Event)
    • Dry runs and Switchovers Part 2
      • Reverting:
        • Restore source access button (CIFS and NFS tiles)
        • Summary Tile > Close Switchover Event > Move back to Steady State
        • Note: Reverting target shares and exports back to their original state needs to be done manually outside of DobiMigrate. This is why - during a switchover - we only update them once all paths in this switchover are successfully completed, and the needed verifications are done on the target server to confirm the switchover was successful.
      • Rollback a switchover:
        • When issues are found on the new target file server after the switchover is completed, we can roll back a migration.
        • A rollback in DobiMigrate means: copying any changes done to a migration path on the target file server after the switchover is completed, back to the original source file server.
          • Migration's finished tile, select path that needs to be rolled back > Rollback...
          • Clicking the Rollback button creates a reversed migration that will sync the path between the new target file server and the old original source file server.
          • Once the migration is in steady state, we can remove the migration path in DobiMigrate, as the target is synced back to the source at this point.
          • Finished migration actions: To steady state
      • Steps to cancel a switchover:
        • Put the source shares and export back to their original state. Put the migration paths that are part of the switchover back to steady state.
  • Maintenance
    • Upgrade DobiMigrate
      • Why important to upgrade?
        • Engineering team is very actively improving DobiMigrate, adding new functionalities, fixing issues, and so on.
        • New software versions containing improvements are released frequently.
        • Upgrading DobiMigrate regularly is a good practice to make sure your migration is running smoothly.
        • Upgrade:
          • 1) Download Latest DobiMiner Upgrade
          • 2) Configuration Module > System tab > Update DobiMigrate Software > Upload... > Update Now (upgrades core and proxies)
          • Note: The core and proxies services will restart during the upgrade, so the UI will be unavailable for a short period of time.
          • 3) Click on log in top left > Version (check upgraded successfully)
        • Important remarks:
          • Upgrading doe snot impact your running migrations. They will automatically resume once the upgrade is complete.
          • No special precautions or preparations are needed to execute an upgrade. It is a non-intrusive action which is safe to do.
          • An upgrade typically only takes a couple of minutes to complete.
          • The proxy statistics on the Proxies Dashboard will reset, as the upgrade operation will restart the proxies.
    • Collect Log Files
      • Importance of log files:
        • During a migration, many components work together to copy the data from source to target. When an issue occurs, it is important that the Datadobi engineers can identify what is wrong as quickly as possible.
        • Log files can be a big help in identifying the issue and providing a solution.
      • Collecting log files:
        • Main Dashboard page > Tools > Logging
        • Note: When no specific components are set, the output of the default log levels will be displayed.
        • Note: Downloading log files to the dropzone is a good solution in case the files are very large.
      • Important to know:
        • The reported file size is the original, uncompressed size. The log files will be zipped when download, so the downloaded file will be a lot smaller.
        • Logs are typically needed for ongoing support investigations. Most of the time, the Datadobi support team will specify which log files are needed. Once downloaded, the logs can then be attached to a support ticket.
        • If certain log levels need to be set for specific components, Datadobi support will specify which values to set. Most of the time, in this case, the required log level will be Debug.
      • Example scenario:
        • We have an Isilon for which further investigation by Datadobi is needed
        • Datadobi asks to send the debug logs for the isilon.
        • See: DataDobi KB "How to enable DM debugging for Isilon mgmt API interactions"
          • 1. Go to the Tools tab
          • 2. Select Logging
          • 3. Type Isilon in the text field
          • 4. Set Debug for 'Isilon'
          • 5. Set Debug for 'IsilonSSH' (if present)
          • 6. Set Debug for 'IsilonConnectionFactory'
          • 7. Set Debug for 'IsilonFilerConnection'
        • Once finished reload the default logging settings.
        • Note: If we leave the Debug logging on, the log files would grow very big very quickly. Debug logging is not needed for day-to-day operations.
  • Certified Professional 5 v2 Exam:
    • Need 85 correct out of 100 to pass. 3 attempts allowed!

Comments

Post a Comment