Hey Sandy!
This is a bit complicated task! However, it is not impossible to accomplish it. I have managed to mount a block-storage volume to /var/ directory of my Droplet without apparent issues. However, with that being said, I highly recommend you to take snapshots of your Droplet and make sure you have local backups(downloaded from Droplet via SFTP or RSYNC or SCP). Here is what I did:
Create a new volume of 10GB(you can choose any size) .
When you are adding the volume, enter the volume name(in my case, I used the volume name as “var”) opt for Manually Format & Mount and click on Create Volume.
Once the Volume is created, you will get a Modal pop up with the mounting instructions. Copy that and save it on a notepad. It will look something like this
Now SSH into your Droplet and perform the following tasks:
- You will need to stop the
snapd service running in your Droplet:
root@wordpress-ubuntu-s-1vcpu-1gb-blr1-01:~# service snapd stop
Warning: Stopping snapd.service, but it can still be activated by:
snapd.socket
root@wordpress-ubuntu-s-1vcpu-1gb-blr1-01:~# service snapd status
● snapd.service - Snap Daemon
Loaded: loaded (/lib/systemd/system/snapd.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Wed 2020-12-30 10:02:08 UTC; 1min 45s ago
TriggeredBy: ● snapd.socket
Process: 3089 ExecStart=/usr/lib/snapd/snapd (code=exited, status=0/SUCCESS)
Main PID: 3089 (code=exited, status=0/SUCCESS)
We need to stop this as snapd library files are located at /var/lib/snapd and while we copy, mount and reboot, the Droplet would fail to locate the .snap files due to block device change.
*You would need to gracefully stop any database services like MySQL as well. As I mentioned on the top, please make sure that you have backups in place. I would suggest taking MySQL dumps from your database before stopping the service and save it somewhere outside the Droplet environment. *
Create a Directory named “var_backup”:
root@wordpress-ubuntu-s-1vcpu-1gb-blr1-01:~# mkdir /var_backup
Backup contents of /var to /var_backup:
root@wordpress-ubuntu-s-1vcpu-1gb-blr1-01:~# cp -aRf /var/* /var_backup/
Now make ext4 filesystem for the volume.
root@wordpress-ubuntu-s-1vcpu-1gb-blr1-01:~# sudo mkfs.ext4 /dev/disk/by-id/scsi-0DO_Volume_var
mke2fs 1.45.5 (07-Jan-2020)
Discarding device blocks: done
Creating filesystem with 2621440 4k blocks and 655360 inodes
Filesystem UUID: 828e2e2d-0470-4795-8058-6ca56a0f80df
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
Please make sure to replace /dev/disk/by-id/scsi-0DO_Volume_var with whatever was shown on your Modal pop up initially when you created the volume.
Now comes the process of mounting. Here you would face downtime on your website and services. So you will want to plan this out whenever you anticipate less traffic.
Let us rename /varto something else:
root@wordpress-ubuntu-s-1vcpu-1gb-blr1-01:~# mv /var /var_original
- Create a new
/var/ directory:
root@wordpress-ubuntu-s-1vcpu-1gb-blr1-01:~# mkdir /var
- Let us mount our new volume to
/var:
root@wordpress-ubuntu-s-1vcpu-1gb-blr1-01:~# mount -o discard,defaults,noatime /dev/disk/by-id/scsi-0DO_Volume_var /var
(Replace /dev/disk/by-id/scsi-0DO_Volume_var as needed)
Verify that volume is mounted using df -h:
root@wordpress-ubuntu-s-1vcpu-1gb-blr1-01:/var/lib/mysql# df -h
Filesystem Size Used Avail Use% Mounted on
udev 474M 0 474M 0% /dev
tmpfs 99M 960K 98M 1% /run
/dev/vda1 25G 3.3G 21G 14% /
tmpfs 491M 0 491M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 491M 0 491M 0% /sys/fs/cgroup
/dev/vda15 105M 9.2M 96M 9% /boot/efi
/dev/sda 9.8G 918M 8.4G 10% /var
/dev/loop0 56M 56M 0 100% /snap/core18/1885
/dev/loop1 56M 56M 0 100% /snap/core18/1944
/dev/loop2 71M 71M 0 100% /snap/lxd/16922
/dev/loop3 68M 68M 0 100% /snap/lxd/18150
/dev/loop4 32M 32M 0 100% /snap/snapd/10492
/dev/loop5 31M 31M 0 100% /snap/snapd/9607
tmpfs 99M 0 99M 0% /run/user/0
root@wordpress-ubuntu-s-1vcpu-1gb-blr1-01:/var/lib/mysql#
Copy contents from /var_backup or /var_original to /var
root@wordpress-ubuntu-s-1vcpu-1gb-blr1-01:~# cp -aRf /var_backup/* /var
- Now the mount we did above needs to stick post reboot as well. So, we need to make sure that the mount is entered in
/etc/fstab file like below:
root@wordpress-ubuntu-s-1vcpu-1gb-blr1-01:~# echo '/dev/disk/by-id/scsi-0DO_Volume_var /var ext4 defaults,nofail,discard 0 0' | sudo tee -a /etc/fstab
/dev/disk/by-id/scsi-0DO_Volume_var /var ext4 defaults,nofail,discard 0 0
(Please make sure to replace /dev/disk/by-id/scsi-0DO_Volume_var as needed)
- Verify again that mount is defined in
/etc/fstab file:
root@wordpress-ubuntu-s-1vcpu-1gb-blr1-01:~# cat /etc/fstab
LABEL=cloudimg-rootfs / ext4 defaults 0 0
LABEL=UEFI /boot/efi vfat defaults 0 0
/dev/disk/by-id/scsi-0DO_Volume_var /var ext4 defaults,nofail,discard 0 0
- Start your database services and snapd as well:
root@wordpress-ubuntu-s-1vcpu-1gb-blr1-01:~# service snapd start
root@wordpress-ubuntu-s-1vcpu-1gb-blr1-01:~# service snapd status
● snapd.service - Snap Daemon
Loaded: loaded (/lib/systemd/system/snapd.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2020-12-30 10:10:05 UTC; 5s ago
TriggeredBy: ● snapd.socket
Main PID: 4644 (snapd)
Tasks: 9 (limit: 1137)
Memory: 71.7M
CGroup: /system.slice/snapd.service
└─4644 /usr/lib/snapd/snapd
- Reboot the Droplet and test it if the mount point sticks post reboot. Once everything works fine, feel free to delete
/var_backup and /var_orignal directory
I hope this helped!
Best,
Sandesh
Please please make sure that you have backed up everything before doing the above!
Question
