Question

Is that Possible to Increase my /Var without loosing my data in it With a Block Storage Volume

Posted December 30, 2020 435 views
DigitalOcean Volumes

I Would like to increase my /Var which contains my Web site data and Database data already in it. is that possible to increase my /var with a Block Storage Volume WITHOUT LOOSING THE DATA ALREADY IN IT. if so . Kindly Explain the Same

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
Submit an Answer
1 answer

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:

  1. Create a new volume of 10GB(you can choose any size) .

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

  3. 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

  4. 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!

  • Thank You @SandeshKotian Thank you For your Detailed Reply,

    One after Completing the steps above . I Have One Doubt, That is What will happen if I Increase the Volume Storage Latter from 10GB to 500GB Using the Provision Available in the DO Control Panel. Whether that may Affect My Data in the /var or Nothing will happen to My Data

    • @KILAAdmin I just tested that out as well. So, I resized the volume from 10Gb to 500GB from the control panel. I checked the volume size and it appears to be still at 10Gb:

      root@wordpress-ubuntu-s-1vcpu-1gb-blr1-01:~# 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
      

      However, if you check the fdisk output for the sda device, you can see that it has been resized to 500GB:

      root@wordpress-ubuntu-s-1vcpu-1gb-blr1-01:~# fdisk -l | /dev/sda
      Disk /dev/sda: 500 GiB, 536870912000 bytes, 1048576000 sectors
      Disk model: Volume
      Units: sectors of 1 * 512 = 512 bytes
      Sector size (logical/physical): 512 bytes / 512 bytes
      I/O size (minimum/optimal): 512 bytes / 512 bytes
      

      So in this case, we just need to manually resize the filesystem using resize2fs:

      root@wordpress-ubuntu-s-1vcpu-1gb-blr1-01:~# resize2fs /dev/sda
      resize2fs 1.45.5 (07-Jan-2020)
      Filesystem at /dev/sda is mounted on /var; on-line resizing required
      old_desc_blocks = 2, new_desc_blocks = 63
      The filesystem on /dev/sda is now 131072000 (4k) blocks long.
      

      Verify the same using df -h

      root@wordpress-ubuntu-s-1vcpu-1gb-blr1-01:~# 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        493G  949M  472G   1% /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:~#
      

      Now the filesystem is using 500GB of the device sda.

      The Droplet I used for testing has a sample wordpress site with mysql. I checked for data loss, but could not find any. All my files were still there and site is working fine as well. So disk resize on volume will not cause any data loss. But as I always suggest, it is always best to backup your data when we do changes to filesystem or the disk. For volumes, you can take snapshots a shown here: Getting Started with Volume Snapshots :: Snapshot How-Tos