Introduction

This time, there was a problem that the capacity of the on-premises server we manage was tight. The server in question had CentOS 7 pre-installed and was operating as it was. The storage configuration of this server is

-/ dev / sda (128 GB for system) -/ dev / sdb (6 TB for data storage)

It has become. In the pre-installed settings

-Mount point / on / dev / sda1 (50 GB) --Mount point / home on / dev / sdb1 (6 TB)

Then, / var and / opt, which contain DB etc., gradually became fat and made / dev / sda1 tight, and a server error started to occur. Also, / home contains web page sources and personal data, but at most 1 TB is not used, so it seems unlikely that this will increase exponentially.

So I decided to move / var, / opt from / dev / sda to / dev / sdb.

At that time

Shrink / dev / sdb1 to 3 TB
Cut the partition and make 1 TB of / dev / sdb2 and 2 TB of / dev / sdb3.
Transfer the data of / var, / opt
Set the mount point / var to / dev / sdb3 and / opt to / dev / sdb2

The migration is performed according to the procedure. Also, / dev / sdb is formatted in GPT format to handle large storage capacity. The procedure may be slightly different from the MBR format. In particular

--Use fdisk instead of gdisk --In the case of GPT, you have to manually format the file system after partitioning.

And so on.

The author is not responsible for any loss of data as described in this article. Be sure to make a complete backup before proceeding. We also recommend testing in a test environment before doing so.

About SELinux

I am working on changing the mount point, but it seems that SELinux labeling must be set correctly at that time. Please note that I am not familiar with SELinux and I am doing it in a disable environment.

Shrink partition

First shrink the / dev / sdb1 partition.

First, unmount / dev / sdb1.

# umount /dev/sdb1

Next, resize the file system.

# e2fsck -f /dev/sdb1
# resize2fs /dev/sdb1 3000G

resize2fs 1.42.9 (28-Dec-2013)

Resizing the filesystem on /dev/sdb1 to 786432000 (4k) blocks.

resize2fs is a command to resize the file system. This command does not operate on partitions. This will defragment the data scattered in the partition and change the information in the superblock. This will take some time. (Reference: https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/storage_administration_guide/ext4grow)

Here, calculate how many bytes of capacity there is from the output block size after resizing. In this example, 1 block = 4 kB = 4096 B, so the capacity is

786432000 * 4096 = 3,221,225,472,000 B

It will be.

Then shrink the partition. Be sure to check if / dev / sdb is mounted and resize the partition using the interactive mode of parted.


# parted /dev/sdb
(parted) unit b  #Set the output unit to Byte
(parted) p #Output current information
Model: ASR8405 RAID1-data (scsi)
Disk /dev/sdb: 5996837601280B
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number  Start     End             Size            File system  Name  Flags
 1      1048576B  5996836552703B  5996835504128B  ext4

Here, since the start of / dev / sdb1 is 1048576 B, the position of End is calculated by adding the offset of the start to the size (Byte) given earlier.

1,048,576 + 3,221,225,472,000 = 3,221,226,520,576‬ B

This is a continuation of the parted dialogue console.


(parted) resizepart
Partition number? 1

End?  [5996836552192B]? 3221226520576‬B

Warning: Shrinking a partition can cause data loss, are you sure you want to continue?
Yes/No? Yes #I've resized the file system before so it's okay

(parted) p

#Abbreviation

Disk Flags:
Number  Start     End             Size            File system  Name  Flags
 1      1048576B  3221226521087B  3221225472512B  ext4

(parted) q #I was able to confirm that the size was changed correctly, so I quit parted

Now you can see that / dev / sdb1 has shrunk correctly.

Cut a new partition

Next, create / dev / sdb2. We will use gdisk for this task. I can create a new partition with parted, but I couldn't align it well. gdisk also seamlessly aligns, so I decided to use this when partitioning. On the contrary, it is quick and easy to resize the partition with parted.

Here, it is assumed that / dev / sdb2 is 1 TB as opt and / dev / sdb3 is 2 TB as / var.

See Help for the gdisk interactive command. Each command used here

-- n: Create a new partition -- c: Change partition name --p: Print partition table -- w: Write partition

So, no changes are written until you run w.

# gdisk /dev/sdb

GPT fdisk (gdisk) version 0.8.10
 
Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.


Command (? for help): n
Partition number (2-128, default 2): 2
First sector (34-11712573406, default = 6291460096) or {+-}size{KMGTP}:
Last sector (6291460096-11712573406, default = 11712573406) or {+-}size{KMGTP}: +1T
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300):
Changed type of partition to 'Linux filesystem'

Command (? for help): n
Partition number (3-128, default 3): 3
First sector (34-11712573406, default = 8438943744) or {+-}size{KMGTP}:
Last sector (8438943744-11712573406, default = 11712573406) or {+-}size{KMGTP}:
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300):
Changed type of partition to 'Linux filesystem'
 
Command (? for help): c
Partition number (1-3): 2
Enter name: opt
 
Command (? for help): c
Partition number (1-3): 3
Enter name: var
 
Command (? for help): p
Disk /dev/sdb: 11712573440 sectors, 5.5 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): BE239631-679B-474D-B43A-305F9146AE5D
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 11712573406
Partitions will be aligned on 2048-sector boundaries
Total free space is 4061 sectors (2.0 MiB)
 
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048      6291458048   2.9 TiB     0700
   2      6291460096      8438943743   1024.0 GiB  8300  opt
   3      8438943744     11712573406   1.5 TiB     8300  var
 
Command (? for help): w
 
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!
 
Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to /dev/sdb.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.

Now that the partition has been cut, reboot and let the device recognize.

Format a new partition

Then format each newly cut partition with ext4. Use the mkfs.ext4 command to format with ext4.

# mkfs.ext4 /dev/sdb2
mke2fs 1.42.9 (28-Dec-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
67108864 inodes, 268435456 blocks
13421772 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2415919104
8192 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848
 
Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

 
# mkfs.ext4 /dev/sdb3
mke2fs 1.42.9 (28-Dec-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
102301696 inodes, 409203707 blocks
20460185 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2558525440
12488 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848
 
Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

Formatting is now complete.

Move `/ var`, `/ opt` to the newly cut partition

Copy of data

First, if there is a service that is accessing the existing / var, / opt (in / dev / sda1), the migration work cannot be performed, so enter single user mode.

# init 1

In this work, the server was not operated directly, but because of log collection, it was done via ssh, so only this work directly touched the main body and started network, sshd.

# systemctl start network.service
# systemctl start sshd.service

Next, temporarily mount / dev / sdb2 and / dev / sdb3 and copy the contents of the current / opt and / var respectively.

# cd /mnt
# mkdir opt_new var_new
# mount /dev/sdb2 opt_new/
# mount /dev/sdb3 var_new/
# rsync -au /opt/* opt_new/
# rsync -au /var/* var_new/

Now the / opt in / dev / sda1 is copied to / dev / sdb2 and the / var in / dev / sda1 is copied to / dev / sdb3. ..

Unmount it and let it fsck just in case.

# umount /dev/sdb2
# umount /dev/sdb3

# e2fsck -f /dev/sdb2
e2fsck 1.42.9 (28-Dec-2013)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sdb2: 312692/67108864 files (0.2% non-contiguous), 9517164/268435456 blocks

# e2fsck -f /dev/sdb3
e2fsck 1.42.9 (28-Dec-2013)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sdb3: 231758/102301696 files (0.2% non-contiguous), 11135325/409203707 blocks

It's OK.

Create a mount directory

Next, change the current / opt and / var to /opt.org and /var.org, respectively, and create the mount destination directories / opt and / var.

# cd /
# mv opt opt.org
# mv var var.org
# mkdir opt var

Editing `/ etc / fstab`

Then edit / etc / fstab. Before that, check the UUID of the device. For the sake of simplicity, the UUID has been changed to make it easier to understand, so please read as appropriate.

# ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 Jul  2 14:51 33333333-3333-3333-3333-333333333333 -> ../../sdb3
lrwxrwxrwx 1 root root 10 Jul  2 14:51 22222222-2222-2222-2222-222222222222 -> ../../sdb2
lrwxrwxrwx 1 root root 10 Jul  2 14:23 11111111-1111-1111-1111-111111111111 -> ../../sdb1

After checking, edit / etc / fstab and specify / dev / sdb2 as the mount point / opt and / dev / sdb3 as the mount point / var.

`/etc/fstab(Excerpt only where it is relevant)`


UUID=11111111-1111-1111-1111-111111111111 /home                   ext4     defaults        1 2
UUID=22222222-2222-2222-2222-222222222222 /opt                    ext4     defaults        1 2
UUID=33333333-3333-3333-3333-333333333333 /var                    ext4     defaults        1 2

This will reboot.

Confirmation

After starting it, check it with df (excerpt only where it is relevant).

# df -Th
Filesystem                             Type      Size  Used Avail Use% Mounted on
/dev/sdb1                              ext4      2.9T  676G  2.1T  25% /home
/dev/sdb2                              ext4     1008G   21G  937G   3% /opt
/dev/sdb3                              ext4      1.6T   18G  1.5T   2% /var

It is mounted normally.

We also confirmed that services that use / opt and / var are working properly.

Finally

In this era, storage can be variably assembled in the cloud, so I think that such dangerous work is less likely to be done, but please refer to it if you have the opportunity to do it. Don't forget to make a backup and keep it safe.

[LINUX] Move mount point / var, / opt to another storage (GPT)