Backing Up a NAS Before a RAID Migration

The short answer

Before changing drives or migrating a RAID layout, create at least one complete, independently accessible backup of your important NAS data, then test restoring representative files. Treat the existing RAID as the source—not as the backup—and include NAS settings, application data, databases, Plex metadata, and surveillance footage if they matter to you.

A safer migration sequence is:

1. Inventory the data and configuration you need to preserve.
2. Check the NAS and drives for errors.
3. Create a backup on separate storage.
4. Create an additional off-site or offline copy when the data is important.
5. Verify the backups and perform a test restore.
6. Only then change the RAID layout, replace drives, or rebuild the pool.
7. Keep the original source or a verified backup untouched until the migration is complete.

RAID, snapshots, and backup solve different problems

These protections are often confused because they all help with data loss. They do not provide the same protection.

Protection	Primary purpose	Helps with	Does not reliably protect against
RAID	Availability and continued operation	A supported drive failure, depending on the RAID level and implementation	Accidental deletion, malware, theft, fire, failed migration, or multiple failures beyond its tolerance
Snapshots	Point-in-time recovery	Accidental edits, deletion, and some ransomware scenarios	Pool loss, NAS theft, major hardware failure, or an administrator deleting the snapshots
Backup	Recovery from a separate copy	NAS failure, migration mistakes, deletion, corruption, theft, and disasters when stored separately	Nothing if it is incomplete, inaccessible, or never tested

RAID can keep a NAS online when a drive fails, but it does not create an independent copy of your files. A RAID migration may also stress the remaining drives while data is being redistributed or rebuilt. If something goes wrong, the array itself may not provide a usable recovery path.

Snapshots are useful for fast local recovery, but they commonly reside on the same storage pool as the original files. If that pool is destroyed or encrypted, the snapshots may be lost or unavailable too. Some platforms support replicated or immutable snapshots; whether that protection applies depends on the NAS software and configuration.

A true backup must be stored on separate storage. For stronger protection, keep at least one copy offline or off-site.

What can go wrong during a RAID migration?

The exact risks depend on the NAS operating system, RAID technology, drive condition, and migration method. Common failure scenarios include:

• A drive fails during a rebuild or RAID reshape.
• Another drive develops an unreadable sector while the array is degraded.
• The migration process is interrupted by a power outage or hardware fault.
• The new layout has less usable capacity than expected.
• A mistake causes the wrong volume or pool to be reformatted.
• File permissions, shares, applications, or databases are not recreated correctly.
• Data appears to migrate successfully, but files are incomplete or inaccessible.
• A previously hidden corruption problem is discovered only after the old layout is gone.
• A drive is removed before its contents have been copied and verified.
• A backup exists but cannot be restored because it was never tested.

A RAID-level change can also alter the practical balance between capacity, redundancy, and rebuild exposure. Do not assume that a migration is reversible. Check your NAS vendor’s documentation for whether the operation is online, destructive, interruptible, or supported only for particular RAID levels.

Start with a migration inventory

Before backing up, list what must survive the transition. A file copy alone may not preserve everything needed to return the NAS to working order.

Include user data

Identify:

• Documents, photos, videos, and project files
• Shared folders and home directories
• Hidden files and application-specific folders
• File permissions, ownership, and access-control lists
• Versioned files or previous revisions
• Encrypted folders and the keys or passphrases needed to open them

Include application and service data

Back up the data and configuration for services such as:

• Plex or other media servers, including metadata and watched-status data if important
• Download managers and automation applications
• Databases
• Virtual machines and containers
• Synced cloud folders
• Surveillance recordings and camera configuration
• Backup-job definitions
• User accounts, groups, shares, and network settings

Applications may store data outside the folders you normally browse. Use the NAS application’s export or backup function where available. If an application uses a live database, do not assume that copying its files while it is running creates a consistent backup. Stop the service or use its supported backup method.

Decide what does not need to be migrated

Not every byte needs the same protection. For example, temporary downloads, replaceable cache files, and regenerated thumbnails may not need a full backup. Mark those exclusions explicitly rather than discovering them after the migration.

For Plex, decide whether the media files are the priority, or whether playlists, posters, watch history, and metadata must also be preserved. For surveillance, determine the required retention period and whether recordings are legally or operationally important.

Check the source NAS before copying

A backup made from a damaged or already-degraded source may contain errors. Before starting the migration backup:

1. Check the NAS dashboard for degraded pools, drive warnings, scrub errors, or filesystem alerts.
2. Review recent SMART or drive-health reports where available.
3. Confirm that the pool has enough free space for normal operation and the planned migration.
4. Run the platform’s recommended filesystem scrub or consistency check if appropriate.
5. Record the current RAID level, drive identities, pool layout, shares, and applications.
6. Make sure the NAS has reliable power during the backup and migration.

Do not begin a risky migration just because the NAS is still accessible. If the array is already degraded or reporting errors, prioritize copying irreplaceable data and consider professional recovery advice before making structural changes.

Use a practical 3-2-1 backup workflow

The 3-2-1 rule means keeping:

• 3 copies of important data
• On 2 different types of storage or media
• With 1 copy off-site

For a NAS RAID migration, a practical arrangement could be:

1. The original data on the current NAS array.
2. A full backup on a separate external drive, second NAS, or backup server.
3. An off-site or offline copy, such as rotated storage or a supported cloud backup.

The exact media depends on your capacity, network, budget, and recovery requirements. A second NAS in the same room is useful for fast recovery, but it does not protect against theft, fire, or a power event affecting both devices. An external drive disconnected after the backup can protect against some ransomware and administrative mistakes, but it must be stored safely and connected periodically for refreshes.

A backup destination should not be another folder on the same pool that is being migrated. It should remain accessible if the source pool is lost.

Choose the backup method

Common options include:

• NAS-to-external-drive backup: Simple and often fast enough for a one-time migration. Confirm that permissions, hidden files, and long paths are preserved.
• NAS-to-second-NAS backup: Useful for ongoing replication and future recovery. Keep the second system independent from the migration.
• Computer-mediated copy: Can work for selected files, but it may miss NAS permissions, application data, and hidden directories.
• Cloud backup: Useful for off-site protection, but initial uploads may take a long time and restore costs or limits may apply.
• NAS backup software: Often provides versioning, integrity checks, scheduling, and application-aware options. Review exactly what it includes rather than assuming it captures the entire system.

For large datasets, estimate transfer time before starting:

Transfer time (hours) = Data size (GB) / Sustained throughput (GB per hour)

Network links are usually quoted in bits, while file transfers are measured in bytes:

Theoretical MB/s = Network bandwidth (Gbps) × 1,000 / 8

Actual throughput is lower because of protocol overhead, small files, encryption, disk speed, filesystem work, and other NAS activity. A large media library may copy efficiently, while millions of small files can take much longer.

Verify the backup before changing RAID

A completed copy is not automatically a usable backup. Verification should happen before the original layout is altered.

Check the backup contents

Confirm that:

• The expected top-level shares and folders exist.
• File counts and approximate sizes are reasonable.
• Large, small, recently changed, and older files are present.
• Files with unusual names, permissions, or characters were copied.
• Encrypted data can be opened with the required keys.
• Plex metadata, databases, virtual machines, and containers have usable backups.
• Surveillance recordings cover the required dates.
• The backup job reports no skipped, locked, or failed files.

Where supported, use checksums, verification passes, or the backup application’s integrity check. A file count alone cannot prove that every file is identical.

Perform a test restore

Restore a sample to a different location and open it. Include:

• A document
• A photo
• A video
• A folder with many small files
• A file with restrictive permissions
• An application database or configuration export
• A Plex metadata or library backup if that information matters
• A surveillance recording from the required retention window

For a more meaningful test, temporarily restore a complete small share or application to another system. Confirm that users can access it and that the application can actually use the restored data.

A backup that cannot be restored is only an assumption of safety.

Keep the original data available during migration

If the migration is non-destructive and your NAS documentation supports it, leave the original data intact until:

• The new layout is online.
• The pool or volume passes its health checks.
• Shares and permissions work.
• Applications start correctly.
• Representative files open normally.
• The backup remains readable.
• A fresh backup has been completed from the new layout.

Do not erase old drives immediately after a successful copy. If the old drives are still usable and the migration method allows it, retain them untouched for a defined period. This gives you another recovery option if a hidden problem appears after the change.

The old drives are not a substitute for a backup, particularly if they are reused, stored together with the NAS, or have not been tested. They are an additional fallback.

Plan retention instead of keeping one temporary copy

A migration backup is often treated as a one-time safety net, but it can also expose weaknesses in your normal retention policy.

Consider retaining:

• Daily versions for recently changed files
• Weekly or monthly versions for longer-term recovery
• A longer-lived copy for irreplaceable photos, records, or projects
• An offline or off-site copy protected from routine deletion

Retention should match how far back you may need to recover. A single mirrored copy can faithfully reproduce accidental deletion or corrupted files. Versioned backups and snapshots provide more recovery points.

Set retention separately for different data:

• Personal documents and photos: Longer historical retention may be worthwhile.
• Media libraries: Re-downloadable media may need less versioning than unique metadata.
• Plex metadata: Protect it if recreating watched status, posters, and collections would be difficult.
• Surveillance footage: Retain according to operational, legal, or insurance requirements.
• Databases and business files: Use application-consistent backups and a defined recovery point.

Snapshots can complement backups by offering quick recovery from recent mistakes. They should not be counted as one of the independent 3-2-1 copies unless they are replicated to separate storage and protected from the same failure.

Account for power and network interruptions

A RAID migration and a large backup can run for hours or days. Reduce avoidable risks:

• Use a UPS that the NAS can monitor and shut down through supported software.
• Avoid starting a migration when severe power or network instability is expected.
• Do not disconnect an external backup drive while a job is active.
• Confirm that the NAS and backup destination have sufficient power and cooling.
• Schedule heavy transfers when the NAS is not running unnecessary workloads.
• Avoid running a drive replacement, scrub, backup, and media transcode workload simultaneously unless the platform and hardware are designed for it.

A UPS helps with short power interruptions and controlled shutdowns. It does not replace a backup or protect against every electrical failure.

Understand capacity before the new layout

A RAID migration may change usable capacity. Calculate capacity using the NAS platform’s documented rules rather than relying on raw drive totals.

A simple raw-capacity estimate for equal-size drives is:

Raw capacity = Number of drives × Advertised drive capacity

Usable capacity depends on the RAID level, filesystem, reserved space, metadata, and the platform’s unit conventions. For parity layouts, a rough conceptual estimate may be:

Usable capacity ≈ (Number of drives − Parity drives) × Smallest drive capacity

This is only an estimate, not a guarantee of the volume size shown by your NAS. Mixed drive sizes, vendor-specific layouts, hot spares, snapshots, and reserved system space can reduce usable capacity.

Before migration, confirm:

• The new layout can hold all data plus working free space.
• The smallest drive does not unnecessarily limit the array.
• Snapshot and backup space is included.
• Surveillance growth is included.
• Future drive expansion is actually supported by the NAS.
• The backup destination is large enough for the selected version history.

Do not start a migration based solely on the maximum advertised capacity of the drives.

When SSD cache is involved

SSD cache does not replace a backup. It may contain recently written or frequently read blocks, metadata, or application-related data depending on the NAS configuration. Before changing the pool:

• Follow the NAS vendor’s procedure for disabling or removing the cache.
• Wait for dirty data to be flushed if the platform requires it.
• Confirm that the cache is healthy.
• Back up the underlying data independently.
• Do not remove cache devices as if they were ordinary unused drives.

The exact behavior depends on whether the cache is read-only, write-through, or write-back, and on the NAS software. If the cache configuration is unclear, consult the platform documentation before proceeding.

Data-protection checklist

Use this checklist before starting a RAID migration:

• [ ] I documented the current RAID, pool, volume, and drive layout.
• [ ] I listed the shares and data that must be preserved.
• [ ] I included permissions, accounts, configuration, and application data.
• [ ] I identified Plex metadata, databases, containers, virtual machines, and surveillance footage that matter.
• [ ] I checked the NAS and drives for existing warnings or errors.
• [ ] I created a complete backup on storage independent of the source pool.
• [ ] I created an off-site or offline copy for important data.
• [ ] I confirmed the backup contains the expected files and dates.
• [ ] I ran integrity verification or checksum validation where available.
• [ ] I completed a test restore and opened the restored files.
• [ ] I confirmed the new RAID layout has enough usable capacity.
• [ ] I reviewed whether the migration is destructive, interruptible, or reversible.
• [ ] I protected the NAS and backup destination from power interruption.
• [ ] I followed the correct procedure for SSD cache removal, if applicable.
• [ ] I know how to restore NAS settings, shares, permissions, and applications.
• [ ] I will not erase or reuse the old drives until the new layout is verified.
• [ ] I have a plan for a fresh backup after the migration succeeds.

Once the backup is verified, RAID migration becomes a controlled storage change rather than your only chance to preserve the data. For future NAS purchases or a replacement system, Browse NAS to compare storage options, or review NAS & storage servers when you need a larger platform for backup capacity and expansion.