[{"content":"前回の記事で、深夜の謎の過負荷（狂ったスリープcron）によりHDDが1台物理死亡した話を書きました。 ホットスペア（日立製HDD）が即座に身代わり出動してデータを死守してくれていましたが、ついに注文していた交換用の新品HDD（WD Red Plus）が到着！\n今回は、新品HDDの物理換装から、ZFSのリシルバリング（再構築）、そしてピンチヒッターのスペアが自動的に待機部屋へ戻っていく感動の「完全復元劇」をレポートします。\n📦 新品HDD「WD Red Plus」が着弾＆物理交換！ # Amazonでポチった信頼のNAS用HDD WD Red Plus（WD20EFPX / 2TB） が無事に我が家に届きました。\nさっそく我が家の要塞（HP ProLiant MicroServer Gen8）を開封し、死んだドライブを抜き取ります。 1スロット分がぽっかり空いた状態です。\n抜き取ったマウンタに新品のWD Redをネジ止めし、カチッとスロットへ装着！ 見事に4スロット全てが埋まりました。\nフロントドアを閉めて鍵をかけたら、ハードウェア側の準備は完了です！\n⚡ リシルバー開始！「あれ、スペア切り替えより早い…！？」 # 物理作業が終わったら、TrueNASのWeb UIへアクセス。 故障していた sdc の位置で Replace（交換） を実行し、今挿した新しいWD Redを選択します。\n画面上では REPLACING ステータスとなり、一時的に新しい sdc と身代わりスペア（sda）が並んでデータ再構築（リシルバー）が進んでいきます。\n実際にリシルバーが始まって画面を見ていると、ある異変に気づきました。\n「…気のせいかな？ スペアに切り替わるとき（約7時間半）よりも明らかに進みが早いぞ！？」\n調べてみると、これにはちゃんとした技術的理由がありました。\n💡 なぜリシルバーは爆速だったのか？ # スペア切り替え時（エラー検知）のオーバーヘッド\nディスクが壊れる時は、システムが「本当にこのHDD死んでる？」と何度も読み書きのリトライを繰り返したりタイムアウトを待ったりするため、全体的に動作が非常に重く遅くなります。 リシルバー（新品への書き込み）のフルパワーモード\n新品ディスクへの書き込み処理は、壊れたHDDのエラーを気にする必要がありません。他方の健全なドライブからデータを連続で読み出し、まっさらな新しいディスクへシーケンシャル（連続）書き込みを一気に行うため、ディスク本来のトップスピードが出るわけです！ 最初の見積もり時間（約4時間48分）からグングン残り時間が縮まり、システムがフルパワーでデータを書き込んでくれているのがわかりました。\n🍖 待ち時間の正しい過ごし方：庭でバーベキュー # HDDのリシルバー処理はいくら早いとはいえ、数時間はかかります。 ZFSの進行状況を画面前でずっと監視していても胃が痛くなるだけなので…\n庭で肉を焼きながらのんびり待つことにしましたｗ 🍖🔥\nホームラボを嗜むエンジニアにとって、最高の休日と作業の組み合わせです。\n🎉 復旧完了！完璧な「ONLINE」復帰 # 美味しいお肉を食べ終わって戻ってくると…画面が緑色に変わっていました！\nリシルバー完了（所要時間：4時間28分36秒、エラー 0）！！\nシステムの画面を確認すると、感動的な変化が起きていました。\n新しいWD Red Plusへのデータ復元がエラー0で完了 ピンチヒッターとして戦ってくれたスペア（sda）が、自動的に元の**「待機状態（1 x 1.82 TiB Spare VDEVs）」**へスマートに帰還！ ストレージの健康状態が美しい**オンライン, エラーなし。**に完全復帰！ 手動でコマンドをガチャガチャ叩く必要もなく、GUIからの操作1つでここまで美しく構成が元通りになるTrueNAS / ZFSの堅牢さには脱帽です。\n🔒 おまけ：復旧後のDBバックアップ運用を見直す # ストレージが綺麗に治ったついでに、バックアップ周りの運用（Google DriveへのCloud Sync）も見直しました。\n我が家では PostgreSQL（pgdata）を使うアプリ（Immich,Vaultwarden, Memos, n8nなど）が動いています。\nPostgreSQLのデータは稼働中の生データを直接クラウドに同期すると壊れるリスクがあるため、現在は 「夜間にアプリを一時停止 $\\rightarrow$ Cloud Sync で Google Drive へ安全同期 $\\rightarrow$ アプリ再開」 という構成でCronを組んでいます。\n停止中のファイルコピーなので整合性リスクは100%ゼロ。手間を増やさず、TrueNASのUIだけで完結する一番安全な構成で今後も運用していくことに決定しました！\n📝 まとめ # 今回の物理障害からの一連の復旧を通して、自作ホームラボに**「ホットスペアを1台仕込んでおく価値」**を痛感しました。\nホットスペア: 突然の物理死でも夜間に自動で一時防御・データ保護してくれる 交換とリシルバー: 新品HDDへの換装後は爆速で復元され、スペアは自動でニート（待機組）部屋へ戻る 精神的余裕: ディスクが死んでも肉を焼きながら安心して復旧を待てる！ 自作NASやHomeLabを運用している方は、ぜひホットスペアの導入をおすすめします！ 守りが固まった要塞で、これからも快適なNASライフを楽しんでいきます👍\n","date":"2026年7月20日","externalUrl":null,"permalink":"/posts/hdd-replacement/","section":"Posts","summary":"","title":"【TrueNAS SCALE】完全復活！物理死したHDDの新品交換とホットスペアの完璧な「帰還劇」","type":"posts"},{"content":"","date":"2026年7月20日","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"2026年7月20日","externalUrl":null,"permalink":"/tags/hdd/","section":"Tags","summary":"","title":"HDD","type":"tags"},{"content":"","date":"2026年7月20日","externalUrl":null,"permalink":"/","section":"hidelog","summary":"","title":"hidelog","type":"page"},{"content":"","date":"2026年7月20日","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"2026年7月20日","externalUrl":null,"permalink":"/tags/raidz1/","section":"Tags","summary":"","title":"RaidZ1","type":"tags"},{"content":"","date":"2026年7月20日","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"2026年7月20日","externalUrl":null,"permalink":"/categories/truenas/","section":"Categories","summary":"","title":"TrueNAS","type":"categories"},{"content":"","date":"2026年7月20日","externalUrl":null,"permalink":"/tags/truenas/","section":"Tags","summary":"","title":"TrueNAS","type":"tags"},{"content":"","date":"2026年7月20日","externalUrl":null,"permalink":"/tags/wd-red/","section":"Tags","summary":"","title":"WD Red","type":"tags"},{"content":"","date":"2026年7月20日","externalUrl":null,"permalink":"/tags/zfs/","section":"Tags","summary":"","title":"ZFS","type":"tags"},{"content":"","date":"2026年7月20日","externalUrl":null,"permalink":"/tags/%E3%83%AA%E3%82%B7%E3%83%AB%E3%83%90%E3%83%BC/","section":"Tags","summary":"","title":"リシルバー","type":"tags"},{"content":"","date":"2026年7月20日","externalUrl":null,"permalink":"/tags/%E6%95%85%E9%9A%9C%E5%AF%BE%E5%BF%9C/","section":"Tags","summary":"","title":"故障対応","type":"tags"},{"content":"おお、ついに我が家のホームラボ要塞で「恐れていた事態」であり、同時に「一番恐ろしくて美しい実戦テスト」が発生しました。\n結論から言うと、HDDが1台物理的に死亡しました。 しかし、事前に設定していたホットスペア（自動身代わりディスク）が完璧に機能し、データロス0で完全生存しました！\n今回は、深夜の謎の過負荷からHDDの完全沈没、整理されたタイムライン、そして新しいHDDを即座に密林でポチるまでのドタバタ劇を記録します。\n🕒 事件のタイムライン（それは深夜に始まった） # 1. 午前3時21分：強制スリープ命令 # 深夜、省電力のために全ディスクへ強制スリープコマンドが実行されました。 これが結果的に、寿命が近づいていたHDDにとって「運命の引き金」になります。\n2. 午前3時30分：悪魔のバッティングと瞬間過負荷 # ディスクたちが爆睡している真っ最中、TrueNASの定期ディスクチェックジョブ（smartctl）が突撃。 眠っていた5台のHDDが一斉にモーターを回転させて目を覚ます「一斉スピンアップ」が発生し、システム全体のI/O負荷と物理的な負荷が瞬間的に限界突破しました。 この時の大衝撃が、弱っていたディスク（sdc）へ致命傷を与えてしまいます。\n3. 午前10時35分：エラー限界突破、実戦開始！ # 目覚めてから数時間、じわじわとセクターエラーを吐き続けていた sdc がついに力尽き、ZFSによって FAULTED（完全隔離） に設定されました。\nしかしここからが我が家の要塞の真骨頂。 ディスクが死んだその1秒後、待機部屋でニートをしていたホットスペア（日立製HDD: P6K******）が自動で戦線に投入され、データの再構築（リシルバリング）がスタートしました。\n4. 午後18時13分：7時間半の激闘の末、リシルバリング成功！ # 約795GBのデータを、スペアディスクが1件のエラーも出すことなく完璧にコピー完了！ プールは一時的に DEGRADED（警告状態） ではあるものの、データは100%安全な状態に保護されました。\n🔍 修羅場のログ（ZFSのステータス） # システムが完全にディスクを切り離し、スペアで持ちこたえている当時の zpool status -x の生のログがこちらです。\nroot@truenas[~]# zpool status -x pool: tank state: DEGRADED status: One or more devices are faulted in response to persistent errors. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Replace the faulted device, or use \u0026#39;zpool clear\u0026#39; to mark the device repaired. scan: resilvered 795G in 07:38:55 with 0 errors on Sat Jul 18 18:13:09 2026 config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 raidz1-0 DEGRADED 0 0 0 spare-0 DEGRADED 0 0 0 ecdc1045-4206-4380-88de-980e1268c147 FAULTED 4 1 0 too many errors cf1d1d91-2cdc-4fe5-80bc-bc9a16339fbc ONLINE 0 0 0 9452449a-07fc-4ced-845c-ff9c8112f7a8 ONLINE 0 0 0 a0c3b51e-e8b4-421e-8a55-6736b5f213ea ONLINE 0 0 0 10e311c0-dfb1-4811-bba9-0a85912f7bb2 ONLINE 0 0 0 spares cf1d1d91-2cdc-4fe5-80bc-bc9a16339fbc INUSE currently in use errors: No known data errors 見事に元のディスクが FAULTED になり、下部にいたはずのスペアが INUSE（出動中） になっているのがわかります。\nまた、途中でTrueNASから Disk P6K****** is UNAVAIL（スペアが部屋にいないぞ！）というお騒がせアラートが飛んできてヒヤッとさせられましたが、これは「待機部屋から現役メンバー部屋に引っ越した」ことによるZFSの仕様（誤報）でした。焦らせやがって…！\n🛠️ 今回の教訓とこれからの対応 # 今回の件で、身をもって学んだ教訓が2つあります。\nHDDの強制スリープ（hdparm -y）のcronはやめる 夜中に一斉スピンアップする物理的負荷が寿命を縮める最大の原因になるため、即座にこの狂ったcron設定は廃止しました。TrueNAS標準の安全な省電力制御に任せます。 ホットスペアは「神」設定 もしスペアを仕込んでいなかったら、私が朝起きて、気づいて、慌てて対応するまでプールは生身の危険に晒されていました。先回りして防御してくれるホットスペアの有り難みが骨身に沁みました。 次のステップ：月曜日に決戦 # 事件発生後、ソッコーでAmazonにて新しい交換用のHDDをポチりました。月曜日には我が家に届く予定です！\n新しいディスクが届いたら、TrueNASの画面から Replace（交換） ボタンをポチッと押すだけ。 新ディスクへの同期が終われば、今がんばってプールを維持してくれているスペアディスク（P6K******）は、自動的に元のニート（待機組）部屋へ帰っていくシステムになっています。\nトラブルではありますが、自分で組んだサーバーの冗長システムが完璧に機能してデータを守りきってくれたのは、自作クラスタとしては脳汁が出るほど嬉しい経験でした。\n月曜日に新ディスクが届いたら、また交換編の記事を書こうと思います！\n","date":"2026年7月18日","externalUrl":null,"permalink":"/posts/homelab-truenas-hdd-fault/","section":"Posts","summary":"","title":"【TrueNAS SCALE】深夜の悲鳴！HDDが物理死したけどホットスペアが完璧に自動防御してくれた話","type":"posts"},{"content":"","date":"2026年7月13日","externalUrl":null,"permalink":"/tags/adguardhome/","section":"Tags","summary":"","title":"AdGuardHome","type":"tags"},{"content":"","date":"2026年7月13日","externalUrl":null,"permalink":"/tags/immich/","section":"Tags","summary":"","title":"Immich","type":"tags"},{"content":"","date":"2026年7月13日","externalUrl":null,"permalink":"/tags/n54l/","section":"Tags","summary":"","title":"N54L","type":"tags"},{"content":"","date":"2026年7月13日","externalUrl":null,"permalink":"/tags/self-hosted/","section":"Tags","summary":"","title":"Self-Hosted","type":"tags"},{"content":"我が家の宅内要塞（hidetti.net）のコア、HP ProLiant MicroServer N54L上で稼働するTrueNAS SCALE環境において、深夜4時から謎のCPU負荷上昇とAdGuard HomeへのDNSクエリ爆撃が発生した。\n結論から言うと、原因はImmichのMachine Learningコンテナが要求するCPU命令セット（AVX）の不整合による即死と、それに伴う名前解決の無限ループであった。非力なTurion II Neo CPU（2コア/16GB RAM枠）を労りつつ、システムに再び「深呼吸」をさせるための美しい撤退戦をここに残す。\n1. 発生した現象：AdGuardのログを埋め尽くす大量のクエリ # 今朝、システムモニターを確認すると、通常1〜2%で推移しているはずのN54LのCPU使用率（Load Average）のベースラインが一段跳ね上がっていた。 同時に、上流のDNSキャッシュサーバーであるAdGuard Homeのクエリログを確認したところ、以下のローカルドメインへの異常な超高速リトライクエリ（秒間数十回）が記録されていた。\nmachine-learning machine-learning.local 過去7日間の「最も問い合せされたドメイン」のトップに急浮上するほどの大出血状態であった。\n2. 原因：AVX命令セット非互換によるコンテナ即死 # TrueNAS SCALEの「Apps」画面からImmichのWorkloads（ワークロード）を確認したところ、インフラの歪みが露わになった。\nserver - 動作中 pgvecto - 動作中 machine-learning - Exited \u0026lt;-- これが原因！ redis - 動作中 permissions - Exited 根本原因のメカニズム # Turion II Neoの限界 (AVX未実装): Immichが近年採用している機械学習ライブラリ（ONNX Runtime / PyTorch等）は、CPUの拡張命令セットである AVX / AVX2 を要求する。しかし、名機N54Lにはこれが物理的に実装されていない。そのため、コンテナ内のプロセスがログ（stdout）を吐き出す前の超初期段階で Illegal instruction により即死（Exited）していた。 リトライループの発生: メインの server コンテナは、死んでいる machine-learning コンテナに対して「おい、応答してくれ！」と名前解決を試み続ける。これがコンテナ内部のネットワークを突き抜け、外部のAdGuard Homeまで漏れ出て無限リトライループ（DNS暴走）を構成していた。 3. 対策：Machine Learningの完全無効化 # メモリ16GB制限（ZFS ARCで8GBをガッチリ死守中）のN54L環境において、顔認識やオブジェクト検出のためにCPUを空振りで100%に張り付かせるのは、インフラ防衛上大きなリスクだ。 万が一、瞬低や停電が発生した際、オムロン BW55T（blazer_usb/ippon）のシャットダウンシーケンス（360秒タイマー）の確真な遂行を脅かしかねない。\nNASとしての「写真バックアップ」「アルバム閲覧」という本質機能を最優先し、ML機能を安全に切り離す英断を下した。\nTrueNAS SCALEでの最適化手順 # TrueNASの Apps ＞ Immich ＞ 編集（Edit） を開く。 Enable Machine Learning のチェックボックスを外す（オフにする）。 画面下部までスクロールし、保存（Save） をクリック。 【結果】 ワークロードから machine-learning の表記自体が消え去り、「インスタンス 5」のクリーンな布陣へ移行。AdGuard HomeへのDNSクエリはピタッと止まり、Tera Termから確認した htop のCPU負荷は平熱（1〜2%の静寂）へと戻った。\n4. AdGuard Home側でのダメ押し防御設定 # 万が一、今後のアップデート等でImmich serverが寝言のようにクエリを飛ばした場合に備え、AdGuard Home側で1ミリ秒でシャットアウトするカスタムフィルターを設定した。\nフィルター ＞ カスタムフィルタールール:\n||machine-learning^$dnsrewrite=NXDOMAIN;; ||machine-learning.local^$dnsrewrite=NXDOMAIN;; これにより、無駄な外部問い合わせを発生させず、即座に「ドメイン不在（NXDOMAIN）」を返してN54LのCPUサイクルを徹底的に保護する。\n5. 今後の展望：顔認識を取り戻すロードマップ # もし将来的にどうしても顔認識（ソート機能）を完全復活させたい場合、N54L単体に無理をさせず、以下のスマートなアプローチをとる予定だ。\nExternal Machine Learningの活用: Immichの設計を活かし、重いAI処理だけを別マシンのパワー（GPU搭載のデスクトップPC等）に丸投げする運用。 Hugging Face超軽量モデルの検証: Hugging Face Endpoint 設定を利用し、AVX命令を要求しない cpu-only の超軽量量子化モデル（MobileNetベース等）を週末にじっくり実験する。 限られた16GBのメモリとTurion CPUという制約の中で、システムをパニックに陥らせず安定稼働させる。これこそがセルフホストの醍醐味であり、シニアエンジニアの流儀である。\n","date":"2026年7月13日","externalUrl":null,"permalink":"/posts/n54l-homelab-immich/","section":"Posts","summary":"","title":"TrueNAS SCALEのImmichでDNSクエリ暴走とCPU負荷を解決する（N54L延命戦記）","type":"posts"},{"content":"","date":"2026年7月11日","externalUrl":null,"permalink":"/tags/ups/","section":"Tags","summary":"","title":"UPS","type":"tags"},{"content":" はじめに：夏だけど、頭の中は年中パウダー # 2012年生まれの可愛い相棒「HP ProLiant MicroServer N54L」。令和も中盤の2026年現在、あえてこのTurion II Neoという激渋プロセッサと、最大16GBという極限のメモリ制約を持つ名機をセルフホストの要塞として延命させる――。\nこれが、我がブログ『Carve, Powder, and Commit』の記念すべき最初のハックログ！\n今はすっかり緑に包まれた7月のテイネ山（手稲山）を眺めながら、「早く冬にならないかな…」とスノーボードの動画をディグる日々。スケートボードでのオフトレや愛車のメンテで汗だくになったあと、冷房をガンガンに効かせた部屋で冷たいコーラを片手にシェルを叩く。ZFSプールにコマンドをカチ撃ちする瞬間こそ、インフラ屋として最高に脳汁が出る時間だ。\n今回は、この愛すべき無骨なキューブ筐体を現代のセルフホスト環境で生き残らせるための、血と汗と（コーラの）涙のチューニング記録をお届けする。\n1. TrueNAS SCALE × ZFS：16GBメモリの極限サバイバル # ZFSという最強のファイルシステムは、デフォルト状態だと「あればあるだけメモリを食い尽くす」という超大食漢。しかし、我がN54Lの最大積載メモリは16GB。ここにモダンなTrueNAS SCALEを載せ、さらにMemosやHome Assistant、Immich（家族写真のバックアップ）などのコンテナ群を共存させるのは、まさにリソースの極限の「削り出し」だった。\nまずは、暴走しがちな ZFS ARC（キャッシュ）の制限設定 から着手。\nメモリ空間を「ARCに8GB」、「OSとコンテナ群に8GB」と脳内で美しく二分するパッチを適用。さらに、リソースをジワジワ食うリアルタイム監視ツール（netdata）などの余計なサービスを徹底的にシバいて停止させた。\n結果として、14年落ちのTurion CPUに一切のスパイク（負荷突入）を起こすことなく、安定の CPU負荷0% を維持する平穏なリソースプールが完成。大成功である。\n2. 夏のゲリラ豪雨と激しい落雷に勝つ：電源防衛戦略 # 冬の猛吹雪も怖いが、夏のテイネの麓だって油断できない。そう、「ゲリラ豪雨と激しい落雷」 である。バリバリと響く雷による瞬低（瞬間電圧低下）や突然の停電は、書き込み中のZFSプールにとって一撃必殺の致命傷になり得る。\n我が家は太陽光発電と家庭用蓄電池を完備しているけれど、電力切り替え時の数ミリ秒の瞬低を無効化する「ラストワンマイルの防衛線」が欲しい。\nそこで配備したのが、オムロン製UPS「BW55T」！\nTrueNAS SCALE上で blazer_usb ドライバ（および ippon サブドライバ）をマウントし、UPSとのシリアル通信のバイパスを確立。停電を検知したら360秒（6分）以内に安全にシステムをランディングさせる自動シャットダウン戦略を構築した。もちろん、Home Assistantへのステータス同期もバッチリ。\nここで、TrueNASが再起動したときにUSBのアクセス権限がリセットされてUPSを見失うという可愛いバグに直面。これに対しては、システム起動時の設定（Post Init Script）に以下のコマンドを登録して力技で解決！\nchmod 666 /dev/bus/usb/00*/* 2\u0026gt;/dev/null || true これで、外がどんな雷雨だろうとも、入力電圧101Vを1パケットの零れもなく維持する「電源の絶対安全圏」を確保。これで夏のお出かけ中も枕を高くして眠れる。\n3. Cloudflare Tunnel：黄金の盾で要塞化 # セルフホストしたMemosやImmichの家族写真を外部から安全に利用するため、自宅のグローバルIPを1ミリもインターネットの海に晒さない 「Cloudflare Tunnel」 のトポロジーを採用した。\n自宅ルーターのポート開放を完全にゼロにした上で、内部からトンネルを確立。さらにフロントにはCloudflare WAF（Web Application Firewall）という「黄金の盾」を配置し、海外IPからの邪悪なポートスキャンや攻撃パケットは、エッジサーバーの手前ですべて火花を散らして弾き飛ばされる。一方で、プライベートな管理画面へのアクセスはTailscale（VPN）を必須とし、バックヤードの防衛線も完璧に要塞化している。\n🛠️ 技術備忘録：N54L要塞化のコンフィグ（再現用） # 今後の再構築や再現性のために、今回の「テイネの麓仕様」のコアコンフィグをここにストックしておく。\n① ZFS ARCの8GB制限（sysfs設定） # メモリの半分をAppコンテナ空間として確実に確保するための設定値。\necho 8589112320 \u0026gt; /sys/module/zfs/parameters/zfs_arc_max ② NUT（Network UPS Tools）ドライバ設定 # オムロン BW55Tからipponプロトコル経由で、電圧・負荷・バッテリー残量を正確にトラッキングするための補助引数（Extra Arguments）。\nDriver: blazer_usb Subdriver: ippon 引数: subdriver=ippon, vendorid=0590, productid=005b 🛡️ 現在の要塞ステータス（ALL GREEN） # このログを打ち込んでいる現在も、我が要塞のインフラレイヤーは完璧な調和を保っている。\nCPU / RAM: 0.05 / 16GB（ARC 8GB制限によりコンテナ空間が深呼吸中） オムロン BW55T: 101V / 100%（常時追従・360秒自動落城タイマー起動） Network: ステルスモード（Cloudflare Tunnel + Tailscale要塞化） ZFS Pool: HEALTHY（深夜帯のスクラブ・バックアップ自動タスク化） 真夏に汗をかき、冬を夢見て、キーボードにコミットする。 テイネの麓に構えたこのN54L延命戦記は、まだまだ始まったばかりだ。\n","date":"2026年7月11日","externalUrl":null,"permalink":"/posts/n54l-homelab-fortress/","section":"Posts","summary":"","title":"テイネの麓からZFSプールへ：真夏のN54L 16GBメモリ極限延命戦記","type":"posts"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"}]