QNAPコミュニティの皆さん、こんにちは！NASのマイグレーションについて、経験豊富な方にご意見を伺いたいです。公式サポートページやフォーラムも一通り調べましたが、いくつか不明な点が残っています。
まず、詳細です：
NAS #1（ソース）：TS-1685
- QTS 5.2.8.3332
- Xeon D-1531 CPU + 32GB DDR4 RAM
- 12x12TB Seagate Exos HDDをRAID6グループ1つ＞ストレージプール1つ＞シンボリューム1つで構成。使用量は約107TB。
- QTSは必要最低限まで削減済み、基本的に高性能なSMB共有のみ。
- 余計なアプリやサービス、仮想化等は一切なし。標準QNAPアプリ、DA Drive Analyzer、SMB共有、UPSマスターのみ。
- シンプルなDHCP割当のネットワーク設定、SFP+リンク1本で接続。
NAS #2（デスティネーション）：TS-1635AX
- QTS 5.2.8.3332
- Marvell Armada 88F8040 ARMv8 CPU + 8GB DDR4 RAM
- 現在ディスクなし
非互換？：
- 公式のマイグレーション互換性ページによると、これら2モデル間での直接マイグレーションはサポートされていません。なぜでしょうか？ページ上の注釈問題は私のケースには該当しません。ハードウェアの違いがあるのは理解していますが、それはOSがハードウェア環境の変化を認識して自動的に調整（ドライバやデバイスラベル等）するだけの話ではないのでしょうか？*nixやWindowsのブートドライブを全く異なるPC間で移動したことが何度もありますが、多少の調整が必要な場合もあったものの、動かなかったことは記憶にありません。
- 私の推測では、互換性ガイドは過度に慎重になっているだけで、実際には致命的な非互換はないのではと思っています。実際に両方の機器をシャットダウンし、HDDを新しい筐体に移して起動した場合、何が起こるのでしょうか？事実としてご存知の方はいらっしゃいますか？
もし本当に直接マイグレーションが非対応の場合：
- 複数の公式サポートページによると、新しいNAS上の新しいストレージプールに手動でデータをコピーする必要があるとのことです。しかし、予備のドライブに$4000もかけられませんし、RAID構築と107TBのコピーに1～2週間もかける余裕もありません。
- ソースNASでプールを安全に取り外し/エクスポートし、（事前に設定・稼働中の）デスティネーションNASにドライブを装着して「ストレージプールのアタッチとリカバリー」を実行する手順ではダメなのでしょうか？
- これも互換性ガイドと同様、QNAPサポートが未経験者を守るために慎重なアドバイスをしているだけではないかと疑っています。
OneCD
2
推測ですが、原因は互換性のないバイナリによるものです。x86-64からaarch64に移行しています。ARM CPU上ではx86バイナリは実行できません。
NA9D
3
なぜ移行されるのかお聞きしてもよろしいでしょうか？
かなり高性能でメモリも豊富なX86から、はるかに性能が低く（実際には約10倍遅い）ほとんどメモリのないARMに移行されるのですね。
もしよろしければ、あなたのTS-1685を引き取りますよ… 
確かに、それは回復性を目的に設計されたOSだけが克服できる障壁かもしれませんね。ただし、実際のストレージプール構造やデータには影響しないはずですよね？（つまり、NAS 1から切り離して、事前に構成されたNAS 2でデータを復元できなくなることはない、という意味で）
公平な質問ですね！インフラの入れ替えをしていて、1685を再利用したいのですが、このストレージプールには引き続きアクセスできるようにしたいんです。
中古のTS-831XとTS-853 Proが2台あるので、もし興味があれば処分しようと思っています 
NA9D
6
いいですね。1685を引き続き使っているのを見て嬉しいです！そして、単なるファイルストレージ用途なら1635で十分でしょう。
ストレージプールのアタッチやデタッチについて（上記のもう一つのご質問）ですが、コアタイプによって違いが出る理由は私には分かりません。同じであるはずだと思います。もっと詳しい方にお任せします！QNAPにチケットを開くのも賢明かもしれません。
それから、手放す予定の他の2台のNASについては…遠慮しておきます。
OneCD
7
これら2つのNASモデル間でストレージプールだけを移行することには特に問題は見当たりません。
問題は、ドライブをモデル間で移動すると、OSも一緒に移動することです。OSはドライブ上のパーティションやアレイに、ユーザーデータとは別に保存されています。つまり、移動しているのは単なるデータファイルだけではありません。
NA9D
8
それは良い指摘ですね。OSは使用しているコアに特有のものです…
お客様のご要望と状況を社内チームに共有し、どのようにサポートできるか確認いたします。
その間に、現在の構成をより正確に把握するため、Storage Manager（ストレージマネージャー）のスクリーンショットをご提供いただけますでしょうか。よろしくお願いいたします。
ありがとう、皆さん。
QTSがOSデータのコピーをディスク間で保存しているのは知っていますが、長年QNAPを使ってきたにもかかわらず、その追加データの実際の保存場所や内容、仕組みについては、いまだに少し謎です。そして、今回最も重要なのは、NAS #2のQTSインストールがNAS #1からのその追加データにどのように反応するかという点です。すでに稼働中のOS上でプールをアタッチ／リカバリーすることになるので、古い追加データは単に破棄されて、自分自身のデータに置き換えられることを期待しています 
スクリーンショットを添付します！
※以前はM.2とSATA SSDでリードオンリーキャッシュアクセラレーションとウルトラハイスピードQtierを構成していましたが、今回の移行に備えて両方の機能を無効にしました。
TS-1685の4つの無料SSDドライブを使ってテストを行いました：
これらを使って新しいRAID6ストレージプール＋シンボリュームを作成し、いくつかのファイルをロードしました。その後、ストレージマネージャーで「プールの安全な取り外し」を使用したところ、問題なく動作しました。ドライブをTS-1635AXに挿入し、「ストレージプールの接続と復元」を使用したところ、これも問題なく動作しました。テストプールを復元した後に1635を再起動しても問題ありませんでした—1685のOSで起動しようとはしませんでした。
この方法で100TBのHDDプールを移行しても大丈夫そうです。
情報提供ありがとうございます！ご説明いただいたシナリオをもとに確認し、調査いたします。
NA9D
13
Qtier（キューティア）については他の方のコメントを待ちますが、一般的にQNAP（キューナップ）システムではキャッシュアクセラレーションはほとんどの場合役に立たず、実際にはパフォーマンスを低下させることもあるというのが広く知られています。大量の小さなファイルを読み込む場合を除き、キャッシュがいっぱいになると、キャッシュ内外のデータ移動がうまくいかなくなり、その時点で最も遅いドライブの速度に左右されてしまうため、ほとんど意味がありません。
nas2nas
14
良い知らせです。すべてうまくいき、ストレージプール全体の復旧と1635での共有ができました。1685を別のストレージプール／ボリュームにシステムドライブとして戻すのに少し手間がかかりましたが、それでHDDプールを切り離せるようになり、そこからは順調でした。
@NA9D キャッシュアクセラレーションについて教えてくれてありがとう。いくつかテストしてみます。Qtier（キュータイア）は私の環境では常にうまく機能していました。約4TBのウルトラティアがあり、非常に大きな（100GB超）ファイルの長時間転送を一貫して高速（400～600MB/s）で行えました。
今回1635の新しい構成では、書き込み専用の小さなキャッシュを試しています。4基の128GB SSDをRAID10で組み、オーバープロビジョニング後の実容量は185GBです。これまでの簡単なテストでは、300～500MB/sのバーストが飽和点まで出て、その後は通常のキャッシュなし速度（180MB/s）に戻ります。追加の処理負荷があっても同様です。
