Guys, can I make the tar files and do the wget thing when logged in as root?

Because in SFTP for instance you are logged in as root and if you upload a file then disconnect and FTP in normally you will not be able to delete that file as it is owned by root and not the user.

Will something like this be the case with making the tar file or doing the wget if I am logged in as root via ssh?

You CAN do that just fine as root; in fact, I did it when I was writing it up lol...



If you planned to SCP the file to your local computer you'd have to chown the file to a username you can access the machine with though.

Just a purely hypothetical question about moving the db dum...

Is it going to be quicker to tar the dump, then wget it on the new server, and then (un)tar the dump... or would it be quicker to just wget the dump without doing the tar and untar?

What kind of compression ratio are we looking at when doing a tar of a dump file?

If you're going to be transferring it from one machine to another with WGet and they're both on professionally hosted lines (IE a non DSL/Cable line) then it should be fine to just forget tarring it, as it's text it'll transfer pretty fast on it's own and would take about the same time, but it may affect yoru bandwith quota on either host; so tarring would be best if possible.

And we're looking at a 200mb dump being 20mb.

Righto, I just tried moving my forum to a new server and failed miserably.

I was able to do the following:
-dump the db
-tar both the dump as well as the forum folder titled "ubb"
-wget both to the new server

What I couldn't do: tar (unpack) any of the files on the new server

1. This is what I got when I typed "tar -xzvf forumdump.tgz" into the command prompt:

...a pause that lasted a few seconds, and then this...


gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

2. I was also unable to tar (unpack) the forum files. I did the wget while being in the web root of the new server account, so the tgz file was naturally saved in "public_html" which was what I wanted. But when I tried to unpack it (tar -xzvf ubb.tgz) it simply listed all the compressed files like this... but no new files appeared anywhere so nothing got unpacked:

home/forum/public_html/ubb/file1.whatever
home/forum/public_html/ubb/file2.whatever
home/forum/public_html/ubb/file3.whatever
home/forum/public_html/ubb/file4.whatever
and so on...

What's interesting is that it was listing the path that was used on the old server: home/forum/... (which surprised me because why should a compressed file list the previous absolute path of all its elements), whereas on the new one the correct path is home/ubb/... Still, nothing was unpacked anywhere.

============

Any thoughts on how I can move my forum files across successfully? Is there a way to move over the ubb folder using wget but without a) having to compress anything -and- b) keep the original file permissions? The compression thing is messing me up and I can afford to go without it. But how can I keep all forum file permissions intact?

Very odd, generally that means that the tar archive wasnt' fully created on the source...

And yes, it iwll list what is listed, the -v flag is verbose, which means it'll list all files as they're extracted. It should have extracted all the files to home/forum/public_html/ubb (from the directory you're in; so if you're in /home/gizmo they'd be in /home/gizmo/home/forum/public_html/ubb).

the reason it's listing the path is that when you tarred them you specified a full path to the files, so it was backed up as paths; you can use mv to move the files to where you want them once they're on the server.

Had a few questions earlier but it's all cleared up now.

I had a problem removing files via ftp later after moving and untarring them while logged in as root (funnily enough I could erase the tgz file but not the files that came out of it), but this is not a problem as I can ssh my way in under the account shell login instead.

I'll give the entire move operations another shot in the evening.

ahh, that'd be due to the -p flag (the deletion issue) as it preserves user permissions; so if you run it as root on one machine and don't have root access on the other, you could run into a pickle...

Actually it doesn't seem like the -p tag is the reason as that is used to compress the files/folders. It actually seems to depend on what I'm logged in as (root or user) when I unpack the tgz file on the new server.

So if I use the -p tag to compress the file when logged in as root, I can then uncompress the file on the new server while logged in as the account user and everything will be fine.

Just a quick last-minute question: how would you compare the time it takes to make a mysql dump to the time that it takes to restore the dump on the new server? What kind of ratio are we looking at? Similar... twice as long... more?