Showing posts with label rsync. Show all posts
Showing posts with label rsync. Show all posts

Thursday, January 16, 2014

Homemade Dropbox with Raspberry Pi and BTSync

Clone Dropbox with a Raspberry Pi and BTSync

clip_image001

After constantly hitting my Dropbox space limit, I decided to build my own distributed backup tool. What I ended up with was an external hard drive with a dedicated Raspberry Pi that keeps in sync with my laptop over the internet using BitTorrent Sync. This new BTSync folder fully replaced my Dropbox folder, and allowed me to streamline my large media backups. I've explained every step of the build below.

Recommended Hardware

These are the items you'll need if you want to duplicate what I've built. If you're building more than 1 node, I highly recommend you buy different brand external hard drives (eg. 1 Western Digital, 1 Seagate, etc). Even different models should be sufficient. If it turns out one goes bad after a year, chances are the second won't die as well.

Install Raspbian

Grab the latest version of NOOBS (New Out of Box Software). NOOBS makes it easy to get the Raspbian OS up and running on your Raspberry Pi, along with setting some basic config options. Once you have it downloaded, copy the contents of the zip onto a freshly formatted SD card (FAT filesystem).

Once you boot up your Raspberry Pi with this SD card and install Raspbian, you'll be given a few more options. These are the settings I usually change, but you should also look around yourself to see what's available.

  • Enable SSH
  • Set the overclocking level to mild
  • Configure a unique hostname

For more detailed setup instructions, check out the installation readme included in the downloaded zip archive.

Fix the Keyboard Layout

If you're using a USB keyboard, you may notice that some of the characters aren't being entered correctly. To switch your keyboard layout from the default of English (UK) to English (US), you can follow the simple instructions after running this command.

sudo dpkg-reconfigure keyboard-configuration

Connect to WiFi

Assuming you've turned on your Raspberry Pi with the wifi dongle inserted, you can move onto configuring the wifi connection. You may want to give it a fixed IP address to make connecting to it from another machine easier. You'll find it is much quicker to SSH into the device rather than hook up a keyboard and monitor every time you want to tweak something.

Connect the External Drive

I haven't had any issues with disks formatted using ext3 or ext4, so using one of those for your external disk is recommended. You can use sudo fdisk -l to find the path of the disk (probably /dev/sda1), which you'll need for mounting. Here's how to mount it. Don't forget to change ext4 below to whatever you used.

sudo mkdir /media/external_disk

sudo mount -t ext4 /dev/sda1 /media/external_disk

Once you verify that works and you can access your files on the disk (if any), you should be able to add the disk to /etc/fstab by adding a new line like this

/dev/sda1 /media/external_disk ext4 defaults 0 0

Now when you boot your Raspberry Pi, the external drive should automatically mount.

Install BTSync

Finally you'll want to download and install BTSync. Be sure to also follow the instructions to make BTSync start on startup too, so you don't need to manually start it every time. Once it's installed and running, you should be able to configure it from any machine by pointing the browser to the Raspberry Pi's IP and port 8888 (eg http://10.0.0.12:8888). It is a good idea to go into the options and set a password for this page.

Lots of Data

The reason I started this project in the first place was because I had over 1TB of pictures and videos I wanted to keep synced across 2 hard drives in 2 different cities. While creating two nodes has done the job, I am still working on the best way to access the data without disconnecting the drive from the Raspberry Pi every time I want to add/remove something. I think my next step will be to run a samba server on each device as well, so I can treat them as network drives and access everything. FTP is also an option. What are your thoughts?

Taken From: http://reustle.io/blog/btsync-pi

Friday, June 12, 2009

Backup Files With Rsync and Grsync

There are, of course, numerous backup solutions you can use, from the simple and free to the complex and expensive, as well as everything in between. The technology behind most backup systems, however, tends to be much more limited. Using classic tools, such as tar and gzip, to back up and compress is still very common under the surface of much more complex tools. This is true even when using network resources. In the end, you are backing up from one machine to another. Many people I know, including those with small businesses, do this for their regular backups. Machine A backs to machine B, which backs to C, which backs to A. The machines, and their drives, are all part of a network. Hey, instant cloud, and you probably didn't know you had one.

This is where rsync, another popular backup tool, shows its worth. As the name implies, rsyncs keep a backup copy of your data, in sync with the original. It can do it locally, from one physical drive to another, or across your network. Because only those files that have been modified are transferred, the process can be very quick. You can do this with single files, whole directories and subdirectories, while maintaining file ownership and permissions, links, symbolic links and so on. rsync has its own transport, or you can use OpenSSH to secure the transfer, and (of course) there are some great front-end, graphical tools to make the process a little slicker.

You can find rsync at rsync.samba.org, but you probably don't even have to look that far. Many distributions load it when you install your system. If not, check your installation disks or simply pick it up from your distribution's repositories. Before I explain how to rsync your data to your own personal cloud, let me show you how easy it is to create a synchronized backup of your data from one directory to another (or one drive to another):

rsync -av important_stuff/ is_backup

In the above example, rsync copies everything in the directory important_stuff into another directory (or folder) called is_backup. Most of you will have figured out that the -v means verbose copy. The -a option hides some amount of complexity in that it is the same as using the -rlptgoD flags. In order, this means that rsync should do a recursive copy; copy symbolic links; preserve permissions, modification times and group and owner information; and, with the final D, copy special files (device and block). When you press Enter, files go scrolling by, after which you see something like this:

sending incremental file list
./
CookingJul08.tgz
CookingJul2008_albums.odt
CookingJul2008_albums.txt
igal_page.png
montage.png
shalbum.png
zenphoto_comment.png
zenphoto_go.png
zenphoto_login.png
zenphoto_makepass.png
zenphoto_setup.png
zenphoto_theming_comment.png
zenphoto_upload_photos.png
zenphoto_view_album.png
. . . .

sent 46059880 bytes received 2753 bytes 6141684.40 bytes/sec
total size is 46044132 speedup is 1.00

One other thing that rsync should be able to do in order to be completely useful is delete files. If you are mirroring files and directories, it stands to reason that you want the mirror to represent exactly what is on the original. If files have been deleted, you want them deleted on the backup server as well. This is where the --delete parameter comes into play. Using the earlier example, let's delete that tgz file from the original, then relaunch the command:

$ rsync -av --delete important_stuff/ is_backup
sending incremental file list
./
deleting CookingJul08.tgz

sent 4164 bytes received 25 bytes 8378.00 bytes/sec
total size is 41911050 speedup is 10005.03

From here on, both directories will always be in sync. When doing network backups, this magic synchronization of files and directories is done using a client and server setup. At least one machine must play the role of server (although nothing is stopping you from running an rsync dæmon on every one of your machines). The server gets its information about who can access what from a configuration file called rsyncd.conf. You'll find that it probably lives in the /etc directory. The following partial listing is from one of my rsync servers:

hosts allow = 192.168.1.0/24
use chroot = no
max connections = 10
log file = /var/log/rsyncd.log
gid = nogroup
uid = nobody

[marcel]
path = /media/bigdrive/backups/marcel
read only = no
comment = Marcel's files
[francois]
path = /media/bigdrive/backups/francois
read only = no
comment = Files for the waiter

This configuration file is quite simple once you get the hang of it. Backup areas are identified by a name in square brackets (marcel, website, francois and so on). The chief bits of information there include the path to the disk area and some kind of comment. Notice that I specified read only = no, but I could just as easily have added that to the top section (the one without a name in square brackets). That's the global section. Anything put up there applies to all other sections, but it can be overridden. Pay particular attention to the gid and uid values; these are the group ID and user ID to which the file transfer takes place. The default is nobody, but you need to make sure that is correct for your system. One of my servers does not have a nobody group, but has a nogroup group instead.

The hosts allow section identifies my local subnet as being the only set of addresses from which transfers can take place. The log file line identifies a file to log information from the dæmon. You also can specify a maximum number of connections, specific users who are allowed to transfer files (auth users) and a whole lot more. Run man rsyncd.conf for the full details. When your configuration is set, you can launch the rsync dæmon, which, interestingly enough, is exactly the same program as the rsync command itself. Just do the following:

rsync --daemon

That's it. Now, it's time to put this setup to use. You might want to test your rsync connection by issuing the command:

rsync remote_host::

Note the double colon at the end of the server's name. The result should be something like this, assuming a server called thevault:

$ rsync thevault::
website All our websites
francois Files for the waiter
marcel Backup area for Marcel

Now, pretend I am on the server where my Web site files live. Using the following command, I can launch rsync to back up this entire area:

rsync -av /var/www thevault::website/

building file list ...

The format of the rsync command is rsync options source destination, which means I also could start the command from thevault, assuming my Web site machine also was running an rsync dæmon. The result would look more like this:

rsync -av localbackupdir websitemachine.dom::websites

All this work at the command line is great, but there are some tools for making the process easier, particularly if you will be creating a number of rsync backups or if you want to get into more complex requirements, such as scheduled backups. A friendly graphical front end on your desktop also may be a greater incentive to perform regular backups or take a quick backup when you've added important data and a “right now” backup is desirable. The first tool I want to show you is Piero Orsoni's grsync (Figure 1).

Figure 1. grsync provides an easy-to-use interface with every rsync option you could want.

While providing a great front end to rsync, grsync also works as a teaching tool for the command-line version of the program, or at least it helps as a memory aid. Almost any command-line option available to rsync is covered in one of these three tabs: Basic options, Advanced options and Extra options. What makes it a learning tool is that if you pause over any of those check boxes with your mouse, a tooltip appears showing the command-line option with a brief description of its function.

To start, click the Add button next to the session drop-down dialog and enter a name for your backup. You can define many different rsync backups here, and then launch them again at a later time. Clicking the Browse button brings up the standard Gtk2 file browser window from which you can select your local and destination folders. Unfortunately, you can't browse remote systems, but if you've already set up an rsync server, have no fear. You can enter it manually in the format I showed you earlier (for example, thevault::marcel/). When you are happy with the various options, click Execute. If you only think you are happy, click the Simulation button. (Chef Marcel loves a program with a sense of humor.) When you do click Execute, the program switches to a progress window (Figure 2), so you can see where you are in the process.

Figure 2. Once your grsync backup begins, it switches to a progress report view.

The next item on our rsync menu is Magnus Loef's GAdmin-Rsync. GAdmin-Rsync makes every aspect of creating an rsync backup a matter of filling in the blanks. What's more, the program creates backups using SSH by default, which means you can set up rsync backups to any machine to which you have secure shell access. This also means you don't actually need to have an rsync dæmon running on the remote machine if you have SSH access. Let me show you how it works.

When you start the program for the first time, you'll be asked for a name to give your new backup (Figure 3). You could back up the entire system or select specific folders of filesystems. Choose a name that makes sense to you based on what you want to back up. Enter a name, then click Apply to continue.

Figure 3. GAdmin-Rsync lets you define numerous backup configurations, each with its own identifier.

As you saw when we did this at the command line, rsync backups can be local, to a remote system or from a remote system. The next window looks for that very information (Figure 4). By default, local backup is checked. To back up to a remote server, select Local to remote backup. Because you can swap source and destination easily when using rsync, there's that third option. I routinely use a remote to local backup for my Web sites and remote systems. Click Forward to continue.

Figure 4. Your next step is to define the location of the backup.

Assuming you chose to back up to your cloud, your next step is to enter the server information (Figure 5). This includes the backup path on your networked server as well as your SSH key type and length. When you have entered this information, click Forward.

Figure 5. For remote backups, GAdmin-Rsync uses SSH/SCP for secure transfers.

Now you're ready to start the rsync backup. Click the Backup Progress tab to watch all the action.

What is nice about this program is that you can (as with grsync) store a number of backup definitions, so you can choose to back up your documents, music or digital photographs when it suits you. GAdmin-Rsync goes further though. If you take a look down at the bottom of the window on the Backup settings tab, you'll notice the words “Schedule this backup to run at specific days via cron” and a check box (Figure 6). Check the box, then scroll down to choose the days you want the backup to run. A little further down, you can specify the time as well.

Figure 6. GAdmin-Rsync also provides an easy way to schedule your backups with cron.

Well, mes amis, closing time has caught up to us, and at least for now, time is one thing we can't back up. Despite the hour, I am quite sure we can convince François to refill our glasses one final time before we go our separate ways. Please, mes amis, raise your glasses and let us all drink to one another's health. A votre santé! Bon appétit!

Marcel Gagné is an award-winning writer living in Waterloo, Ontario. He is the author of the Moving to Linux series of books from Addison-Wesley. Marcel is also a pilot, a past Top-40 disc jockey, writes science fiction and fantasy, and folds a mean Origami T-Rex. He can be reached via e-mail at marcel@marcelgagne.com. You can discover lots of other things (including great Wine links) from his Web sites at www.marcelgagne.com and www.cookingwithlinux.com.


Taken From: Linux Journal Contents #180, April 2009

http://www.linuxjournal.com/article/10409

Wednesday, July 23, 2008

Backups With Rsync Using SSH and Cron

Sincronize Folders With Rsync Using SSH and Cron

Looking for how to set up RSync over SSH so that you can run it in a cron job, or without entering a password?

It's actually very simple. Just follow these few steps:


Step 1
As the user you are going to be running rsync as, and on the machine you will be running rsync on, type:

  # ssh-keygen -t rsa

Follow the prompts and use the defaults for the filenames it gives you. Don't enter in a passphrase, otherwise you will still be prompted for a password when trying to connect.

You should then have two new files in path_to_user_home/.ssh, id_rsa and id_rsa.pub.


Step 2
Open path_to_user_home/.ssh/id_rsa.pub and copy the text to the end of path_to_user_home/.ssh/authorized_keys file on the host you will be connecting to as the user you will be logging in as.

ex:in bash you can do it like this:
cat id_dsa.pub >> .ssh/authorized_keys

Note: if /.ssh/ or authorized_keys dont exist create them, this hapened to me in cygwin,
where i had to create .ssh/ and inside it i created the authorized_keys


Step 3
Now try it out. Try ssh'ing from the host you created the id_rsa* files on to the one you added a text to the end of the authorized_keys file. You won't be prompted for a password any more.


Step 4
Now you can use, cron (see Configuring a Cron Task below) to schedule rsync tasks using ssh, because you don't need to prompt the password



Configuring a Cron Task

The main configuration file for cron, /etc/crontab, contains the following lines:

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/


# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

The first four lines are variables used to configure the environment in which the cron tasks are run. The value of the SHELL variable tells the system which shell environment to use (in this example the bash shell), and the PATH variable defines the path used to execute commands. The output of the cron tasks are emailed to the username defined with the MAILTO variable. If the MAILTO variable is defined as an empty string (MAILTO=""), email will not be sent. The HOME variable can be used to set the home directory to use when executing commands or scripts.

Each line in the /etc/crontab file has the format:

    *minute   *hour    *day    *month    *dayofweek   *command


minute — any integer from 0 to 59
hour — any integer from 0 to 23
day — any integer from 1 to 31 (must be a valid day if a month is specified)
month — any integer from 1 to 12 (or the short name of the month such as jan, feb, and so on)
dayofweek — any integer from 0 to 7 where 0 or 7 represents Sunday (or the short name of the week such as sun, mon, and so on)
command — the command to execute. The command can either be a command such as ls /proc >> /tmp/proc or the commandcustom script that you wrote.

For any of the above values, an asterisk (*) can be used to specify all valid values. For example, an asterisk for the month value means execute the command every month within the constraints of the other values.

A hyphen (-) between integers specifies a range of integers. For example, 1-4 means the integers 1, 2, 3, and 4.

A list of values separated by commas (,) specifies a list. For example, 3, 4, 6, 8 indicates those four specific integers.

The forward slash (/) can be used to specify step values. The value of an integer can be skipped within a range by following the range with /. For example, 0-59/2 can be used to define every other minute in the minute field. Step values can also be used with an asterisk. For instance, the value */3 can be used in the month field to run the task every third month.

Any lines that begin with a hash mark (#) are comments and are not processed.


crontab
---------------------------------------------------------------

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# run custom script the first day of every month at 4:10AM
10 4 1 * * /




your_scripts_dir



/backup.sh


# run-parts
01 * * * * root run-parts /etc/cron.hourly
31 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly










backup.sh
---------------------------------------------------------------

echo "+================================+"  >> /root/.rsync.log
echo "Syncrhonization Attempt Started At:" >> /root/.rsync.log
date >> /your_log_dir/.rsync.log

rsync --delete -avz "/source_dir/"  -e ssh username@remote_machine_ip_or_dns_name:/destination_dir

echo "---------------------------------" >> /root/.rsync.log
echo "
Syncrhonization Attempt Ended At" >> /root/.rsync.log



date >> /root/.rsync.log


As you can see from the /etc/crontab file, it uses the run-parts script to execute the scripts in the /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, and /etc/cron.monthly files on an hourly, daily, weekly, or monthly basis respectively. The files in these directory should be shell scripts.

If a cron tasks needs to be executed on a schedule other than hourly, daily, weekly, or monthly, it can be added to the /etc/cron.d directory. All files in this directory use the same syntax as /etc/crontab.

The cron daemon checks the etc/crontab file, the etc/cron.d/ directory, and the /var/spool/cron directory every minute for any changes. If any changes are found, they are loaded into memory. Thus, the daemon does not need to be restarted if a crontab file is changed.

Users other than root can configure cron tasks by using the crontab utility. All user-defined crontabs are stored in the /var/spool/cron directory and are executed using the usernames of the users that created them. To create a crontab as a user, login as that user and type the command crontab -e to edit the user's crontab using the editor specified by the VISUAL or EDITOR environment variable. The file uses the same format as /etc/crontab. When the changes to the crontab are saved, the crontab is stored according to username and written to the file /var/spool/cron/username.
Starting and Stopping the Service

To start the cron service, use the command /sbin/service crond start. To stop the service, use the command /sbin/service