When IT leaders move their unstructured data to a new platform, whether on-premises or in the cloud, thoughtful consideration and advanced planning are critical. Without it, enterprises could face extensive project delays, cost overruns, and data risk.
Ranking high on the project consideration list is migrating snapshots from one network-attached storage (NAS) platform to another.
When thinking about snapshot migration, the words “if and how” can cause a lot of headaches for IT leaders. After all, the implementation of snapshots on a NAS platform is specific to that platform and not compatible between different platforms. Unfortunately, there are also many technological differences in how vendors implement snapshot functionality. For example, some do redirect on write (ROW), copy on write (COW), and the list goes on.
So, what should IT leaders consider when faced with the inevitable snapshot migration dilemma?
A snapshot is a point-in-time image of a file system or a part of a file system. It simply consists of pointers to blocks or files that have not been changed since the snapshot was created and only physically stores later changes (new, deleted, or changed files).
While a snapshot (aka image) of a file looks like a logical full copy, it only consumes the space for the changes since the snapshot was taken. They are created in seconds, don’t consume much physical space on the storage system, yet still represent a (virtual) copy of a filesystem.
Snapshots are often used as complementary backups to restore from logical errors, if files on the original system copy get corrupted, deleted, or encrypted (be it accidental or even by cyberattacks). Snapshots can be used for short-term or limited retention (kept only for a number of hours or days) and also for long-term (extended) retention periods to provide full backup history, depending on the agreed SLA for backups.
Migrating from One NAS to Another
So what should you do with the snapshot history if you are planning to migrate from one vendor’s NAS to a different vendor’s solution?
Unfortunately, simply copying “some pointers and blocks” — which is basically what a snapshot represents on a system — definitely won’t do the trick. The new platform will have absolutely no idea what to do with these fragments of information since it has its own method of composing and maintaining snapshots.
For NAS systems with a limited snapshot history of hours or maybe days, our general recommendation is to migrate only the active data while recreating the snapshot policies on the new system. The old/source system can be kept online as the migration runs and new snapshots are created, and it can also serve as a safety belt until all snapshots have been aged out.
But what about NAS systems with a snapshot history of several months or even years? What if you have to be able to reproduce data from snapshots taken years ago for legal reasons? Simply copying the logical content of snapshots to the new target would multiply the amount of storage needed as your logical (or virtual) copy now becomes a physical copy. For example, if you had 100TB of active data plus 10 yearly backup copies you would need 1.1PB of capacity for the equivalent fully hydrated copies of data.
Migration Made Easy
Luckily you have a choice. StorageMAP’s migration capability is the gold standard for enterprise-class NAS migrations. In many migrations, you may want to avoid the content of snapshots and therefore exclude them from your migration streams. However, StorageMAP gives you the ability to individually select snapshots and migrate them to the new target. Datadobi has developed a simplified solution where you only need the capacity of one (biggest) snapshot plus the changes between each snapshot.
Let’s assume you have a filesystem where you keep the yearly snapshots for a ten-year period (2011 – 2021), as well as the 12 latest monthly snapshots and you have to migrate them all to a new system.
If you follow these (slightly simplified) easy steps, you will end up with a similar space efficiency you had on the source system:
- Rename the oldest snapshot (2011) on the source to a universal name (e.g., ‘migration’)
- Migrate that path (‘migration’) to the target path
- Take a snapshot on the target system and name that snapshot ‘2011’
- Rename the source snapshot to its original name (2011)
- Now rename the second oldest snapshot (2012) to the same name ‘migration’
- Migrate that path to the same target path, take a snapshot and name it ‘2012’
- StorageMAP will only copy the files that changed between the snapshots in 2011 and 2012
- Continue for all the yearly snapshots as well as the 12 monthly snapshots from oldest to newest.
If you need to prove to an auditor that you have successfully and correctly migrated every snapshot, perform a switchover in StorageMAP after every migration step and let StorageMAP compile the chain of custody report for every migration.
Why You Need an Enterprise-Class, Vendor Neutral NAS Migration Expert
Created to simplify data migration, StorageMAP’s powerful migration functionality gives enterprises complete control of their data migrations. Whether it’s snapshot data or live filesystem data, StorageMAP delivers fast, efficient migrations with easy-to-follow wizards, massive scalability, and unrivaled protection and security. We will hash the data at the source and then again at the target and then keep those hashes and provide you a chain of custody document at the time of cutover. The chain of custody document provides verification that the content of the files written matched the content of the files read from the source system.
So rest easy! The combination of speed, accuracy, ease of use, scalability, and automation make the decision to use StorageMAP an easy one to make.
Ready to Get Out of Your Dilemma?
Want to learn more? Contact a member of our sales team to dig yourself out of the snapshot migration dilemma today.