[youssefbasha]

This tutorial is made specially for HostLease vps holders and whats a backup for their servers
As we all know, there was some problems with HostLease Network which sadly lead to immediate end for the sponsorship and to backup your files you will need rescue mode enabled on your server, so at first make a topic in private vps support and admins will start it for you (they may change the root password to the default one that was in the vps request topic)
So at first you need to login with your ssh details but 22 port only will be available for ssh even if you disabled it and opened another port.
First step to do after logging in at rescue mode is to mount your disk space into rescue mode so get your disk info by using

Terminal

root@rescue:~# fdisk -l

Disk /dev/vda: 704 MiB, 738197504 bytes, 1441792 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x2dd1bce6

Device     Boot Start     End Sectors  Size Id Type
/dev/vda1  *     2048 1435647 1433600  700M 83 Linux

Disk /dev/vdb: 75 GiB, 80530636800 bytes, 157286400 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000b136f

Device     Boot     Start       End   Sectors Size Id Type
/dev/vdb1  *         2048 148897792 148895745  71G 83 Linux
/dev/vdb2       148897793 157286399   8388607   4G 82 Linux swap / Solaris

root@rescue:~#

So here my disk space was in /dev/vdb1 and thats thats probably with all users
Second step is to make a directory for the disk

Terminal

mkdir /backup

Third step to do is to mount the disk in that directory

Terminal

mount -t auto -o ro /dev/vdb1 /backup

Fourth step is to check if its mounted successfully

Terminal

root@rescue:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       672M  653M     0 100% /
udev             10M     0   10M   0% /dev
tmpfs           793M   81M  713M  11% /run
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup
/dev/vdb1        70G  8.4G   58G  13% /backup
root@rescue:~#

Fifth step is to login with the same info at filezilla/wincp and go to backup folder, it will give u access to all directories of the server.
This was how can you backup your files, to backup your MySQL database you can find them in /var/lib/mysql or the directory that contains MySQL my.cnf file you can download the folder of the mysql that you want and upload it to the another host/place when you need it.
Hope you liked the tutorial
I typed this in 5 minutes so if there is any grammar mistakes tell me in private and i will edit them, if anyone got edits/questions for this topic you can leave leave a reply

[Mashiro]

Good job but this is more of a tutorial for/about "how to mount partitions in Linux via command line" based on something you had to do to achieve a goal and what you did to get to it. There is nothing about doing the backup of the MySQL databases.

Well, you did mention the path where the database files are usually stored:
- /var/lib/mysql usually ALWAYs contains the database files (mind the "usually" since you can change the path but that path is the default).
- /etc/mysql (and similar) is just the folder with the MySQL database server configuration files and you won't find the databases there.

Backing up the database files by copying them from /var/lib/mysql is a bit of a last resort usually. Depending on how the database server was shutdown the files might be "unclean" as the shutdown was not clean/proper. If you import that into a new server you might run into some issues. Just need to be careful.

To backup it up properly you could rebind the local /var/lib/x to /var/lib/x on the drive you are trying to backup, then install MySQL and do a clean start of it to get the database checked and such and after that run a mysqldump. However that is more advanced than it sounds like for most users.

[youssefbasha]

Actually @"Hidden Refuge" you are right, seems that because my MySQL server didn't shut down well the files are unclean which caused me some errors in the database i moved like  #1033 - Incorrect information in file: './xx/xx.frm'
And i didn't figure out how can i fix this yet

[fChk]

Actually @"Hidden Refuge" you are right, seems that because my MySQL server didn't shut down well the files are unclean which caused me some errors in the database i moved like  #1033 - Incorrect information in file: './xx/xx.frm'
And i didn't figure out how can i fix this yet

I'm not sure if this is still relevant but, in any case here is the command for that (adjust it to your own case):

Code: (Select All)

mysqldump -u root -p --host=localhost --port 3306 --default-character-set=utf8 --all-databases > /output_path/all_databases.sql

The above suppose that you remounted the filesystem and started mysqld.

Edit: To debug the #1033 error, you need to give us a lot more information than what's in the the quoted text.

Good luck!

[Mashiro]

[...] 
#1033 - Incorrect information in file: './xx/xx.frm'
And i didn't figure out how can i fix this yet

Looks like maybe your database is a InnoDB database. Did you enable the InnoDB database engine on your new server?

You can see if InnoDB database engine is running with the command below:

Code: (Select All)

SHOW ENGINES;

Just run "mysql -u root -p" and login with your MySQL root password. After that run the command above.

The result should look like (example output with InnoDB disabled):



Alternatively this error can also be caused by corrupted database files when the InnoDB database engine is enabled and running.

You could use the following option to force a automatic database recovery via InnoDB:

Code: (Select All)

innodb_force_recovery "1"

This line has to be placed inside the my.cnf file for the InnoDB configuration block.

Be aware that this can lead to data loss according to some research I did. So if the recovery fails the database might be more corrupted than it already is. So take a backup of the files you have before launching MySQL with that option. And if your database gets repaired successfully shutdown the MySQL server clean, remove the command and launch the server again.


Other than that I have no clue how else to fix the issue without being able to reproduce it. I'm not a magician. Fixing issues I never experienced or reproduced is pretty hard.

[humanpuff69]

Good job but this is more of a tutorial for/about "how to mount partitions in Linux via command line" based on something you had to do to achieve a goal and what you did to get to it. There is nothing about doing the backup of the MySQL databases.

Well, you did mention the path where the database files are usually stored:
- /var/lib/mysql usually ALWAYs contains the database files (mind the "usually" since you can change the path but that path is the default).
- /etc/mysql (and similar) is just the folder with the MySQL database server configuration files and you won't find the databases there.

Backing up the database files by copying them from /var/lib/mysql is a bit of a last resort usually. Depending on how the database server was shutdown the files might be "unclean" as the shutdown was not clean/proper. If you import that into a new server you might run into some issues. Just need to be careful.

To backup it up properly you could rebind the local /var/lib/x to /var/lib/x on the drive you are trying to backup, then install MySQL and do a clean start of it to get the database checked and such and after that run a mysqldump. However that is more advanced than it sounds like for most users.

that what i use . i backup the /var/lib/mysql server when i backup or migrate the server . when i migrate from VPS 9 to VPS 5 i compress the /var/lib/mysql into zip and send the zip to the new vps and extract it there

for /etc/mysql i dont back that up and it work just fine

mysql isnt the only thing that i back up at that time . i backup the root directory because it contains all my https certificate . the nginx sites-enabled folder that contain all the sites setting , var www folder that contain all the sites files and finally the var lib mysql itself for the mysql database