Migration #23

Closed
opened 2023-06-29 11:58:48 +02:00 by tdpeuter · 4 comments
Owner

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.
However, we also introduce new disks and the configuration will be different (this time with redundancy in mind). Special care is in order.

0. Create a backup

Should be obvious, but I write it down just to be sure.

a. Duplicate the two 2TB HDDs

Because 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 (PUBLIC_MEDIA) over to those.

b. Point services to new data

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. Remove PUBLIC_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 pool

Create a simple pool with these temporary drives.

c. Install new 2TB pool

Install the four 2TB's on the second instance using RAIDZ1 named SMALL, effectively creating a 5.5-6TB pool.

3. Migrate a. Duplicate PRIVATE_DOCS and PRIVATE_MEDIA

Copy these pools from instance 1 over to the new SMALL pool on instance 2.

b. Duplicate 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 1

One 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 2

Let 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 2

It is now safe to move the drives to the second instance. Create a RAIDZ1 pool with these three drives, named BIG, resulting in a 7.5TB pool.

f. Move data from temporary pool to BIG

This should result in an empty temporary pool.

g. Remove temporary pool

Everything should be set now. Move the data around if you like, create some datasets...

Checklist:

Applications:

  • Bazarr
  • Calibre
  • Calibre-web
  • Dashboard
  • FreshRSS
  • Gitea
  • Jellyfin
  • Lidarr
  • Nextcloud
  • Plex
  • Prowlarr
  • QBittorrent
  • Radarr
  • Readarr
  • Sonarr
  • Vaultwarden

Storage:

  • /BACKUP/DEVICES (+SMB)
  • /DATA/GIT
  • /DATA/HOME
  • /MEDIA/AUDIO (+SMB)
  • /MEDIA/BOOKS (+SMB)
  • /MEDIA/HOMEVIDEO (+SMB)
  • /MEDIA/PHOTOARCHIVE (+SMB)
  • /MEDIA/VARIA (+SMB)
  • /MEDIA/VIDEO (+SMB)
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. <details> <summary><b><u>Migration plan of action</b></u></summary> <details> <summary><b>1. Prepare old instance (1)</b></summary> <p>We need to move most of the disks and its content to the new server.</br> However, we also introduce new disks and the configuration will be different (this time with redundancy in mind). Special care is in order.</p> <u>0. Create a backup</u> <p>Should be obvious, but I write it down just to be sure.</p> <u>a. Duplicate the two 2TB HDDs</u> <p>Because 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 (<code>PUBLIC_MEDIA</code>) over to those.</p> <u>b. Point services to new data</u> <p>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.</p> <u>c. Remove <code>PUBLIC_MEDIA</code></u> <p>You should have two 2TB drives on hand now.</p> </details> <details> <summary><b>2. Prepare new instance (2)</b></summary> <u>a. Add temporary disks to allow the migration.</u> <p>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.</p> <u>b. Install temporary pool</u> <p>Create a simple pool with these temporary drives.</p> <u>c. Install new 2TB pool</u> <p>Install the four 2TB's on the second instance using RAIDZ1 named <code>SMALL</code>, effectively creating a 5.5-6TB pool.</p> </details> <details> <summary><b>3. Migrate</b></summary> <u>a. Duplicate <code>PRIVATE_DOCS</code> and <code>PRIVATE_MEDIA</code></u> <p>Copy these pools from instance 1 over to the new <code>SMALL</code> pool on instance 2.</p> <u>b. Duplicate <code>PUBLIC_MEDIA</code></u> <p>Copy this pool from instance 1 over to the temporary pool on instance 2.</p> <u>c. Move services over to new instance 1 by 1</u> <p>One 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.</p> <u>d. Move route from router to instance 2</u> <p>Let the apps route straight to the second instance, without going through instance 1 first. This results in instance 1 not being used any more.</p> <u>e. Install new 4TB pool on instance 2</u> <p>It is now safe to move the drives to the second instance. Create a RAIDZ1 pool with these three drives, named <code>BIG</code>, resulting in a 7.5TB pool.</p> <u>f. Move data from temporary pool to <code>BIG</code></u> <p>This should result in an empty temporary pool.</p> <u>g. Remove temporary pool</u> <p>Everything should be set now. Move the data around if you like, create some datasets...</p> </details> </details> <details> <summary><b><u>Checklist:</u></b></summary> Applications: - [x] Bazarr - [x] Calibre - [x] Calibre-web - [x] Dashboard - [x] FreshRSS - [x] Gitea - [x] Jellyfin - [x] Lidarr - [x] Nextcloud - [x] Plex - [x] Prowlarr - [x] QBittorrent - [x] Radarr - [x] ~~Readarr~~ - [x] Sonarr - [x] Vaultwarden Storage: - [ ] /BACKUP/DEVICES (+SMB) - [x] /DATA/GIT - [x] /DATA/HOME - [x] /MEDIA/AUDIO (+SMB) - [x] /MEDIA/BOOKS (+SMB) - [x] /MEDIA/HOMEVIDEO (+SMB) - [x] /MEDIA/PHOTOARCHIVE (+SMB) - [x] /MEDIA/VARIA (+SMB) - [x] /MEDIA/VIDEO (+SMB) </details>
Author
Owner

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 squared smaller).

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.

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 squared~~ smaller). 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.
Author
Owner

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.

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.
tdpeuter self-assigned this 2023-09-07 21:15:25 +02:00
tdpeuter added this to the Server setup project 2023-09-07 21:19:16 +02:00
Author
Owner

I found a lovely guide by TrueCharts for database migrations.

I found a [lovely guide by TrueCharts](https://truecharts.org/manual/SCALE/guides/migration-pvc/) for database migrations.
tdpeuter added the due date 2023-09-24 2023-09-15 21:35:46 +02:00
tdpeuter added the
chore
label 2023-09-24 11:07:39 +02:00
tdpeuter added a new dependency 2023-09-30 13:34:51 +02:00
Author
Owner

Still need to check if SyncToy agrees.

Still need to check if SyncToy agrees.
tdpeuter removed this from the Server setup project 2023-10-07 20:58:42 +02:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

2023-09-24

Reference: Bos55/Hugo#23
No description provided.