There are various ways of transferring files between Linux systems.
scp uses encryption making it a good option when copying sensitive data between two remote locations. For this use case,
rsync makes the most sense as we will be transferring files between development, testing and production servers all on the same local network.
In this guide I am moving a Drupal installation, but these instructions can be applied to any other use case.
1: Copying the files
We will be working on our new server, copying files to it from the old server.
In the following command, the first path denotes the source directory, the second is the destination directory (if it doesn't exist it will be created). However,
/var/www/html/ should be there, as it is Ubuntu's default Apache web directory.
user enter your source server’s admin user name. For
remote.host enter the IP or domain name of your source server.
Note: Include the trailing slash on the source directory to prevent it from being created inside the destination directory. In other words, you can think of a trailing
/ on a source as meaning "copy the contents of this directory" into
html as opposed to "copy the directory by name", which would result in
html/example.com. Note, however, that the attributes of
example.com (user, group, permissions) will still be applied to
sudo rsync -rlptDvz email@example.com:/var/www/vhosts/bigmarker.de/og.bigmarker.de/ /var/www/html/
sudo, the permissions of all files will be
2: Fix file attributes
2.1: Make Apache root readable
sudo chmod 755 /var/www/html
2.2: Make web site files belong to dev
Go to webroot:
root-owned files and directories and
find . -user root -group root -print0 | xargs -0 sudo chown -v -h dev:dev
2.3: Fixing Drupal’s various directories
Allow module updates:
sudo chown www-data:www-data /var/www/html/sites/default/
Allow Drupal to create new shared-site directories:
sudo chown www-data:www-data /var/www/html/sites/all
Allow Drupal to install modules, libraries and translations:
sudo chown -R www-data:www-data /var/www/html/sites/all/libraries
sudo chown -R www-data:www-data /var/www/html/sites/all/modules
sudo chown -R www-data:www-data /var/www/html/sites/all/translations
Allow Drupal users to save content:
sudo chown -R www-data:www-data /var/www/html/sites/default/files
Fix Composer Manager directory:
sudo chown dev:dev /var/www/html/sites/default/files/private/composer/composer.*
3: Copying the database
Opening your website in a browser should produce the follow:
This is a good error. It’s looking for our database.
We will export a MySQL database from our old server, then import it to our new one.
3.1: Export database
To export, we need command line access on the old server.
For this example, we will assume our MySQL user name is
ogu and our database name is
We will now export and compress the database in one command:
mysqldump -u ogu -p og | gzip -9 > /var/www/vhosts/bigmarker.de/ogdb.sql.gz
Enter password for the database user
-9 option is for max compression. But on extremely large databases, that could mean a longer compress time. Leave blank for the default level of 7, or pick another number.
3.2: Copy database to the new server
Going back to our command line for the new server:
sudo scp firstname.lastname@example.org:/var/www/vhosts/bigmarker.de/ogdb.sql.gz /var/www
3.3: Prepare MySQL for import
Enter the password you chose for MySQL during installation.
Now let’s create an empty database. We will again call it
og so that Drupal's
settings.php doesn't have to be changed:
CREATE DATABASE og;
Now we want to setup the same user and password for the database as we had on the old server. In our example we will call the user
ogu. Be sure to replace
'password' with your password. The
'' symbols must be included.
CREATE USER 'ogu'@'localhost' IDENTIFIED BY 'password';
At this point
ogu has no permissions to do anything. Let's fix that:
GRANT ALL PRIVILEGES ON * . * TO 'ogu'@'localhost';
For our changes to take effect, we run:
That's it for now.
3.4: Import database
From the directory containing the gzipped database, we can run this combined command:
gunzip < /var/www/ogdb.sql.gz | mysql -u root -p og
We just unzipped and imported all tables and rows into the empty database called
og which we created before.
Now visit your site and you should come to the landing page.
4: Setup Apache
By default, Ubuntu’s Apache server ignores any
.htaccess files which are in a web directory’s root and subfolders.
This results in being able to see the front page of your Drupal site, but coming no further than that. Trying to log in or access any other page may result in either a white screen or a server connection error.
We need to activate
sudo a2enmod rewrite
This will activate the module or alert you that the module is already in effect
4.2: Allow changes from
Open the default Apache configuration:
sudo vi /etc/apache2/sites-enabled/000-default.conf
Inside that file, you will find the
<VirtualHost *:80> block on line 1. Inside of that block, add the following block:
Options Indexes FollowSymLinks MultiViews
allow from all
Your file should now match the following. Make sure that all blocks are properly indented.
To put our changes into effect, restart Apache.
sudo service apache2 restart
Your Drupal site should now let you further in.
5: Modifying the PHP Configuration
The Drupal Status page shows us a the PHP memory limit. To see other server variables, click on more information in the PHP row; this will take us to the
Under “Core” we can see many of the variables we could change. We will modify some of the common ones now.
Rather that edit the main configuration file, we will create our own
.ini file for overriding PHP's default settings.
To see where to put this, look at the row “Scan this dir for additional .ini files”. In my case it’s
/etc/php/5.6/apache2/conf.d. That is where we will create our custom
sudo vi /etc/php/5.6/apache2/conf.d/10-custom.ini
Add your overrides to the file. Mine are as follows:
memory_limit = 512M
max_execution_time = 60
post_max_size = 100M
upload_max_filesize = 100M
Restart the web server to enable the changes:
sudo service apache2 restart