Migration #23
Labels
No labels
bug
chore
duplicate
enhancement
help wanted
invalid
question
urgent
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
Depends on
#30 Share storage between apps and SMB share
Bos55/Hugo
Reference: Bos55/Hugo#23
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I have new hardware on hand and would like to move my server onto the new instance.
It is my goal to keep the downtime of my services as low as possible while migrating to the new server.
This issue will describe the plan of action.
Migration plan of action
1. Prepare old instance (1)
We need to move most of the disks and its content to the new server.
0. Create a backupHowever, we also introduce new disks and the configuration will be different (this time with redundancy in mind). Special care is in order.
Should be obvious, but I write it down just to be sure.
a. Duplicate the two 2TB HDDsBecause the 2TB pool is the only one that is being expanded in the second instance, it makes sense to install those drives on the second instance first. We have enough space in other pools on instance 1 to move the data (
b. Point services to new dataPUBLIC_MEDIA
) over to those.With the data copied over to the other disks, point the services on instance 1 to the new location. There should be no more pointers to the 2TB HDDs.
c. RemovePUBLIC_MEDIA
You should have two 2TB drives on hand now.
2. Prepare new instance (2)
a. Add temporary disks to allow the migration.Because we are mostly reusing the same drives on the new setup, but do this is in a new configuration, we need to store the data in a different location while setting up that new configuration. Add some temporary drives to accommodate the transfer.
b. Install temporary poolCreate a simple pool with these temporary drives.
c. Install new 2TB poolInstall the four 2TB's on the second instance using RAIDZ1 named
SMALL
, effectively creating a 5.5-6TB pool.3. Migrate
a. DuplicatePRIVATE_DOCS
andPRIVATE_MEDIA
Copy these pools from instance 1 over to the new
b. DuplicateSMALL
pool on instance 2.PUBLIC_MEDIA
Copy this pool from instance 1 over to the temporary pool on instance 2.
c. Move services over to new instance 1 by 1One by one, bring your services down/put them in maintenance mode. From the backups that you (should) already have - maybe also create a fresh backup now to have the most recent state of the application, then duplicate the setup. Test it out, then point the route from instance 1 to instance 2.
d. Move route from router to instance 2Let the apps route straight to the second instance, without going through instance 1 first. This results in instance 1 not being used any more.
e. Install new 4TB pool on instance 2It is now safe to move the drives to the second instance. Create a RAIDZ1 pool with these three drives, named
f. Move data from temporary pool toBIG
, resulting in a 7.5TB pool.BIG
This should result in an empty temporary pool.
g. Remove temporary poolEverything should be set now. Move the data around if you like, create some datasets...
Checklist:
Applications:
ReadarrStorage:
It is important to note that it is somewhat discouraged to use RAIDZ1, because sure, a single drive can fail. However, you are at risk while replacing that drive. RAIDZ2 solves that issue, by keeping your data safe, even while replacing a disk (the chance of a disk failing while resilvering your data is just as large, but the chance of another disk failing is
that chance squaredsmaller).On the other hand, this is a homelab, and we have been running striped disks up until this point... We will be fine.
I'll be on the lookout for ways to add more disks to the system.
So far, all routing goes through the second instance. I was unable to do it the other way around, because the old system is already outdated and I cannot update without much trouble.
I found a lovely guide by TrueCharts for database migrations.
Still need to check if SyncToy agrees.