Related

Product Managed MySQL, Redis, Postgres on DigitalOcean Product
PHP Error Log: authz_core:error - For files that don't exists on my server Question Question
blocked ip in spam Question Question

Question

Removing a volume: steps to move files back to droplet, remove symbolic link and delete volume

Posted January 25, 2019 2k views
Ubuntu 16.04Block StorageDatabases

Hello -

Short story is my admin is no longer with us and I’m not that familiar with this setup, so appreciate any help.

We have an Ubuntu droplet for our MySql database: db-droplet
We have a volume attached to that droplet and our db tables and data live there: /mnt/db-volume-01

I see in our droplet it has a symbolic link to what I assume is the original location where the db was storing the db table data.

/mysql/db_tables -> /var/lib/mysql/db_tables

We no longer need the volume so we’d like to copy back our data from the volume to the droplet, remove the symbolic link and then detach & delete the volume.

Can anyone please provide the necessary steps and commands to do the above? Much appreciated!

Add a comment
Beerock
By:
Beerock

Related

Product Managed MySQL, Redis, Postgres on DigitalOcean Product
PHP Error Log: authz_core:error - For files that don't exists on my server Question Question
blocked ip in spam Question Question

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
jarland January 25, 2019

Greetings!

I can kind of get you there a bit, but some pieces are relative and you’ll need to consider how they impact you because they might be just a little wrong. Where I’m failing the most, which may cause me to be wrong, is drawing correlation between /mnt/db-volume-01 and /mysql. If the additional volume is mounted at /mnt/db-volume-01 and the databases are symlinked from /mysql, then I assume the databases are not on the additional volume. So for my purposes here, I’m going to just make an assumption that the databases are at /mnt/db-volume-01/mysql and work accordingly.

Under my assumption, this is what I’d do:

  1. Take a snapshot of the droplet. This is your restore point should anything go wrong.
  2. Run these commands:
service mysql stop && systemctl stop mysql #Covers init and systemd, if one fails no issue.
unlink /var/lib/mysql
cp -R /mnt/db-volume-01/mysql /var/lib
service mysql start && systemctl start mysql
umount /mnt/db-volume-01
  1. Look in /etc/fstab to make sure the volume isn’t listed, remove if it is.

This is mildly dangerous and may fail, restoring droplet backup should undo the failure.

Jarland

Reply Report
  • Beerock January 26, 2019

    Much appreciated for the thorough reply Jarland.

    I think you and I are thinking along the same lines here but to clarify…

    The volume is /mnt/db-volume-01
    The db tables are located at /mnt/db-volume-01/mysql/db_tables
    If I cd to /mnt/db-volume-01/mysql and do an “ls” I see the link as 

    db_tables ->  var/lib/mysql/db_tables/

    So I believe I would modify your commands as such

    cd ~ #start at root
service mysql stop && systemctl stop mysql #Covers init and systemd, if one fails no issue.
cd /mnt/db-volume-01/mysql #move to the mounted volume and mysql directory
unlink /var/lib/mysql/db_tables #unlink the symbolic link
cp -R /mnt/db-volume-01/mysql/db_tables /var/lib/mysql/db_tables #copy all contents from volume to droplet
service mysql start && systemctl start mysql
umount /mnt/db-volume-01

    Then if I test and everything is working, I can delete the volume.

    Will the “cp -R” also maintain the same permissions on the files/tables?

    Reply Report
  • Beerock January 29, 2019

    Hi Jarland - thought I’d ask if you had a chance to review my response, and if you think it looks ok? Much appreciated

    Reply Report

Related

Looking for something else?

Ask a new question Search for more help