# I Built My Own Offsite 3-2-1 Backup System

## Метаданные

- **Канал:** Techno Tim
- **YouTube:** https://www.youtube.com/watch?v=wwt9dDhsgJw
- **Дата:** 12.04.2026
- **Длительность:** 12:19
- **Просмотры:** 48,077

## Описание

I set out to build a real 3-2-1 backup system for my homelab… and it turned into a way bigger project than expected. What started as offsite backup for 30TB of data ended with a second TrueNAS server, a full NAS rebuild, and a third backup copy with a much simpler restore experience.

Video Notes: https://technotim.com/posts/321-backup/

Note: Ubiquiti previously sent me the UNAS months for testing, but this video is not sponsored and they had no input on this video.

Merch Shop 🛍️: https://l.technotim.com/shop
Support me on Patreon: https://www.patreon.com/technotim
Sponsor me on GitHub: https://github.com/sponsors/timothystewart6
Subscribe on Twitch: https://www.twitch.tv/technotim
Become a YouTube member: https://www.youtube.com/channel/UCOk-gHyjcWZNj3Br4oxwh0A/join
Gear Recommendations: https://l.technotim.com/gear
Get Help in Our Discord Community: https://l.technotim.com/discord
2nd channel: https://www.youtube.com/@Technically-Tim

(Affiliate links may be included in this description. I may receive a small commission at no cost to you.)

00:00 - I Built a Real 3-2-1 Backup System
00:49 - Why Cloud Backup Wasn’t the Answer
01:59 - My Main TrueNAS Starting Point
02:30 - Building the Offsite Backup Server
03:12 - 4 Bays, Big Drives, and Compromises
04:26 - Snapshot Replication in TrueNAS
05:04 - When Backup Exposed Bigger Problems
05:29 - Rebuilding My Main NAS
06:12 - Fixing the Old Layout
07:03 - The Migration and Data Shuffle
07:37 - Why 3-2-1 Still Felt Unfinished
08:12 - Why the UNAS Made Sense
09:21 - My Final 3-2-1 Backup Setup
10:13 - Colo Upgrades and Homelab Jank
11:22 - Final Thoughts

Thank you for watching!

## Содержание

### [0:00](https://www.youtube.com/watch?v=wwt9dDhsgJw) I Built a Real 3-2-1 Backup System

In my last HomeLab video, I broke down the software side, what I'm actually self-hosting, what those services do, and how everything fits together. But one of the biggest missing pieces in that video was backups. I want a real 3-2-1 backup solution for my HomeLab without paying a giant ongoing cloud bill for around 30 terabytes of data. Now traditionally, a 3-2-1 backup means three copies on two different media and one copy off-site. But in my HomeLab, I also want a third to live on a different platform with an easier file level restore experience. So in this video, I'm going to walk through the whole thing. Why I didn't just use cloud backup, how the offsite system came together, how it ended up letting me rebuild my main pool safely, and why I added a completely different restore experience at the end.

### [0:49](https://www.youtube.com/watch?v=wwt9dDhsgJw&t=49s) Why Cloud Backup Wasn’t the Answer

Now, just to be clear, this is not me just saying "cloud backup is bad! " For a lot of people, cloud backup is absolutely the right answer. It's simple, it's offsite by default, and for basic file level recovery, it's honestly pretty hard to beat. The problem for me was scale. Once you start talking about 30 terabytes of NAS data, the simple answer of "just throw it in the cloud" starts to feel a whole lot less simple. Backblaze, which I used to use, is great in a lot of ways, especially on the restore side. The whole model of just being able to go and grab a file when you need it is really nice. But for my HomeLab, B2 starts getting really expensive really fast, and I don't really want to sign up for another forever subscription just to protect data that I already own. And then another option is something like Glacier or Deep Archive, which looks way better on paper, until you start to think about restore times, retrieval costs, and what the experience would actually be like if something really bad happened. So for me, the goal became clear. Build something that I own, that I control, and that I understand, with an upfront hardware cost instead of an ongoing backup tax.

### [1:59](https://www.youtube.com/watch?v=wwt9dDhsgJw&t=119s) My Main TrueNAS Starting Point

So the starting point here is my main TrueNAS system at home. This thing holds roughly 30 terabytes of data, but more importantly, it's not just a pile of files. It also supports apps and services, which changes the backup story a lot. Because once the NAS is doing more than just storing media, Backup is not just about do I have the files, it's also about whether I can recover the structure, configs, app data, and actually get everything back in a useful way. So the first real move here was getting a second copy somewhere off-site.

### [2:30](https://www.youtube.com/watch?v=wwt9dDhsgJw&t=150s) Building the Offsite Backup Server

The original goal here was actually pretty simple. I wanted one real off-site copy. And because I already have access to a co-location space, that was the first obvious place to put it. That said, I was not trying to build some perfect backup masterpiece here. I had 1U left in the rack, so whatever this was had to fit in 1U, had to be remotely manageable, and it had to make sense financially. At first I thought about doing some kind of custom build, but once you start looking at 1U cases, drive support, remote management, and all the other trade-offs that come with trying to build a DIY system that fits in a 1U colo rack, it gets expensive really fast and the options narrow down pretty quickly. So I ended up grabbing

### [3:12](https://www.youtube.com/watch?v=wwt9dDhsgJw&t=192s) 4 Bays, Big Drives, and Compromises

a familiar 1U SuperMicro server off eBay. And this is where the backup system started looking pretty different from the main NAS. I went with recertified 22 terabyte Seagate Enterprise drives, which is pretty normal for me. And honestly, with used server pricing, RAM, and all the drives being weirdly expensive right now, this is not exactly the best time to build a NAS. Now I was willing to make different trade-offs here because it's the backup target, not the primary system. With only four drives to work with RAID Z1 was the compromise that made the most sense. Enough backup protection for a backup target without sacrificing too much of the usable capacity. For the boot drive I used a SATA DOM which keeps it nice and tidy inside. One issue I ran into was the RAID controller and TrueNAS really wants direct access to the disk. This one couldn't be flashed into IT mode so it had to go. So I pulled it out and wired the drives directly using a few old SATA cables from a box of random cords that everyone in IT somehow ends up with. I also added 10 gig temporarily because before this thing ever went off site, I wanted to do the initial replication locally without waiting forever. Once the hardware was done, the next step was making it an actual backup

### [4:26](https://www.youtube.com/watch?v=wwt9dDhsgJw&t=266s) Snapshot Replication in TrueNAS

target. And in ZFS terms, what I'm really doing here is snapshot replication. So instead of manually copying files, I'm sending point in time snapshots of datasets over to the second system. So before I could even set up replication, I needed snapshot tasks in the first place. From there, TrueNAS makes this pretty straightforward. Under data replication, you just create replication tasks, pick the data sets that already have snapshots, and then send them over SSH to the remote system. I used a dedicated replication account for this instead of just doing everything as admin. The initial sync took a while, even over 10 gig.

### [5:04](https://www.youtube.com/watch?v=wwt9dDhsgJw&t=304s) When Backup Exposed Bigger Problems

But once that was done, the replication started showing me pretty quickly that my set structure and retention policies were not nearly as clean as I wanted them to be. Most of my datasets were grouped in ways that made snapshot policies and replication harder than it should have been. And the more I looked at it, the more obvious it became that this was not just a backup problem. It was also a structure problem. And that was kind of the first sign that this backup

### [5:29](https://www.youtube.com/watch?v=wwt9dDhsgJw&t=329s) Rebuilding My Main NAS

project was turning into something bigger. That pool was something I put together years ago, before I really knew how the system was going to be used long term. It has (10) 14 terabyte drives and five mirrors, plus a special VDEV, a SLOG, and an L2ARC. And to be clear, that setup works perfectly. Mirrors are still a great way to build storage, especially when you're still figuring things out. But at 10 drives for this workload, it was giving me more IOPS than I really needed, and the capacity trade-off stopped feeling worth it. And this is when the second NAS stopped being just an off-site backup. It was the only reason that this rebuild was possible, because I needed another 30 terabytes of usable space to hold my data while I rebuilt the main NAS. And once I had

### [6:12](https://www.youtube.com/watch?v=wwt9dDhsgJw&t=372s) Fixing the Old Layout

that safety net, the path forward seemed pretty obvious. Everything had grown inside of one big pool. I didn't have clean data set boundaries based on how the data was actually being used, so the backup policy started to sprawl. Once that became clear, the redesign made a whole lot more sense. Instead of one giant pool to do everything, I split them up intentionally. Apps on NVMe, projects on NVMe, and then bulk storage for everything else. Documents, media, Time Machine backups, object storage, NFS shares, and the larger data sets that mostly just care about capacity. That made backups and replication a lot cleaner, gave me better workload separation, improved performance where it actually mattered, and let me move the bulk storage side to a two five wide RAID Z2 VDEVs, which gave me better protection and more usable space back. Once I had the new layout

### [7:03](https://www.youtube.com/watch?v=wwt9dDhsgJw&t=423s) The Migration and Data Shuffle

planned out, then it was time to actually do the scary part. Now before touching the main pool, I exported configs, documented the share and dataset setup, and made sure that the backup side was fully current. Then I stopped SMB, NFS, and the apps, ran a final sync, and verified the backup side before doing anything destructive. Only after that did I destroy the original pool and rebuild the storage layout from scratch. And from there, it was less like hitting a restore button and more like doing a careful data shuffle back and forth to the new structure.

### [7:37](https://www.youtube.com/watch?v=wwt9dDhsgJw&t=457s) Why 3-2-1 Still Felt Unfinished

At that point, I had a primary TrueNAS system and an offsite TrueNAS system. And honestly, that's already a pretty good place to be. I had multiple copies, one was offsite, and the system itself was already way better than when I started. But I still felt like one part of the strategy was unfinished. Even though I had an off-site copy at that point, I didn't have my full three copies and I was still missing the second platform I wanted for the 321. So for me, the last piece was adding a third copy that also gave me a much simpler restore experience when I just need to get a single file back.

### [8:12](https://www.youtube.com/watch?v=wwt9dDhsgJw&t=492s) Why the UNAS Made Sense

And this is where the UNAS came in. I could have built another TrueNAS box, but that still would have left all three copies tied pretty closely to the same stack. And even though the risk is low, I like the idea of having one copy on a completely different platform. The UNAS also fit the environment well. 1U, low power, dual 10 gig, and a simple appliance style setup. But more importantly, it gave me both the extra copy I still needed and a much simpler restore experience. With Drive, I get easy browser-based access, file previews, and quick one-off restores. And that is a very different experience than dealing with ZFS snapshots, restoring to a temporary data set, and manually copying the files back out just to recover one thing. That kind of simple file level restore is one of the nicest parts of services like Backblaze, and this just gave me some of that convenience in my own setup. So while the TrueNAS replication gives me deep system level backup, the UNAS gives me a third copy on a completely different platform with a much easier way to get a file back when I need one. That's what made this feel like a really useful addition, even if it's not where I expected this

### [9:21](https://www.youtube.com/watch?v=wwt9dDhsgJw&t=561s) My Final 3-2-1 Backup Setup

project to end up. So the final setup end up looking like this. Copy one is the main TrueNAS system at home. Copy two is the snapshot replication to the offsite TrueNAS system at the co-location, and copy 3 is a daily file level copy to the UNAS share. That last piece runs from the main TrueNAS system in a small Docker container I put together, which handles the copy over SMB to the UNAS. I'll throw it in the docs if anyone wants to dig through it. And the nice thing is that each copy is doing a slightly different job. The main TrueNAS system is the live system, the off-site full snapshot replica, and the UNAS is the simpler, more convenient way to get a backup quickly, not to mention it's my third local copy. That combination feels a whole lot more complete than me just making three versions of the same thing. And of course, building the offsite

### [10:13](https://www.youtube.com/watch?v=wwt9dDhsgJw&t=613s) Colo Upgrades and Homelab Jank

copy was only half the job. At some point, I actually had to take it to the colo, install it, and handle the rack and network changes that came along with it. I'd basically outgrown the UDM and the colo, so part of this project meant moving to a real switch with 2. 5 gig ethernet. And once that was in place, I decided to upgrade all of the servers with dual 2. 5 gig NICs while I was at it. There were a bunch of smaller jobs wrapped into that too, rails, labels, and eventually replacing the UDMSE with an EFG. And of course, no HomeLab project is complete without at least a little bit jank. In my case, one of the servers has a GPU in it already, and only 1Usable PCIe slot. So adding the NIC turned into a little bit of a side quest. I had to use a PCIe extension cable, remove the bracket from the NIC, and make a little case for it so it wouldn't touch anything on the motherboard. And by "make a little case," I mostly mean copying and pasting a bunch of stuff from the internet into FreeCAD until I had something workable, then zip-tying it into the server, cutting a few holes so the ethernet cables could actually get through. It's not pretty, but it works. And I think this might be peak homelab.

### [11:22](https://www.youtube.com/watch?v=wwt9dDhsgJw&t=682s) Final Thoughts

The biggest takeaway for me is that backup is not just about having multiple copies of your data. It's about knowing what is actually protected, how current it is, and what restoring would really look like if you had to do it for real. In my case, setting up snapshots and replication had also exposed the old layout had gotten more complicated than what it needed to be and fixing that made the whole system so much better. This also reminded me that the backup target is not just there waiting for a disaster. The second NAS is what made this rebuild possible in the first place. And I do think there is real value in having different restore experiences and different platforms, not just more copies on the same stack. So for me, the win here is not just that I bought more hardware. The win is that I now have a backup system that feels a whole lot more complete. when I understand, control, and can actually restore from it more than one way. Well, I hope you enjoyed this video. I'm Tim. Thanks for watching. (ASL)

---
*Источник: https://ekstraktznaniy.ru/video/49202*