remote ftp backup not working

[cmdman]

hi mr ..
1.after new version installation  i tried to take remote backup to myftp server it wont works ..  please check..


2. even i saw mysql back it takes only 1 mb or 1 mb size where i have sql database around 700mb  i downloaded backup files via under backup option via via file manager i see ony 1mb database file inside compressed file and site copied good but bad sql backup.

[MRatWork]

Try 'sh /script/backup --class=client --name=admin'.

[cmdman]

do i just need to run this command or edit it

and i face one more problem.. i have 700mb sql back take from phpmyadmin when i tired to import it via phpmyadmin ... i get phpmyadmin page blankpage error

[MRatWork]

Inform here your 'sh /script/sysinfo'.

[cmdman]

[quote ]

[root@server12 script]# sh sysinfo

A. Kloxo-MR: 6.5.1.b-2014042702
here it is..


B. OS: CentOS release 6.5 (Final) x86_64

C. Apps:
   1. MySQL: mysql55-5.5.37-1.ius.el6.x86_64
   2. PHP: php53u-5.3.28-2.ius.el6.x86_64
   3. Httpd: httpd-2.2.27-1.el6.x86_64
   4. Lighttpd: --uninstalled--
   5. Hiawatha: hiawatha-9.5-2.mr.el6.x86_64
   6. Nginx: nginx-1.7.0-1.el6.x86_64
   7. Cache: varnish-3.0.5-1.el6.x86_64
   8. Dns: bind-9.9.5-1.el6.x86_64
   9. Qmail: qmail-toaster-1.03-1.3.38.mr.el6.x86_64
      - with: courier-imap-toaster-4.1.2-1.3.16.mr.el6.x86_64

D. Php-type (for Httpd/proxy): php-fpm_event

E. Memory:
                total       used       free     shared    buffers     cached
   Mem:          1974       1871        103          0         51       1453
   -/+ buffers/cache:        366       1607
   Swap:         2022          0       2022
[/quote]

[MRatWork]

Try update to 2014042902.

Like I said before, 'sh /script/backup' to know what's happen is your backup process. Also investigate '/usr/local/lxlabs/kloxo/log/backup'

[cmdman]

iam talking abt problem with mysql restoration from backup sqldumps i get blank page if i upload 700mb of sql dump which i exported from my old server to new server

[MRatWork]

Oh you mean mysql restore and not Kloxo-MR backup.

You can try with 'mysql -u root -p myDatabase < my_backup.sql' where 'myDatabase' is root password (see your '/usr/local/lxlabs/kloxo/etc/slavedb/dbadmin').

Remember, this restore will fail if mysql dump using innodb as storage-engine and your /etc/my.cnf exist 'skip-innodb'.

[Kloxo-DR]

Hi cmdman,

FOR BIG DATABASES
AVOID EXPORT MYSQL ---> DOWNLOAD ---> UPLOAD ---> IMPORT
USE PACK ---> HIGH SPEED TRANSFER BETWEEN DATACENTERS ---> UNPACK

Anything to do with export from mysql has given many problems. I do a transfer by archiving it and unpacking the archive, a method that is reliable.

FOR THIS YOU DO NOT NEED TO DOWNLOAD THE BACKUP FILE TO YOUR COMPUTER!

#####################################
Do the following:

1) OLD SERVER: PREPARE FOR TRANSFER AND PACK
Make a tar of the corresponding database from # shell and make it accessable on the internet.

Code: [Select]

mkdir /home/clientname/domain.com/download_dir_name
cd /home/clientname/domain.com/download_dir_name
tar -zpcf backup.tgz /var/lib/mysql/db_name

2) NEW SERVER: CONNECT AND DOWNLOAD BY WGET METHOD AND UNPACK

You can use the following to download the backup by following:

Code: [Select]

mkdir /root/download
cd /root/download
wget https://domain.com/download_dir_name/backup.tgz --no-check-certificate
tar -zxvf backup.tgz

Then you are done.
#####################################

In the above step, the database is made available for download via internet. You can add password protection to download_dir_name or backup.tgz, or do without it.

If you add password protection to download_dir_name, then you must make the wget  connection with username and Password.
If you add Password protection to backup.tgz, then you must give it during unpacking by tar -zxvf.

When you download the file to your computer, then you use the download speed of your internet connection of downloadstream. When you upload this file, you use 8 times slower internet connection speed of upstream.

When you make a secure wget connection, you use 10-30 times faster connection from new server to old server for download and transfer the file in compressed format depending the network card attached to both servers and load on the servers.

The advantage of this method is that you DOWNLOAD THE FILE USE HIGH SPEED TRANSFER BETWEEN DATACENTERS.

[cmdman]

@kloxo dr

dont give a use less solutions which is useless

[Kloxo-DR]

Hi cmdman,

It has been 15 years I have been using the above solution. I have written several shell scripts for all kinds  for transfers of data between servers and use them daily.

Any other method is not as good as reliable than above.

In any method other than server to server transfers, one uses ones own computer to download and upload.

Wget and ftps and basically no different. Both work with SSL.

It is a joke to say that this is a useless solution.

Next time when I see your post, I will avoid giving any solution.

No problem. Sorry for wasting my time for you.

[cmdman]

see your solution ,

mkdir /root/download
cd /root/download
wget https://domain.com/download_dir_name/backup.tgz --no-check-certificate
tar -zxvf backup.tgz

where is option to restore 

[Kloxo-DR]

Hi cmdman,

Why the hell you want to restore?

You do not make any "backups". So there is no option or suggestion of "restore".

In the above solution, one already has the database uncompressed under the root directory /root/download. With this one has "kind of restored" in a different location

You simply have to create a new database from kloxomr with any name and copy as follows:

cp /root/download/db_name /var/lib/mysql/old_or_new_db_name

Then all the database files for mysql will appear under the new database (with same or new name) in the new server.

Where is the question of "restore" here?

When people started to use calculators they forgot to calculate. And thats the question you are asking me.

Before you make such rubbish comments "use less is useless", apply your intelligence and inform yourself in advance to talk like this.

[MRatWork]

I think we must back to topic.

If file database backup already exists in server, many options to restore:

1. Use phpmyadmin --> may trouble for big file (let say 100MB+) especially with import process (limiting size and timeout)
2. Use my first propose --> mysql -u root -p myDatabase < /tmp/my_backup.sql (where myDatabase is root password and my_backup.sql is database dump inside /tmp dir)
3. Use a trick like Kloxo-MR do reset mysql root password (the same assumption like no 2; modified for restore purpose):

Code: [Select]

service mysqld stop
sleep 10
mysqld_safe --init-file=/tmp/my_backup.sql
sleep 10
service mysqld start
sleep 10
service mysqld restart


[Kloxo-DR]

Hi Mustafa,

I think we must back to topic.

Did you mean to say that my solution is wrong?

If file database backup already exists in server, many options to restore:

There are even more options to use a dump. The method you suggested is not the only one.

But I can certainly read your thoughts between the lines. It can be avoided tell people "how to use an extra layer" of problems.

Mysql dump, backup and restore is helpful when there is a purpose. Creating mysql dump, it simply makes a file with SQL statements in ASCII format. One can compress it for certain reasons.

Mysql dump with SQL statements in ASCII format is necessary when one should make a version upgrade from Mysql 4--- > 5 or technical pre-requisites changes like INNODB ---> MyISAM.

When all pre-requisites between two servers are equal and a manual transfer is in question, there is no reason for a mysql dump, backup and restore. Why?

Under the mysql database directory /var/lib/mysql there are files with extensions like MYI, MYD, etc. in mysql format. These files will operate under any name of the database under the same mysql server architecture and driver connecting it.

THESE MYSQL FILES ARE NOT SERVER DEPENDENT AND ARE PORTABLE TO ANY SERVER.

So one converts these files to a text file inserting SQL INSERT statements and make one file 10 - 100 times bigger. Then one transfers to a different server. And then one reconverts it back again.

This is a step that can be completely avoided. There are many tutorials available for such a process with php scripts, also interactive. So ofcourse one can use method of back/restore. One can ofcourse give solution to this, when necessary. But this is not always necessary.

Young webmasters will not realize this. There are experts reading such exchanges and your messages are evaluated by the international community. There are journalists writing articles on Kloxo-MR...