Directadmin backup

Status
Not open for further replies.
No eta at this time. The changes to the internal code are somewhat significant, and also required several skin updates, so bits get done in pieces. Once done, the binaries will be in pre-release for for a while to ensure all is well with the changes.

John
 
If you don't want to deal with this but only make a backup/restore, there is another way to do it.

Warning: It's possible that this will only work if the platform is the same and the major versions are the same. That said, it worked for us over the weekend: shut down the site so no updatest to MySQL are being made. Restart MySQL to make sure buffers are dumped.

Tar up the entire directory from the old server and unpack it on the destination server.

This is NOT guaranteed, so save all your old copies, but it worked for us this weekend.

Jeff
 
every backup created with directadmin 1.35.1 with mysql 5.1 is un restorable by directadmin
please release a minor version to fix this bug only
 
jlasman said:
Tar up the entire directory from the old server and unpack it on the destination server.
Click to expand...

Its what I had to do as well. Also don't forget to either reset the password and/or change it in the mysql.conf file.
 
John pointed me here after I also reported the problem.

I have successfuly ran backups and restored using DA's admin backup.restore feature and mysql 5.1.45,

The problem is mysqldump, and this is what I did.

Ran backup.
Prior to restore untar the tarball.
Inside the backup sub directory load up the sql file(s) in an editor and strip the first line (which is the warning).
Create a new tarball with the same filename and remember to also put the domains directory back in it.
You should now be able to restore data as normal.

this is messy but works.

Using the fixed version John has done probably is easier but I did this before I knew about the new version.
 
jlasman said:
If you don't want to deal with this but only make a backup/restore, there is another way to do it.

Warning: It's possible that this will only work if the platform is the same and the major versions are the same. That said, it worked for us over the weekend: shut down the site so no updatest to MySQL are being made. Restart MySQL to make sure buffers are dumped.

Tar up the entire directory from the old server and unpack it on the destination server.

This is NOT guaranteed, so save all your old copies, but it worked for us this weekend.

Jeff
Click to expand...

MUCH Larger warning: if your databases use the INNODB structure this WILL NOT WORK and will result in much pain and gnashing of teeth and tearing of robes for you.

Most of our customers use INNODB :(
 
Dixiesys said:
MUCH Larger warning: if your databases use the INNODB structure this WILL NOT WORK and will result in much pain and gnashing of teeth and tearing of robes for you.

Most of our customers use INNODB :(
Click to expand...

I do not see why that would make a difference.
 
floyd said:
I do not see why that would make a difference.
Click to expand...

Read up on innodb databases and their architecture and you'll see why, short answer is, all the data is in /var/lib/mysql for -every- innodb database on the server in a big (or several big) ibdata files, for example here's the ls -l from just one random server:

ls -lh /var/lib/mysql | grep ibdata
-rw-rw---- 1 mysql mysql 5.7G May 12 12:19 ibdata1

This is a newer server so the ibdata file is not that big (!!) but I have some with 30+ gigs in ibdata!

So yeah backing up the /var/lib/mysql/DATABASE folder for those database will do nothing but waste your time.
 
Dixiesys said:
Read up on innodb databases and their architecture and you'll see why
Click to expand...

Sorry I don't have that kind of time.

So yeah backing up the /var/lib/mysql/DATABASE folder for those database will do nothing but waste your time.
Click to expand...

But we are talking about backing up the entire /var/lib/mysql. So any innodb files that are on the old server will also be present on the new server when you untar it.

The size of the files makes no difference as to whether it will work or not.

I presume you have tried this and that is why you know it will not work. So what is missing on the new server that prevents it from working?
 
floyd said:
Sorry I don't have that kind of time.



But we are talking about backing up the entire /var/lib/mysql. So any innodb files that are on the old server will also be present on the new server when you untar it.

The size of the files makes no difference as to whether it will work or not.

I presume you have tried this and that is why you know it will not work. So what is missing on the new server that prevents it from working?
Click to expand...

Oh yeah if you backup the WHOLE mysql folder not just the user database folder but damn who wants to backup 10, 20 even 30 gigs of data for one database :D
 
Dixiesys said:
Oh yeah if you backup the WHOLE mysql folder not just the user database folder but damn who wants to backup 10, 20 even 30 gigs of data for one database :D
Click to expand...

Time and size was not in question.

Even if you backed up individual database directories would not the innodb file still be there?

So far the only reason you have suggested that it won't work is that the size is big.
 
floyd said:
Time and size was not in question.

Even if you backed up individual database directories would not the innodb file still be there?

So far the only reason you have suggested that it won't work is that the size is big.
Click to expand...

No the ibdata file is one file for the whole server and it is in /var/lib/mysql so you'd have to grab it AND the user folder, also I'm not 100% sure that's enough either as I think there's 2 more innodb specific files to grab (or more) in mysql and also if your my.cnf is tweaked for innodb with buffer and other settings, you will (maybe) need that too else the new server won't know how the big huge ibdata file is actually setup.
 
Hello John, how far are you with the update i have to move a compleet server to a other one.

I get this error's after a restore.
Unable to restore database klaas&#95gids&#49.sql to klaas_gids1 : ERROR 1064 (42000) at line 1 in file: '/home/klaas/backups/backup/klaas_gids1.sql': You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'Warning: The option '--all' is deprecated and will be removed in a future releas' at line 1

hans
 
Last edited:
ok, so all are using the pre-release bins?

but i read that there are some features releated to ip adress changes that can be buggy?!?

with a server move and or account move i do this all the time...

and yes, i also have serveral servers / accounts to move..

can anyone confirm the prelease bins are also working correctly with ip changes in the restores? .. ;(

thx

soul
 
It has been over 3 months now that this problem has been alive. I've been delaying the server move since then, as I don't want to manually transfer databases.

Are the pre-release binaries stable? I'm tempted to try them, but this is a production server and I don't want any problems... my clients would kill me.
 
Yes, they're stable (they actually always were, but we just had to test them to confirm). We're likely going to release them in the next few days.

John
 
Status
Not open for further replies.
Back
Top