Bottom line: Treat the metadata VDEV as a pool-layout decision with a failure-tolerance and removal review. Do not approve the addition solely because a proposed device is fast or has spare capacity.
\nThe TrueNAS Fusion Pools guide says the special allocation class stores metadata, indirect blocks and deduplication tables, with optional small-file blocks. It warns that losing a special VDEV without redundancy corrupts the pool and prevents access to its data. The guide recommends special-VDEV failure tolerance equal to or greater than the data VDEVs’ tolerance. It says a whole metadata VDEV can be removed only when the data VDEVs are mirrors; with RAIDZ data VDEVs, that addition is permanent.
\nThis article addresses the versioned special-VDEV layout decision, not a device qualification or performance guarantee. Whole-VDEV removal is the scope of the permanence statement; this article does not prescribe a drive-replacement or member-detachment procedure.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE recommends a before-and-proposed pool diagram that labels data VDEVs and the special allocation class separately. Have a second storage administrator reconcile the diagram with actual pool status. Resolve any uncertainty about existing topology before ordering or assigning the additional devices.
\nCompare the proposed special-VDEV redundancy with the failure tolerance of the data VDEVs. Write the owner’s accepted failure scenario in plain language, including what simultaneous device loss the design is intended to tolerate. Keep hardware compatibility and endurance assessment in the applicable device review rather than inferring suitability from the allocation-class name.
\nFor a proposed RAIDZ data pool, make the documented permanent-addition boundary an explicit approval item. Do not offer later whole-VDEV removal as an easy rollback. For a mirrored-data design, review the supported removal procedure separately before promising it as a recovery option.
\nUse a disposable representative pool for any proposed layout exercise. Keep production backup and recovery evidence available through the established storage process. Leave performance claims open until a separately designed workload comparison has been completed under approved conditions.
\nProposed verification: inspect the disposable pool’s data topology and selected special-VDEV members against the approved diagram. Record the reported redundancy and device identities. Ask another reviewer to identify which whole-VDEV removal branch the topology permits from the cited documentation.
\nWhere an expressly approved failure or recovery exercise is required, follow its separately reviewed procedure and retain actual pool and harmless-file observations. Do not create a destructive production failure to demonstrate the warning. Preserve the final pool diagram and the owner’s acceptance of permanence and recovery requirements.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "Bottom line: Treat the metadata VDEV as a pool-layout decision with a failure-tolerance and removal review. Do not approve the addition solely because a proposed device is fast or has spare capacity.\nSource fact: what the authority says\nThe TrueNAS Fusion Pools guide says the special allocation class stores metadata, indirect blocks and deduplication tables, with optional small-file blocks. It warns that losing a special VDEV without redundancy corrupts the pool and prevents access to its data. The guide recommends special-VDEV failure tolerance equal to or greater than the data VDEVs’ tolerance. It says a whole metadata VDEV can be removed only when the data VDEVs are mirrors; with RAIDZ data VDEVs, that addition is permanent.\nWhat the source does not establish\nThis article addresses the versioned special-VDEV layout decision, not a device qualification or performance guarantee. Whole-VDEV removal is the scope of the permanence statement; this article does not prescribe a drive-replacement or member-detachment procedure.\nApplicability questions\n\nAre the pool’s data VDEVs mirrors, RAIDZ or another separately reviewed topology?\nWhat failure tolerance is required from the metadata allocation class?\nWhich exact devices and redundancy layout are proposed?\nDoes the owner accept the documented whole-VDEV removal boundary?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a before-and-proposed pool diagram that labels data VDEVs and the special allocation class separately. Have a second storage administrator reconcile the diagram with actual pool status. Resolve any uncertainty about existing topology before ordering or assigning the additional devices.\nCompare the proposed special-VDEV redundancy with the failure tolerance of the data VDEVs. Write the owner’s accepted failure scenario in plain language, including what simultaneous device loss the design is intended to tolerate. Keep hardware compatibility and endurance assessment in the applicable device review rather than inferring suitability from the allocation-class name.\nFor a proposed RAIDZ data pool, make the documented permanent-addition boundary an explicit approval item. Do not offer later whole-VDEV removal as an easy rollback. For a mirrored-data design, review the supported removal procedure separately before promising it as a recovery option.\nUse a disposable representative pool for any proposed layout exercise. Keep production backup and recovery evidence available through the established storage process. Leave performance claims open until a separately designed workload comparison has been completed under approved conditions.\nVerification and evidence\nProposed verification: inspect the disposable pool’s data topology and selected special-VDEV members against the approved diagram. Record the reported redundancy and device identities. Ask another reviewer to identify which whole-VDEV removal branch the topology permits from the cited documentation.\nWhere an expressly approved failure or recovery exercise is required, follow its separately reviewed procedure and retain actual pool and harmless-file observations. Do not create a destructive production failure to demonstrate the warning. Preserve the final pool diagram and the owner’s acceptance of permanence and recovery requirements.\nOfficial references\n\nTrueNAS — Fusion Pools — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "Bottom line: Treat the metadata VDEV as a pool-layout decision with a failure-tolerance and removal review. Do not approve the addition solely because a proposed device is fast or has spare capacity.\n\n## Source fact: what the authority says\n\nThe [TrueNAS Fusion Pools guide](https://www.truenas.com/docs/scale/25.10/scaletutorials/storage/fusionpoolsscale/) says the special allocation class stores metadata, indirect blocks and deduplication tables, with optional small-file blocks. It warns that losing a special VDEV without redundancy corrupts the pool and prevents access to its data. The guide recommends special-VDEV failure tolerance equal to or greater than the data VDEVs’ tolerance. It says a whole metadata VDEV can be removed only when the data VDEVs are mirrors; with RAIDZ data VDEVs, that addition is permanent.\n\n## What the source does not establish\n\nThis article addresses the versioned special-VDEV layout decision, not a device qualification or performance guarantee. Whole-VDEV removal is the scope of the permanence statement; this article does not prescribe a drive-replacement or member-detachment procedure.\n\n## Applicability questions\n\n- Are the pool’s data VDEVs mirrors, RAIDZ or another separately reviewed topology?\n\n- What failure tolerance is required from the metadata allocation class?\n\n- Which exact devices and redundancy layout are proposed?\n\n- Does the owner accept the documented whole-VDEV removal boundary?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends a before-and-proposed pool diagram that labels data VDEVs and the special allocation class separately. Have a second storage administrator reconcile the diagram with actual pool status. Resolve any uncertainty about existing topology before ordering or assigning the additional devices.\n\nCompare the proposed special-VDEV redundancy with the failure tolerance of the data VDEVs. Write the owner’s accepted failure scenario in plain language, including what simultaneous device loss the design is intended to tolerate. Keep hardware compatibility and endurance assessment in the applicable device review rather than inferring suitability from the allocation-class name.\n\nFor a proposed RAIDZ data pool, make the documented permanent-addition boundary an explicit approval item. Do not offer later whole-VDEV removal as an easy rollback. For a mirrored-data design, review the supported removal procedure separately before promising it as a recovery option.\n\nUse a disposable representative pool for any proposed layout exercise. Keep production backup and recovery evidence available through the established storage process. Leave performance claims open until a separately designed workload comparison has been completed under approved conditions.\n\n## Verification and evidence\n\nProposed verification: inspect the disposable pool’s data topology and selected special-VDEV members against the approved diagram. Record the reported redundancy and device identities. Ask another reviewer to identify which whole-VDEV removal branch the topology permits from the cited documentation.\n\nWhere an expressly approved failure or recovery exercise is required, follow its separately reviewed procedure and retain actual pool and harmless-file observations. Do not create a destructive production failure to demonstrate the warning. Preserve the final pool diagram and the owner’s acceptance of permanence and recovery requirements.\n\n## Official references\n\n- [TrueNAS — Fusion Pools](https://www.truenas.com/docs/scale/25.10/scaletutorials/storage/fusionpoolsscale/) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/review-truenas-metadata-vdev-redundancy-before-adding-a-fusion-pool/", "url": "https://update.dsesecurity.com/updates/review-truenas-metadata-vdev-redundancy-before-adding-a-fusion-pool/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/review-truenas-metadata-vdev-redundancy-before-adding-a-fusion-pool/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Networks & Infrastructure", "item": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "@type": "ListItem", "position": 3, "name": "Review TrueNAS metadata VDEV redundancy before adding a fusion pool", "item": "https://update.dsesecurity.com/updates/review-truenas-metadata-vdev-redundancy-before-adding-a-fusion-pool/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/review-truenas-metadata-vdev-redundancy-before-adding-a-fusion-pool/#article", "identifier": "https://update.dsesecurity.com/updates/review-truenas-metadata-vdev-redundancy-before-adding-a-fusion-pool/", "url": "https://update.dsesecurity.com/updates/review-truenas-metadata-vdev-redundancy-before-adding-a-fusion-pool/", "headline": "Review TrueNAS metadata VDEV redundancy before adding a fusion pool", "description": "The TrueNAS fusion-pool guide makes special-VDEV redundancy critical and warns that a metadata VDEV added to a pool with RAIDZ data VDEVs cannot be removed.", "abstract": "The TrueNAS fusion-pool guide makes special-VDEV redundancy critical and warns that a metadata VDEV added to a pool with RAIDZ data VDEVs cannot be removed.", "articleBody": "Bottom line: Treat the metadata VDEV as a pool-layout decision with a failure-tolerance and removal review. Do not approve the addition solely because a proposed device is fast or has spare capacity.\nSource fact: what the authority says\nThe TrueNAS Fusion Pools guide says the special allocation class stores metadata, indirect blocks and deduplication tables, with optional small-file blocks. It warns that losing a special VDEV without redundancy corrupts the pool and prevents access to its data. The guide recommends special-VDEV failure tolerance equal to or greater than the data VDEVs’ tolerance. It says a whole metadata VDEV can be removed only when the data VDEVs are mirrors; with RAIDZ data VDEVs, that addition is permanent.\nWhat the source does not establish\nThis article addresses the versioned special-VDEV layout decision, not a device qualification or performance guarantee. Whole-VDEV removal is the scope of the permanence statement; this article does not prescribe a drive-replacement or member-detachment procedure.\nApplicability questions\n\nAre the pool’s data VDEVs mirrors, RAIDZ or another separately reviewed topology?\nWhat failure tolerance is required from the metadata allocation class?\nWhich exact devices and redundancy layout are proposed?\nDoes the owner accept the documented whole-VDEV removal boundary?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a before-and-proposed pool diagram that labels data VDEVs and the special allocation class separately. Have a second storage administrator reconcile the diagram with actual pool status. Resolve any uncertainty about existing topology before ordering or assigning the additional devices.\nCompare the proposed special-VDEV redundancy with the failure tolerance of the data VDEVs. Write the owner’s accepted failure scenario in plain language, including what simultaneous device loss the design is intended to tolerate. Keep hardware compatibility and endurance assessment in the applicable device review rather than inferring suitability from the allocation-class name.\nFor a proposed RAIDZ data pool, make the documented permanent-addition boundary an explicit approval item. Do not offer later whole-VDEV removal as an easy rollback. For a mirrored-data design, review the supported removal procedure separately before promising it as a recovery option.\nUse a disposable representative pool for any proposed layout exercise. Keep production backup and recovery evidence available through the established storage process. Leave performance claims open until a separately designed workload comparison has been completed under approved conditions.\nVerification and evidence\nProposed verification: inspect the disposable pool’s data topology and selected special-VDEV members against the approved diagram. Record the reported redundancy and device identities. Ask another reviewer to identify which whole-VDEV removal branch the topology permits from the cited documentation.\nWhere an expressly approved failure or recovery exercise is required, follow its separately reviewed procedure and retain actual pool and harmless-file observations. Do not create a destructive production failure to demonstrate the warning. Preserve the final pool diagram and the owner’s acceptance of permanence and recovery requirements.\nOfficial references\n\nTrueNAS — Fusion Pools — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T19:49:34+00:00", "dateModified": "2026-10-29T19:50:08+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/review-truenas-metadata-vdev-redundancy-before-adding-a-fusion-pool/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/review-truenas-metadata-vdev-redundancy-before-adding-a-fusion-pool/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Review TrueNAS metadata VDEV redundancy before adding a fusion pool" }, "articleSection": [ "Networks & Infrastructure" ], "keywords": [ "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 508, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "TrueNAS — Fusion Pools", "url": "https://www.truenas.com/docs/scale/25.10/scaletutorials/storage/fusionpoolsscale/" } } ] } }