10 Practical Rsync Commands and Examples

The man page calls Rsync a fast and versatile remote and local file copying tool. Rsync is a powerful utility baked into many Linux systems and widely used by administrators for backups. Rsync is famous for its ability to send over only the changed portions of the files resulting in extremely fast copy times. You can make a complete backup just once and future backups will only copy the changed bits. Rsync can copy files to and from a local/remote host as well as between 2 locations on a local host. (Rsync does not support copying between 2 remote hosts.)

To use Rsync, you must have shell access to the remote machine (typically SSH) and Rsync installed on both client and server. When connecting to a machine with Rsync you will be prompted for login credentials unless you have SSH keys setup. Alternatively, the Rsync client can connect to any machine running the Rsync daemon. The Rsync daemon is useful when you don’t want to allow user level SSH access to the server.

There are a lot of options for Rsync but most administrators only use a handful of them. Below are the most popular options.


-aArchive mode. Back up recursively and preserve permissions etc.
-vverbose. Increase output to terminal.
-zCompress data before transferring
-rBackup recursively
--progressShow progress bar
--excludeExclude specific files from transfer
--remove-source-filesRemove files from source once data is transferred
--dry-runOutput files to be copied/skipped. Does not actually run.


1.) Sync contents of 2 folders

At the most basic level Rsync can sync the contents of 2 directories. This isn’t exactly a backup but allows you to explore the basics of what Rsync has to offer.

Here we use Rsync with no options to sync the contents of 2 folders:

rsync /path/to/folder1/ /path/to/folder2/

Pay careful attention to the leading slashes at the end of your file paths. A slash at the end means you want to sync only the contents of the directory. Leaving off the slash means you want to sync the directory as well.

2.) Sync entire contents of 2 directories including sub directories

With no options specified Rsync will only copy files in a directory. By default it does not copy sub directories. The -r switch tells Rsync to copy everything including all directories and sub directories.

rsync -r /path/to/folder1/ /path/to/folder2/


3.) Copy everything in archive mode

The -a option is the most popular option to use with Rsync. This option is actually many options strung together. -a is a full archive backup and backs up everything including time stamps, permissions, and modifications. -a is the same as using the options -rlptgoD.

rsync -a /path/to/folder1/ /path/to/folder2/


4.) Sync a remote folder to a local folder

Rsyncs true power comes from its ability to securely sync a remote folder to a local folder. Useful for backing up a web server. Here we sync a remote folder called folder1 to a local directory folder2:

rsync -a user@ /var/www/folder2


5.) Sync a local folder with a remote folder and compress before sending

Rsync can compress data before it transfers over the network. This is useful for slow networks but should be avoided if CPU power is limited. Compression is executed with the -z option.

rsync -az /var/www/folder1 user@


6.) Do a dry run first

Rsync can tell you what will be copied without actually copying any data. This can provide a visual overview of what is missing in the destination as well as how much data will be transferred. It can also save your bacon especially when using the –delete option! Here we also include the -v (verbose) so we can see the output in the terminal.

rsync -av --dry-run /var/www/folder1 user@


7.) Delete files in destination that are not in the source

Sometimes you want to completely mirror a directory and remove extra files. The –delete option tells Rsync to delete everything in the destination that is not in the source. Be careful with this one! If you are accidentally in an empty directory you can completely wipe out your destination files.

rsync -av --delete /var/www/folder1 user@


8.) Delete files from source once synchronized

When you no longer need the source files.

rsync --remove-source-files -avz /var/www/folder1 user@


9.) Exclude specific files

In this example we exclude every document with a .docx file extension

rsync -avz --exclude '*.docx' user@ /var/www/folder1/


10.) Show a progress bar

For those who gain deep satisfaction from watching progress bars tick by the screen. Here we use the –progress option to create a nice little progress report of each transfer in the terminal.

rsync -avz --progress /var/www/folder1 user@

8 Practical SCP Commands and Examples

SCP stands for secure copy and makes safe file transfers easy on both Windows and Linux. Linux users can take advantage of the built in utility while Windows users can use free software like WinSCP. SCP uses the SSH protocol to encrypt its data transmissions and requires SSH access. Data transfers can take the form of local to remote, remote to local, or remote to remote machines. Simply provide the SSH credentials and you’re good to go. Similar to SSH, if you don’t have the appropriate SSH keys you will be prompted for a password to login to the remote machine(s).


-PSpecify SSH port
-pPreserve time stamps
-qQuiet mode. Do not show progress bar.
-rRecursively copy entire directory
-SSpecify program to be used for encrypted connection.
-TDisable file name checking.
-vVerbose mode. Print debugging information.

scp man page

Here are a few practical SCP examples to start transferring files immediately.

1.) Copy file from a local machine to a remote machine

Here we supply SCP with the local file we want copied and then specify the remote machine and directory. The following SCP command transfers the local file backup.tar.gz to a remote directory on remotemachine.com. Replace remotemachine.com with the domain or IP address of your remote host:

scp /home/user/backup.tar.gz user@remotemachine.com:/var/www/backups

2.) Copy file from a remote machine to a local machine

This is basically the same command as example 1 except reversed:

scp user@remotemachine.com:/var/www/backups/backup.tar.gz /home/user

3.) Copy file between 2 remote machines

Here we copy a file from a remote machine to another remote machine. We supply SCP with the addresses of both machines and where we want to put the file:

scp user@ user@

4.) Copy directory from remote machine to local machine

The -r option must be specified when copying directories. Here we copy the contents of the entire /var/www/ directory to our local machine:

scp -r remotemachine.com:/var/www/ /var/www/backup/

5.) Compress files before transferring

SCP can compress files with Gzip before transferring. This can speed up transfers on networks with very slow connections but can slow things down on faster connections. Extra CPU power must be used for the compression.

Here we use the -C option to transfer a file with compression enabled:

scp -C /var/www/novel.txt user@

6.) Copy multiple local files to remote machine

You can specify multiple files to be copied:

scp /path/to/file1 /path/to/file2 user@

Alternatively use the following format to copy multiple files with the same extension:

scp {file1,file2,file3}.txt user@

7.) Copy multiple directories

The following command copies multiple directories in a folder. Sometimes you don’t want the entire directory, just a few folders in that directory. Here we use the -r option once again:

scp -r user@\{dir1,dir2,dir3\} /local/folder/

8.) Specify SSH port

Specify the port of the remote machine if SSH is not running on the standard port 22:

scp -P 2244 user@ /path/to/local/folder/

Installing Lets Encrypt SSL On Ubuntu and Apache (Easy)

Lets encrypt is hands down the easiest way to secure your web server communications with SSL. On Ubuntu the process is simple and the configuration automagically takes care of all the http to https redirects. I’ve used Letsencrypt to secure many WordPress installations running on various Apache based VPS.

1.) add the Certbot repository to the Ubuntu package system:

sudo add-apt-repository ppa:certbot/certbot

2.) Install the package:

sudo apt install python-certbot-apache

3.) Configure an SSL cert and associate it with your domain:

sudo certbot --apache -d yourdomain.com

When asked if you want Certbot to handle the redirects press 2:

lets encrypt https redirect


lets encrypt success


Certbot verifies your domain through the existence of an Apache virtual host. If you do not have a virtual host configuration file you will need to set one up.

6 Reasons Your cron Job is Not Running


cron can be a real S.O.B. to setup if you’ve never scheduled a job before. The utility is downright nitpicky at times. Not to fear. If your cron job is not running, here are the top 6 most common hang ups you might be snagging on.

1.) Wrong environment

Your user account operates under a specific environment where you have a direct path to the programs and utilities you need. cron operates under a limited path and does not always have access to the same programs. Your PATH is one such environment variable that tells the shell where to look for executable programs. If you’re trying to use a program that isn’t in your path, the shell will return error. In the case of cron, your job will simply not run.

You can see if this is the case by comparing the cron environment to your user environment. Plug this small line of text into your crontab and take note of cron’s output in /tmp/path.txt

* * * * * env > /tmp/path.txt

Compare the contents of path.txt with your current environment and you will see a big difference in where cron searches for executables. Run the following command to see your current path.

echo $PATH

Solution – There are two things you can do in this case. The first involves using absolute paths in your script. This ensures cron has a complete path to the program you’re running:

/usr/app/command -x take-over-the-world-pinky

Alternatively, you can set your path at the top of your script like so:


This will give cron direct access to your program. Either way, you should be good to go.

2.) Your scripts aren’t owned by root

From the man page:


If you’re placing scripts inside one of the /etc/cron.* directories, the scripts must be owned by root. If root does not own the script then cron will simply skip over it entirely. Many users choose to place scripts inside of these folders to bypass the finicky requirements of their own crontab. Rightly so, but even here you will find cron to be relentless with it’s requirements. Make sure your scripts are owned by root so things go smoothly.

3.) Your script names aren’t formatted properly

From the man page:

Once again, we see cron putting his foot down until the people around him fall in line with his unique perspective on reality. Your script cannot contain any special characters when placed into one of the /etc/cron.* directories. A common practice is appending your script with the .sh file extension. This is a no-no for cron. As you know, Linux does not require a file extension and your script will run just fine without one. Do what cron says and you will be a happy admin.

4.) Your cron script is not executable

An obvious one to some. Not so obvious to others. Your cron script must have executable permissions in order for cron to run it. Use the following command to make your script executable if it isn’t.

chmod +x /path/to/script

Executable scripts make cron very happy.

5.) Incorrect permissions

Permissions are a very common problem especially for commands placed in crontab. crontab runs under the permissions of the crontab user. If you don’t have proper permissions under your user, cron is not going to have the proper permissions either. Always run your script or command prior to scheduling them with cron. If your commands don’t run or error out with access denied errors, you know you need to make adjustments. If your script or command absolutely requires root permissions, then create a crontab as the root user of your system.

6.) cron daemon not running

The last and most insidious reason why cron is not working. I’ve racked my brain for hours trying to figure out why a cron script wasn’t working only to find out the daemon itself wasn’t even running. You can verify whether or not cron is running in a number of ways.

pgrep cron

cron is running if you see a number. cron is not running if you don’t.


service cron status

Easy way on Debian systems to check the status of cron.



These are 6 of the most common reasons why your cron jobs are not running. Run through this list next time cron refuses to do what you tell him to. Eventually, cron will start to see things your way and will do as he’s told.



Linux cron job Tutorial


Cron is a Linux utility that lets you automate tasks on a schedule of your choosing. A Linux cron job is the perfect way to automate backups or other repetitive tasks. Cron comes with all versions of Linux and functions mostly the same across different distributions.

How cron works

Cron works by reading through a number of configurable text files and then reading commands into memory. Every minute the cron daemon crawls a special spool folder on the file system that contains a crontab for each user on the system. When cron runs across a crontab with a scheduled job it loads the job into memory.

Types of Linux cron jobs

There are 2 types of cron jobs. System wide jobs are cron jobs configured through /etc/cron and the directories /etc/cron.hourly /etc/cron.daily /etc/cron.weekly and /etc/cron.monthly These jobs are ran under the root account and have full access to the system. User jobs are cron jobs scheduled by standard user accounts and configured through crontabs. For security reasons it is recommended to schedule your jobs through your own crontab unless the task must be executed as root.

How to schedule a cron job

There are 2 ways to schedule a Linux cron job. The first is to simply drop a shell script into any of the directories mentioned below:

/etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly

Shell scripts in these directories must be executable, owned by root, and adhere to a specific set of filename restrictions. From the man page:

As described above, the files under these directories have to be pass
some sanity checks including the following: be executable, be owned by
root, not be writable by group or other and, if symlinks, point to
files owned by root. Additionally, the file names must conform to the
filename requirements of run-parts: they must be entirely made up of
letters, digits and can only contain the special signs underscores
(‘_’) and hyphens (‘-‘).

The second way to schedule a cron job (and the preferred way) is to edit your users crontab:

crontab -e

This opens up the crontab for the currently logged in user. Here, all cron jobs scheduled will be executed under the user who created it. You will see a number of lines with the proper crontab format at the bottom. This is where you schedule your job. You can drop in a direct command to run or give the path of an executable shell script. Here are a few examples:

Note: cron uses a 24 hour clock ie military time.

Schedule a job to run once a day at 2:00am:

00 2 * * * /path/to/command

Schedule a job to run at the 1st of the month:

* * 1 * * /path/to/script

Schedule a job to wish the system a merry christmas:

* * 25 12 * echo “Merry Christmas Tux”

Clear the temp files once a week on Friday after everyone has left work:

01 17 * * 5 rm /temp/*

Make the appropriate edits and then save the file. Don’t worry about reloading or restarting cron. The daemon automatically checks for changes every minute.


Cron is drop dead simple once you understand the format. However, there are a few things that can hang up a cron job if you aren’t careful. Here are a few:

1.) Your scripts aren’t executable

All of your scripts must be executable in order for cron to run them. Go back and make sure all of your cron scripts have the +x permission configured.

2.) Your scripts aren’t owned by root

If you’re dropping your scripts into /etc/cron.hourly or any other cron folder, they must be owned by root or cron won’t run them. Make sure your scripts are owned by root and the proper permissions are set.

3.) Your scripts contain characters that aren’t allowed by cron

Similar to point number 2, your cron scripts won’t run in the /etc/cron.* folders unless they conform to a specific format. It’s usually a period that trips people up. Remove the period and your scripts will magically start running. Refer to the quoted man page above for more information.

4.) Wrong format

It’s easy to make a mistake in your crontab. You might think you’re running a script at one time but the format you gave cron doesn’t match up. Go back and make sure you have a clear grasp of the cron format and understand how to implement it into your crontab.


cron is a picky S.O.B but performs well once you can get him running. The nice thing is, once you have cron configured it will run like a well oiled machine for the rest of your days. Let me know what you think about cron in the comments below.




Crontab Format Explained


Cron is a built in Linux utility that allows you to schedule jobs called cron jobs. You can schedule cron jobs to run hourly, daily, weekly, monthly, yearly or any sort of variation in between. Cron is configured through a specialized text interface called the crontab. The problem is that the Crontab format is a little confusing until you become acclimated to scheduling out jobs. Let’s take a look:

* * * * * /path/to command

Each * represents a time slot. Using the table below you can see that each * represents varying measurements of time:

MinuteHourDay of the month (1-31)Month (1-12)Day of the week (0 - 6 where 0 = Sunday)

crontab format examples

Note: cron uses a 24 hour clock ie military time.

Schedule a job to run once a day at 2:00am:

00 2 * * * /path/to/command

Schedule a job to run at the 1st of the month:

* * 1 * * /path/to/command

Schedule a job to wish the system a merry christmas:

* * 25 12 * echo “Merry Christmas Tux”

Clear the temp files once a week on Friday after everyone has left work:

01 17 * * 5 rm /temp/*


Is it all coming together now? Practice some examples of your own to really get the hang of it. Pretty soon you will be using anything as an excuse to bust out your crontab for a quick scheduling. Let me know in the comments if you need help.


Samba File Sharing Configuration and Tutorial


Samba file sharing allows a competent system administrator to configure a Windows-like network share on a Linux system. These shares are accessible by Windows computers and other SMB clients. Samba is software that makes it easy to exchange data with Windows operating systems.

What is Samba?

Samba is free software for Linux that implements SMB like functionality into the system. SMB is the dominant file sharing protocol used on Windows systems. By recreating this functionality, Linux systems can integrate into a Windows environment and function as both a client and/or a server. The software includes a dozen core services to make this possible.

Samba file sharing HOWTO

In this samba file sharing tutorial I will show you how to setup a Samba share with basic user access controls. You will learn to share a folder with read/write access and grant permissions to select users on the network. A mapped network drive on the Windows machine will serve as easy access to the Samba share.

This is a basic process that involves installing the Samba file sharing software and making a few configuration changes to the configuration file.

Installing Samba

Samba may or may not be installed on your system. Here are a few ways to install the software on various Linux distributions.


apt-get install samba


yum install samba samba-client samba-common


pacman -S samba

By default, the Samba configuration file is located at /etc/samba/smb.conf and comes extremely bloated. I always delete the contents and start fresh with only the configuration directives I require. If this scares you, make a backup of smb.conf first:

cp /etc/samba/smb.conf /etc/samba/smb.bak

The following configuration file will grant your username full access to your home directory on your Linux box. Copy and paste the contents below straight into the smb.conf configuration file. Be sure to substitute your own parameters on each line.


# Copy this into your /etc/samba/smb.conf configuration file

workgroup = WORKGROUP
netbios name = SAMBA
security = User

path = /home/user/
valid users = username
read only = no
create mask = 0777

There are a few parameters here worth mentioning.

workgroup should be the same name as the workgroup your Windows machine is on. The default Windows workgroup is called WORKGROUP, conveniently enough. You can verify this by going into your system properties.

netbios name is the name your Linux box will present to the network. Essentially, this is the name that will show up when you browse the network for connected hosts.

security is a setting used to determine how a particular share is accessed. In this case, we only want to grant permission to users that exist on the Linux system.

[data] is the name we are specifying for the share.

path is the absolute path of the folder we want to share to the network

valid users specifies what users should have access to this share. All other users not on this list will be denied access.

read only = no makes this share writeable by the users.

create mask sets the default permissions for this share. In this case, we grant full permissions to the owner of the files while completely denying permission to everyone else.

That’s all there is to it. Save the configuration file and then reload the Samba configuration:

service samba reload

The last thing we need to do is create a special Samba password for your user:

smbpasswd -a user

Your share should now be accessible from any Windows machine on the network. You can access the share by specifying the UNC or by browsing the network via Windows Explorer. Double clicking the share will prompt for a username and password. Plug in the credentials of your Linux user and click OK.


Once logged in you will see the share you set up in the Samba configuration:




Problems with Samba are usually caused by incorrect configuration settings, permissions, or service related issues. A good starting point if you’re having problems connecting to your server is to check the Samba service status:

service samba status

Is the service running? If not, you’ll have to find out why.

Next, make sure there are no typos in your Samba configuration file. A single typo can throw off the whole server. Comb through your /etc/samba/smb.conf and make sure all your directives are correct.

Access denied problems can crop up if your permissions aren’t set correctly or you failed to set an smbpasswd for your Linux user account. Make sure the account you specify in the Samba configuration is active on the system and that you created an SMB password for the user. Re read the sections above for instructions.


Samba file sharing makes it easy to exchange data in a Windows dominant environment. You can see how easy this was to quickly get a file server up and running. Once again, Linux proves itself to be a very capable server operating system. Best of all, the software is free! This tutorial covered a very small aspect of Samba. If you’d like to learn more about Samba and its full capabilities, check out the official documentation or run through the man page.


Ultimate List of Beginner Linux Commands With Examples


New to Linux? Maybe you’re looking to switch to Linux full time or learning how to operate a VPS. Below I have compiled a list of beginner Linux commands with examples to get you started. These commands will lay the foundation required to use the Linux system in more advanced ways. Let’s get started.


Print working directory. This command lists where you are in the file system. The top of the Linux file system starts with / and then branches out like a tree from there. The pwd command is useful when you have no idea where you are on the system.

linux commands with examples


Change directories. The same as clicking through your folders on a Mac or Windows machine. This command works with both relative and absolute paths.



Lists files in a directory. Exactly the same as opening up a folder on Mac or Windows and seeing all the files. By itself, the command will list all the files in the current directory. You can also list the contents of a relative or absolute path.


Notable Parameters Description
-aLists all files including hidden ones
-lLong listing. Includes additional info like permissions and timestamps


You are familiar with the traditional way of copying files on a GUI (graphical user interface.) This typically involves dragging files from one window to another or executing a right click copy/paste. Using the cp command you can execute the same process a lot faster. Here we copy the “file1” file from the current directory into the /home/2cf/documents directory.


Notable Parameters Description
-rCopy in recursive mode (copy both files AND directories)


Creates a folder in the current or supplied directory


Notable Parameters Description
-pCreate the parent directories if they don't exist


Removes a file when used by itself and deletes directories when used with the -r switch. Be careful with this one. You don’t want to accidentally delete any important files!


Notable Parameters Description
-rRemove directory


Move or rename files. In the example below, we rename “documents” to “mydocuments”



determines the file type of a file. Very useful for identifying cryptic files on a Linux system. As you explore Linux you will come across files of mysterious types. Use the file command to expand your knowledge of these files.



concatenates files and displays their output. In other words, the cat command reads the contents of a file right onto your terminal. This is a quick way to read a file without actually opening it in an editor.



Clears the terminal screen. All the output on the terminal can become overwhelming and confusing. Use the clear command to wipe the slate clean! Note that clear doesn’t actually delete anything. It simply clears the output generated by any commands you have ran.



Prints the user currently logged in to the system. Not sure who’s account you are using? You can always verify the current operator with the whoami command.



man is an interface to the Linux manual. The manual contains complete information on every command and utility available on the Linux system. If you are wondering what a certain command does you can read the manual. In the old days when n00bs asked the veterans about a particular command, they were instructed to RTFM – Read the F’n manual! They were, of course, speaking of the man command.



Reboots the system.



Brings the system down. When used without any parameters, the default action is to bring the system down into single user mode (run-level 1) immediately.  This mode logs off any users currently logged into the system and prevents them from logging in. To execute a full system power down, you must use the -h option and specify a time:

shutdown -h now

Time can also be specified with a +n where “n” is the minutes before you want the system to shutdown. Here we tell the system to execute a full power down in 5 minutes.

shutdown -h +5


Becoming familiar with these commands is a great start to learning how to use the Linux system. You now have everything you need to manipulate files, navigate the file system, and do some basic system administration tasks. Best of all, you have the man command. All of these commands have advanced options that I did not cover in this beginners guide. Using man, you can dive deep into the commands that interest you and learn more.


rsync over SSH: backup your data securely


Using rsync over ssh is a secure method to backup your system. SSH encrypts your data over the internet and secures the transmission from hackers and other threats. The good news is that rsync uses the SSH protocol by default. In this tutorial I will show you how to use rsync over SSH and how to conifgure SSH keys for passwordless backups.

rsync over SSH requirements

  • SSH access to server
  • rsync client installed locally

Installing rsync

In most cases rsync will already be installed on your system. If it’s not, it can be easily installed.


sudo apt-get install rsync


sudo yum install rsync

Testing the connection

Test the connection to your server by connecting with SSH:

ssh user@remotehost.com

If all goes well you should be greeted by a password prompt:

Testing rsync

If you can connect with SSH you can connect with rsync over ssh. Test rsync by initiating a dry run backup of your home directory:

rsync -nav user@remotehost:~/ /path/to/local/backup/folder/

With any luck you will see your files and folders fly by the screen. Note that we did not have to use the -e switch. Since rsync uses SSH by default this is not necessary unless you need to specifiy additional connection parameters (non-standard port or SSH key locations.)

Setting up SSH keys

We can setup SSH keys so rsync doesn’t need a password to connect. This is useful for automating your backups with chron while staying completely secure. SSH keys are generated on your local computer and then copied to the remote host. Generate a key pair with the following command:

ssh-keygen -t rsa

Save the keys in the default location or specify another directory:

Enter file in which to save the key (/home/demo/.ssh/id_rsa):

Leave the passphrase blank by hitting enter through the following prompt:

Enter passphrase (empty for no passphrase):

Here is what you should see:

Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
4a:dd:0a:c6:35:4e:3f:ed:27:38:8c:74:44:4d:93:67 user@a
The key's randomart image is:
+--[ RSA 2048]----+
|          .oo.   |
|         .  o.E  |
|        + .  o   |
|     . = = .     |
|      = S = .    |
|     o + = +     |
|      . o + o .  |
|           . o   |
|                 |

While it would be more secure to enter a passphrase, rsync can’t be automated in this way. However, this method is still secure because a hacker would need to obtain your private key to gain access to the server.

Next we copy the public key to the server. Security tip: Never grant your keys to the root account. Always copy your keys to a standard user account. This way if a hacker jacks your private key he would only have limited access to your box.

ssh-copy-id user@remotehost.com

If prompted, type yes to connect and then enter your password to complete the transfer:

The authenticity of host ' (' can't be established.
RSA key fingerprint is b1:2d:33:67:ce:35:4d:5f:f3:a8:cd:c0:c4:48:86:12.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (RSA) to the list of known hosts.
user@'s password: 
Now try logging into the machine, with "ssh 'user@'", and check in:


to make sure we haven't added extra keys that you weren't expecting.

Boom goes the dynamite. You should now be able to run rsync over ssh without a password.