diff options
| -rw-r--r-- | content/post/nas-upgrade/index.md | 32 |
1 files changed, 16 insertions, 16 deletions
diff --git a/content/post/nas-upgrade/index.md b/content/post/nas-upgrade/index.md index c2e8018..ea7f0bb 100644 --- a/content/post/nas-upgrade/index.md +++ b/content/post/nas-upgrade/index.md @@ -11,19 +11,19 @@ Doing it right this time. <!--more--> Until now I've been using a [RockPro64](https://pine64.org/devices/rockpro64/) in the (excellent for starters) Pine64 [NAS case](https://wiki.pine64.org/wiki/NASCase) for my NAS. -It runs [Armbian](https://www.armbian.com/rockpro64/), and `openzfs`, and I managed my ZFS as needed on the CLI. +It runs [Armbian](https://www.armbian.com/rockpro64/), `openzfs`, and I manage my ZFS as needed on the CLI. I share my datasets over NFS to my Proxmox guest VMs for access. This has served me reasonably well for the past few years. -But we have a baby comming soon, and along with that a flurry of new photos and videos +But we have a baby coming soon, and along with that a flurry of new photos and videos for my family to store on my NAS. -And although I *probably* have enough buffer to survive the inital few months, -I certainly wish to do better than my current 2xHDD mirrorred pool giving me ~4TB of storage. +And although I *probably* have enough buffer to survive the initial few months, +I certainly wish to do better than my current 2xHDD mirrored pool giving me ~4TB of storage.  # The Plan Luckily I already possess the hard-drives I need for my desired pool. -In total I have 2 HDDs from my current NAS, and 2 spares - +In total, I have 2 HDDs from my current NAS, and 2 spares - all the same 4TB capacity. I still want to keep my current NAS running as a backup store, @@ -34,8 +34,8 @@ me 2 drives for storage and 1 for parity. Now for the platform. I have been a very happy user of [Proxmox](https://www.proxmox.com/en/proxmox-virtual-environment/overview) (on my compute node) and it already comes ready with ZFS support so I'll stick with that. I did consider [TrueNAS](https://www.truenas.com) (both standalone, and virtualized within Proxmox with -disk-passthrough), but I when it comes to storage, I want as few surprises as possible -so I stuck with what I know. I'm already used to ZFS on the CLI and Proxmox is basically +disk-passthrough), but when it comes to storage, I want as few surprises as possible +so I stuck with what I know. I'm already used to ZFS on the CLI and Proxmox is based on Debian so if/when something goes wrong, I don't want to be messing around with an unfamiliar UI. Although I don't want to manage ZFS via a GUI, @@ -56,7 +56,7 @@ Wants: - 1U - 10Gb networking -On Ebay, I ended up checking-out with: +On eBay, I ended up checking out with:   @@ -73,7 +73,7 @@ First I free one of my HDDs from my RockPro64 NAS for use in my new pool. This means I am running on a single HDD for the remainder of the migration. With the free HDD, and my two spares, -I get everything assembled, and setup a new Proxmox node with a ZFS pool +I get everything assembled, and set up a new Proxmox node with a ZFS pool from the UI using the 3 disks.  @@ -81,11 +81,11 @@ from the UI using the 3 disks. # Sync To migrate all of my data from the old pool to the new pool I use [`syncoid`](https://github.com/jimsalterjrs/sanoid/tree/master?tab=readme-ov-file#syncoid). -It uses ZFS snapshots to accomplish this. Its awesome. +It uses ZFS snapshots to accomplish this. It's awesome. This takes many hours depending on the size of your pool and your connection, -but I since I saw almost full utilization of my network link -I was convinced its the best I can do right now. +but since I saw almost full utilization of my network link +I was convinced it's the best I can do right now. I've seen in a few Reddit posts suggesting ways this can be optimized using some combination of `zfs send` with `mbuffer` rather than `ssh` which @@ -102,7 +102,7 @@ sync, I do not want to stay in this state for any longer than I need to due to potentially leading my single disk to failure. Once the sync is complete, I do a second sync (for the delta), and promptly -shutdown all of my services to prepare for the cut-over. +shut down all of my services to prepare for the cut-over. # Cockpit Before I can re-enable my services. I need to expose my datasets on Cockpit. @@ -114,7 +114,7 @@ Other than that, I just make sure my container has the NFS feature enabled: Setting up user permissions is a pain, but once done I expose the relevant NFS as well as Samba paths for my services - -basically replicating my old NAS's shared paths. +replicating my old NAS's shared paths. # Voila In my homelab nameserver, I update the A record @@ -126,8 +126,8 @@ I confirm everything is still good by turning off the old NAS, and yep still goo Luckily for me all good on the first try! # Finishing touches -I setup a cron on my old NAS to sync data nightly from the new pool. -This will only work while my the actual data size on my new pool is less than 4TB, +I set up a cron on my old NAS to sync data nightly from the new pool. +This will only work while the actual data size on my new pool is less than 4TB, so I'll need to get a new drive with higher capacity to keep the backups going in the future. |