/* if they are here, we dont need to convince them to backup
======System Backups======
The reason so many appreciate "the cloud" today is because of the assurance that their data is safe. It's not safety from the NSA or computer attacks that they appreciate, it's the safety from dying hard drives, because everyone knows that the cloud is redundant, and the cloud is automated. It just backs stuff up, all the time.
Believe it or not, you can and should have this same peace of mind on your own computer system. Networked drives in "the cloud" are not inherently safer from drive crashes than your own system, it's just that they have automated repetitious backup schemes. You can do that, but you do have to set it up.
Unfortunately, there seems to be no "easy" way for humans to enforce backups, so the best backup methodology is one that you actually //do//. In other words, you might find a brilliant way of backing up but if you don't hit the "backup" button on a regular basis, then it's worthless.
The most important thing about backing up your data is finding a backup plan that you actually use.
Make no mistake: you don't have to settle on just one backup scheme. If you want to push all of your artistic work to "the cloud" and back up all of your private data to a local thumbdrive, there's nothing wrong with that, as long as you actually //do it//.
*/
=====Backing Up with Rdiff-Backup=====
**TL;DR** \\
1. [[drives|Format a big drive]] as UDF. \\
2. Install ''rdiff-backup'' \\
3. ''rdiff-backup --exclude-globbing-filename $HOME/.excludes $HOME /path/to/drive'' \\
4. Automate that command with ''cron'' \\
There are several good backup applications aimed at local and network backups. Some are geared toward sys admins managing entire VFX houses, others are geared toward the advanced home user, and still others are aimed at regular, humble, everyday artists like us. No matter the audience, the best solutions can be //automated// so that you don't have to remember to do it, or wait for huge data dumps when you finally do remember to backup. A steady, automated, "always on" backup scheme tends to be the smartest backup plan.
The most straight-forward and flexible backup application available is [[http://rdiff-backup.nongnu.org|rdiff-backup]], available from [[http://slackbuilds.org]]. It has one dependency, ''librsync'', which is also available on slackbuilds.org.
This section assumes that you are interested in backing up your personal data, not the entire system, since the OS is free and can be re-constructed. \\
\\
There is a case for backing up the entire system (quicker recovery in the event of a full system disaster being the main one), and this //can// be done; just replace ''/home/$USER'' in this chapter with ''/'' and run your backups as root. See [[http://rdiff-backup.nongnu.org/docs.html]] for more information on what directories you should exclude when doing a full system backup.
Rdiff-backup is a terminal command only; it has no graphical user interface. If you are not comfortable using the terminal, it's still ok to use rdiff-backup because the point of it is that you don't have to use it much; you automate it. That's what we'll do together here, and once you get through this chapter, you will never have to use rdiff-backup directly again, except to recover data but under those circumstances, you probably won't mind learning a new command or two.
If you still doubt this prescription, you are welcome to try out [[http://slackbuilds.org/result/?search=luckybackup&sv=|LuckBackup]] but be aware that fancy graphical (luckybackup included) are more subject to change than backup commands, which have often been around, basically unchanged, for decades. If longevity is not a concern, feel free to explore different backup options than what Slackermedia recommends.
======Rdiff-backup Plans======
There are a few likely scenarios for backing up:
* [[#bkpsetup|You want to backup up to a big hard drive that is always connected to your computer via a cable.]]
* [[#bkpsetup|You want to backup to a big hard drive that you will connect to your computer (when you happen to think to do it) via a cable.]]
* [[#bkpsetup|You want to back up to a home server or a remote server that you have physical access to.]]
* [[#bkpcloud|You want to back up to a server in a data center somewhere that you do not have physical access to.]]
* [[#bkpcherrypick|You only want to backup a few important files as you generate them.]]
{{anchor:bkpsetup}}
=====Local Backup=====
☛ If you own the drive to which you want to backup, then do these steps before continuing.
☛ If you run your own home server (or you otherwise have physical access to the server acting as your backup destination), then this setup should occur //on the server//, not your local computer.
☛ If you are backing up to a server off site that you have no physical access to, skip this entirely and read the section on [[#bkpcloud|remote backups]].
**1.** Format your hard drive to be used as a backup drive.
If you are intimately familiar with hard drive formats ("file systems") and have your own preferred file system, you may use that, but Slackermedia recommends the UDF file system for your backup drive because it is easy to configure, it handles large drives well, its paths are easy to specify, and it is universal so that no matter what you have available to you, you can get to your data.
Read the section on [[drives#udf]] to learn how to safely create a UDF drive. Give your UDF drive an id of ''safehouse'' (''--vid=safehouse'').
When you format it, give your UDF drive an id of ''safehouse'' (''--vid=safehouse'').
When coming up with a naming scheme for your backups, it's best to use a unique (but //sensible//) term, because the word "backup" gets used so frequently by so many applications. You want to be able to recognise //your// backup, so pick a somewhat unique name for it; look in a thesaurus or use your artistic creativity to think of a word that means "backup" (examples: carbonite, keepsafe, safehouse, vault, bunker, silo, attic, booty, hoard).
Slackermedia uses the naming scheme "safehouse" as the backup location. This avoids confusion over whether we are talking about "backup" **the action** or "backup" **the place**, and so on.
**2.** Add the drive to ''/etc/fstab''.
There are several advantages of doing this; it will make the drive automatically mount if it is attached at boot time, and it also ensures that you have an easy way of finding your backup location no matter when the drive is attached.
First, add a directory for the drive. This will make the drive more integrated with the system (meaning that your computer will not have to create dynamic directories for it in ''/run/media'' as it does for most external drives).
$ su -c 'mkdir /safehouse'
Next, add the drive to the file system table, located at ''/etc/fstab''. Open this file in your favourite text editor with ''kdesu'' and add this line to it (it's ok to copy and paste this exact line; it is **verbatim** what you should add):
LABEL=safehouse /safehouse udf user,rw 0 0
Save the file and reboot to make sure that the drive mounts automatically if connected. Technically, it's not necessary to reboot, but you might as well reboot just to verify that all goes well.
**3.** Perform an initial backup.
The first backup is the largest and slowest backup because it is copying everything over to your backup drive. Subsequent backups will be much much smaller, because it will only copy changes to that base layer.
It is vital that this initial backup is done the exact same way it's going to be done on all future backups, for many reasons, but essentially because you need to get confirmation that everything has been set up correctly //before// you try to automate it. If you do a backup with a drive connected to your computer, and then try to switch to a networked backup, you might do user permissions wrong, or file paths might be inconsistent, or any number of problems, and you won't ever realise it because you'll have automated the process, never knowing that all you have automated is failure.
Do not do that.
Make your first backup the initial test of your backup process. If it fails, refine your process, troubleshoot, and try again. When you get it right, you'll know it, and you'll know exactly what to automate.
The basic command to backup your home directory (where all of your personal data lives):
For a locally attached drive:
$ rdiff-backup --terminal-verbosity 8 --print-statistics \
--exclude-globbing-filelist /home/klaatu/.excludes /home/klaatu/ \
/safehouse/klaatuWork/
You might have exclusions that you don't want to have backed up (for instance, do you ever want your trash bin backed up?). For this, read the section on [[#excludes|exclude]] options.
Or for a server:
$ rdiff-backup --terminal-verbosity 8 --print-statistics \
--exclude-globbing-filelist /home/klaatu/.excludes /home/klaatu/ \
klaatu@10.1.1.11::/safehouse/klaatuWork/
Notice that the server path contains //two// ''::'' between the hostname and the destination path.
This command backs up your entire home directory to the ''/safehouse'' location. Do not bother creating the destination file (in this example's case, the ''/safehouse/klaatuWork'' folder); ''rdiff-backup'' will [attempt] to create that for you and warn you if it cannot write to the drive.
No matter what, your first backup will take a long time, so just let it work.
You have completed the setup phase.
{{anchor:bkplocal}}
=====Backup to a Local Drive=====
If your computer is a workstation (or "desktop" or "tower") then it makes sense to backup your data to a drive that you just leave plugged in to the computer. The advantage is that the backups occur in the background, without any special action required of you. The dis-advantage is that the drive is physically connected to your computer, so if accidentally erase your entire computer and everything connected to it, then you have blown away both your data and the backup copies of your backup data (the likelihood of you devising such a command by accident is extremely rare).
As with //any// local backup, this method also is not fire-, flood-, or Velociraptor-proof. That is, if something catastrophic happens to your house or apartment, then your data is gone and so is your backup.
On the other hand, if you accidentally delete a file an hour before your deadline, you can pull the most recent version off of a drive sitting under your desk and move on with your life.
As always with devising a backup plan, the cost-to-benefit factor is your own to ponder.
The backup scheme for such a setup is simple.
**1.** Verify that the drive has been mounted to ''/safehouse'' as expected:
mount | grep safehouse
If nothing is listed, then the drive has not mounted successfully. Verify that you have labelled it properly with the ''vid'' flag (if using UDF as recommended; if you are using ext{2-4}, try using ''e2label'').
**2.** Change a file or add a new test file, and then run the your backup command again.
$ rdiff-backup -v 8 /home/klaatu/ /safehouse/klaatuWork/
This time, the process is relatively fast, since it has only copied over the changes.
☛ You might have exclusions that you don't want to have backed up (for instance, do you ever want your trash bin backed up?). For this, read the section on [[#excludes|exclude]] options.
☛ Assuming everything is working as expected, [[#automate|automate]] the process and never think about it again.
☛ For information on recovering data //from// a backup, read the section on [[#recovery|restoring files]].
/* +++ + + BACKUP TO LOCAL DRIVE UPON CONNECT + + + + + + + */
{{anchor:bkpconnect}}
=====Backup Upon Connection of a Local Drive=====
If your computer is a laptop, then having a drive that is always connected probably is not realistic. You can, however, create a system such that when you plug in a specific hard drive, your system uses it as a backup drive. This way, all you have to do to initiate a backup is attach your backup drive; you don't even have to necessarily run a command (depending on your preference).
The dis-advantage to this method is that you might forget to attach the drive with any regularity, so your backups may end up being few and far between. Reducing the perceived workload of "it's time to backup" to the simple act of plugging in a portable drive does simplify things, but if you don't attach the drive, then even a simple solution like this does you no good.
As with //any// local backup, this method also is not fire-, flood-, or Storm Trooper-proof. That is, if something catastrophic happens to your house or apartment or planet, then your backup drive is gone. If your laptop is on your person, you do have your original data, so in a way this scheme (because a laptop is inherently portable) enforces the "never keep your originals and your backups in the same place" rule (except when your laptop and the drive //are// in the same place).
On the other hand, if you accidentally delete a file an hour before your deadline, you can pull the most recent version off of a drive sitting under your desk and move on with your life.
As always with devising a backup plan, the cost-to-benefit factor is your own to ponder.
====Easy (the "It's better than nothing" solution)====
You need to identify your backup drive to your system, so that your computer knows to backup to it when it gets plugged in. The easiest way to do this is to lie to your computer and tell it that your backup drive is always attached; any backup attempts made when the drive is //not// attached will fail, while any backup attempt when the drive happens to be attached will succeed. To implement this method, just use the [[#bkplocal|backup to a local drive]] method, and then skip down to the [[#automate|automation]] section.
The danger of using this easy method is that if you have your computer set to backup every 4 hours, for example, and you attach your drive but only leave it attached for 3.75 hours, then you miss a backup cycle. Keep doing that, and you may end up with far fewer backups than expected. It practise, it's better than nothing, and as long as you remember to leave your laptop on and awake overnight with your backup drive attached, you are sure to hit one or two backup cycles (depending on how often you sleep).
{{anchor:udev}}
====udev (the "I spent my weekend with udev" solution)====
The more difficult solution is to use ''udev'', the sub-system in Linux that supplies your computer with "device events". It's the system that labels things like DVD-ROM drives, network cards, external hard drives, mousen, keyboards, joysticks and gamepads, and so on. That makes it a very handy utility, and like everything else in Linux, it's very well exposed to the user so you can manually script it to, for instance, perform certain tasks when a certain hard drive is plugged in.
**The script**
First, you need a script to launch when your drive is attached.
Start with something that will simply confirm that yes, ''udev'' is detecting a drive when it is plugged in, and is triggering a corresponding script. Since we cannot guarantee that we will ever see the results of the script with our own eyes, make the script //log// that it was successfully triggered:
#!/bin/sh
date > /tmp/udev.log
Place this in ''/usr/local/bin'' or some such place; call it ''safehouse.sh'' and make it executable with ''chmod +x''.
If ''udev'' triggers this script, there will be the timestamp of when it happened in ''/tmp/udev.log''
**Unique Device Identification**
In order for the ''safehouse.sh'' script to be triggered by a device event, ''udev'' must know under what conditions it should call the script. In real [human] life, we can look at our backup drive and say "Whenever I plug in this 3tb, gray drive, manufactured by TyCoon Corporation, I want the computer to back it up"; the computer can use, more or less, the same criteria, but it needs a more explicit way of identification.
The ''udev'' system can identify devices by serial number, vendor ID, and product ID (and more). As with so much in computers and art, we will make our first iteration very basic. Our criteria will begin as broad, non-specific, and all-inclusive as possible; we want first to catch nearly any valid ''udev'' event and trigger our script, just to confirm that we are on the right track.
With the ''udevadm'' monitor command, you can tap into ''udev'' in real-time and see what it sees when you plug in different devices. Become root, and try it:
$ su
# udevadm monitor
With ''udevadm'' monitor running, plug in your backup drive and watch as all kinds of information is spewed out onto your screen. Notice, particularly, that the type of event is an ''ADD'' event. That's a good way of identifying what type of event we want.
The ''udevadm'' monitor provides a lot of good info, but we can see it with prettier formatting with the command ''udevadm info -a -n'', assuming you know where your drive is currently located in your ''dev'' tree. If not, unplug and then plug your thumbdrive back in and then immediately issue this command:
# dmesg | grep \/dev\/sd* | tail -n1
Assume that this command returns ''sdx'', for instance; in that case, your thumbdrive has been assigned the ''sdx'' label (unlikely; it will probably be ''sdb'' or ''sdc'' or ''sdd'' or so) by the kernel. Now that we have established that, we can view the ''udev'' information about that device:
# udevadm info -a -n /dev/sdx | less
This will return a wealth of information. Focus on the first block of info, first.
The feedback from ''udevadm info -a -n'' starts with the device specified by the ''devpath'', and then walks up the chain of parent devices. It prints for every device found, all possible attributes in the ''udev'' rules key format.
A ''udev'' rule must contain one attribute from one single "parent" device; parent attributes are things that describe a device from the most basic level, such as "it's something that has been plugged into a physical port" or "it is something with a size of XX" or "this is a removable device".
That info, just under the ''udevadm info -a -n'' introductory paragraph, looks a little something like this:
looking at device '/devices/000:000/foo/bar//block/sdx':
KERNEL=="sdx"
SUBSYSTEM=="block"
DRIVER==""
ATTR{ro}=="0"
ATTR{size}=="125722368"
ATTR{stat}==" 2765 1537 5393"
ATTR{range}=="16"
ATTR{discard_alignment}=="0"
ATTR{removable}=="1"
ATTR{baz}=="quux"
Since the ''KERNEL'' label of ''sdx'' can change depending upon how many other drives you happen to have plugged in before you plug that drive in, that's not the optimal parent attribute for a ''udev'' rule, but it would work for testing. Another, //better//, candidate is the ''SUBSYSTEM'' attribute, which identifies that this is a "block" system device.
We now have enough to write a simple ''udev'' rule.
**A "Hello World" Udev Rule**
Construct a very simple and very generic proof-of-concept ''udev'' rule, just to make sure that everything is working as expected. The only goal at this stage is to trigger our basic script.
With ''kdesu'', open a file ''/etc/udev/rules.d/80-local.rules'' (it will not exist, so create it) and place this text into it (it's OK to copy and paste this text; it is **verbatim** what you should put into the file):
SUBSYSTEM=="block", ACTION=="add", RUN+="/usr/local/bin/safehouse.sh"
Unplug your drive, and reboot.
Once your computer is back up, plug in your drive. Wait a few moments, and then:
$ cat /tmp/udev.log
Wed Sep 19 22:23:22 EDT 2019
If you see the date and time returned from ''/tmp/udev.log'', then the script has worked.
**Refining the Rule into Something Useful**
The problem with the rule right now is that it is generic to the point of being functionally useless. Plugging in a mouse, a thumbdrive, or someone else's thumbdrive will all indiscriminately trigger your script. Now is the time to start focusing in on the exact backup drive you want to have trigger your script.
The easiest way to do that is with the vendor ID and product ID. To get these numbers, you can use the ''lsusb'' command.
$ lsusb
Bus 001 Device 002: ID 8087:0024 Slacker Corp. Hub
Bus 002 Device 002: ID 8087:0024 Slacker Corp. Hub
Bus 003 Device 005: ID 03f0:3307 TyCoon Corp.
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 hub
Bus 001 Device 003: ID 13d3:5165 Tyrell Network Interface
The ''vendorID'' and ''productID'' are the set of numbers around the colon ('':''). Looking at the ''TyCoon Corp.'' line, the vendor id is ''03f0'' and the product is ''3307''.
You can include these attributes in your rule. With ''kdesu'', open the file ''/etc/udev/rules.d/80-local.rules'' again and refine your rule (you need to customise this line to match what you see on your screen; do not copy-paste the text from here):
SUBSYSTEM=="block", ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="3307", ACTION=="add", RUN+="/usr/local/bin/safehouse.sh"
Reboot and test the new rule.
The results should be the same as before (except with a later timestamp), only now if you plug in, say, a drive manufactured by a different company (therefore with a different ''idVendor'') or a mouse or a webcam, the script will not be triggered.
Keep adding in new attributes to further focus in on the one unique drive that you want to trigger your script. In theory, the more specific, the better, although in practise the vendor and product may be suitable, depending on how many of the exact same drives you own. Use ''udevadm info -a -n /dev/sdx'' to find out vendor name, serial number, product name, and so on.
For your own sanity, be sure to add only //one// new attribute at a time. Most mistakes made during this process come from throwing a bunch of attributes into a ''udev'' rule such that nothing ever matches it.
**Refining the Script**
Once you can comfortably confirm that your script is triggered by ''udev'' when you attach your backup drive, turn your attention to the functionality of the script. Right now it is useless, doing nothing more than logging the fact that it has been executed.
Here is an example backup-on-attach script. You can use it exactly as is EXCEPT for the last command; you need to change the path of the directory you want backed up (unless your username is also ''klaatu'') and the destination (unless you also named your destination folder ''klaatu''):
#!/usr/bin/bash
mount /safehouse
COUNT=0
# wait for drive to mount and be writable
while [ "$COUNT" -lt "6" ]; do
sleep 5
if [ -b /safehouse ]; then
if [ -w /safehouse/klaatu ]; then
# everything is ok
COUNT=9
break
else
echo "Backup directory has incorrect permissions @ `date`" >> /tmp/safehouse.log
fi
else
echo "Drive not mounted @ `date`" >> /tmp/safehouse.log
fi
let "COUNT++"
done
# this is hopeless, get out
if [ "${COUNT}" == "6" ]; then
echo "Could not locate SAFEHOUSE. Backup NOT complete. THIS IS BAD. `date`" >> $HOME/safehouse.log
exit
fi
# if we are here, everything is good to go
if [ "${COUNT}" -gt 6 ]; then
##BACKUP COMMAND
rdiff-backup /home/klaatu /safehouse/klaatu
fi
You might have exclusions that you don't want to have backed up (for instance, do you ever want your trash bin backed up?). For this, read the section on [[#excludes|exclude]] options, and then add those options to the ''##BACKUP COMMAND'' section.
☛ Try changing a file or adding a new test file, and then attach your hard drive. A backup process should be started by ''udev'', this time copying over only the changes you have made to your home directory. Check for errors in ''/tmp'' and in your home directory.
☛ Assuming everything is working as expected, [[#automate|automate]] the process and never think about it again.
☛ For information on recovering data //from// a backup, read the section on [[#recovery|restoring files]].
{{anchor:bkpserver}}
=====Backup to a Personal Server=====
If you have a home server, or a server away from home that you can physically access, you might prefer to do your backups remotely. The advantage to remote backups is that you neither get tied down by having a hard drive attached to your computer, nor do you have to remember to attach it if you like a mobile lifestyle. If your server is off-site, then you have some insurance against disaster, since the likelihood of both your personal computer and your off-site server facing destruction is less likely when they are not physically located in the same building.
You should have gone through the setup steps before starting this process, so you should have a hard drive in the UDF format with the initial backup of your data on it. Your server should have a ''/safehouse'' mount point on it, and the drive should be set as mountable in ''fstab''. Both your client and your server must have ''rdiff-backup'' installed.
For rdiff-backup to work remotely, //both// your client (the machine whose data is being backed up) and the server (the computer receiving the backup data for storage) must have ''rdiff-backup'' installed. That's **two** installs of ''rdiff-backup''.
**1.** Mount the drive on your server:
$ mount /safehouse
**2.** Make the server accessible by ''ssh'' or ''rsync'' (for ''rsync'', you'll also need to run the rsync daemon, which requires additional setup.
For security's sake, and because ''rdiff-backup'' will not prompt you for a password, you must use an ssh key to log into the remote server. For more information on ssh keys, see the [[#automate|automation]] section.
On the server, you should disable ssh-password sign-in (this option is found in ''/etc/ssh/sshd_config''), and consider using [[http://fail2ban.org|Fail2Ban]].
**3.** Attempt a remote backup:
$ rdiff-backup -v 8 $HOME username@your-server.info::/safehouse/username
This time, the process is quite fast, since it has only copied over the changes.
☛ You might have exclusions that you don't want to have backed up (for instance, do you ever want your trash bin backed up?). For this, read the section on [[#excludes|exclude]] options.
☛ Assuming everything is working as expected, [[#automate|automate]] the process and never think about it again.
☛ For information on recovering data //from// a backup, read the section on [[#recovery|restoring files]].
{{anchor:bkpcloud}}
=====Backup to Someone Else's Server=====
Backing up to a server that you do not own or do not have physical access to can be tricky, because you may not have access to it in such a way that remote backups are allowed. Besides, the remote server must also have ''rdiff-backup'' installed on it, and it may not have that.
On the other hand, you might; it depends on what you are paying for, or what the sys admin is providing you.
If you have ''ssh'' access to the server, then you can treat it the same as [[#bkpserver|your own private server]] in terms of setup.
Other methods of accessing the server will likely not work, since ''rdiff-backup'' must be on the remote server, and needs ssh access.
You might look into other backup solutions, like [[http://luckybackup.sourceforge.net]].
{{anchor:bkpcherrypick}}
=====Backup a la Carte=====
Some people generate more data than others. If you are, for example, a writer or any kind of artist dealing in small file formats, and you find it's easier to just backup files as you create them, then that's a valid backup option...as long as you remember to do it.
Consider purchasing a large-capacity thumbdrive and using it as either your master work directory or as your [[#bkpconnect|plug-and-backup]] destination. That way, every time you plug your drive into your computer, it gets backed up; you no longer have to remember to do it manually!
If you are using rdiff-backup, you can backup a single file between backup script occurrences:
$ rdiff-backup --include $HOME/foo.txt --exclude '**' $HOME /safehouse
Another option is to wield the power of the Internet, and use a good git service. There are several simple clients for git, including the very appealing [[http://sparkleshare.org|SparkeShare]] or, if you have access to a server and the time to configure it, [[http://owncloud.org|ownCloud]]. These both have Dropbox-style sync folders.
{{anchor:excludes}}
=====Excludes=====
No matter what your backup plan, space is limited. There are bound to be things hanging around in your home directory that just aren't important to you. You can and should exclude these files from being backed up.
You could specify the directories and files you want excluded in your ''rdiff-backup'' command, but if you are automating the backups (and you should be), then what not to backup also should be automated.
The solution is to have a local ''~/.excludes'' file, listing each directory or file you want excluded from the ''rdiff-backup'' process. Such a file is easy to create: just echo the path of a directory or file into ''~/.excludes''; if it does not exist, the file will be created for you, and the entry added.
$ echo '/home/klaatu/.local/share/Trash' >> ~/.excludes
As you find more files that you want to exclude, use the same command.
$ echo '/home/klaatu/stockFootage' >> ~/.excludes
$ echo '/home/klaatu/downloads' >> ~/.excludes
The only thing you must do is change the command you use to start the backups such that it knows where to look for a list of files to ignore:
rdiff-backup --exclude-globbing-filelist \
/home/klaatu/.excludes \
/home/klaatu/ \
klaatu@homelinux.local:/safehouse
{{anchor:automate}}
=====Automate=====
Surprisingly, the hardest part about ''rdiff-backup'' or any backup plan is just determining //how// it should happen; once you have a hard drive dedicated to backing up your data, and have devised a way for that hard drive to be available, the automation part of the plan is simple.
====Cron====
Processes on Linux can be scheduled with ''cron''. Each user has a cron table or ''crontab'', which can be edited to run tasks at certain times.
$ EDITOR=emacs crontab -e
or if you prefer kate:
$ EDITOR=kate crontab -e
Your ''crontab'' will most likely be empty. Add a line like this (do not copy and paste this, modify it for your setup):
0 */6 * * * rdiff-backup --exclude-globbing-filelist /home/klaatu/.excludes /home/klaatu/ klaatu@example.local::/safehouse/klaatu/
This sets up an automatic backup every 6th hour (on the hour) of every day of every month, regardless of the day of the week.
The syntax for scheduling events in ''cron'' is:
* Minute (0-59): This is almost never a ''*'' (which would mean to perform an action //every minute//. It is combined with the **hour** field, such that the 0th minute of the 4th hour (4:00), some action would occur.
* Hour (0-23): 24 hour clock; 4 is 4am, 16 is 4pm. Use the ''/'' (slash) to do things at increments. ''*/4'' means any hour that is cleanly divisible by 4 (so, every 4 hours). ''*/3'' is every three hours, and so on. ''*'' means //every// hour at whatever minute is set in the **minute** field.
* Day of Month (1-31): ''*'' means every day. ''*/2'' would mean every other day, ''*/3'' every three days, and so on.
* Month (1-12): Same principle as the day field.
* Day of Week (0-6): 0 is Sunday and 6 is Saturday.
For example, to run a backup once a day at 23:00:
0 23 * * * rdiff-backup blah blah
To run backups every other hour only during 9:00 to 17:00 (business hours):
0 9,11,13,15,17 * * * rdiff-backup blah blah
The same, excluding weekends:
0 9,11,13,15,17 * * 1,2,3,4,5 rdiff-backup blah blah
And so on. If you are unclear, there are several good examples online, probably for the exact schedule you are planning.
''Cron'' only works if your computer is //on//.
====SSH Keys====
If you are backing up to a local drive (that is, a drive attached physically to your computer), then you can skip this section.
If you are backing up to a server over SSH, then you presumably need to sign into that server. You are not prompted by ''rdiff-backup'' for a password, and even if you were, you wouldn't see it because you're automating the backup process.
Therefore, you must set up ssh key sign-in for your server.
Slackware makes this very easy. If you do not already have an ssh key on your Slackermedia machine, create one (it's free):
$ ssh-keygen
When prompted to create a passphrase, **leave the passphrase empty**. If you give you ssh key a passphrase, then you are defeating the purpose of using an ssh key for this use case.
If you already have an ssh key on your source machine, then you can use that. If, however, that key requires a password, then it's useless for automated backups. Create a new key, exclusively for the backup server. For example:
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/klaatu/.ssh/id_rsa): /home/klaatu/.ssh/safehouse_rsa
Enter passphrase (empty for no passphrase): LEAVE THIS EMPTY
Enter same passphrase again: LEAVE THIS EMPTY
Your identification has been saved in /home/klaatu/.ssh/safehouse_rsa.
Now configure ''ssh'' to use your new ''safehouse_rsa'' key whenever you attempt to login to your backup host.
Open ''~/.ssh/config'' in your favourite text editor. If that file does not exist (it probably won't) then create it. Here are two examples of valid configurations, one for a server with a fully-qualified domain name, and one for an internal home server:
host slackermedia.info
hostname slackermedia.info
identityfile /home/klaatu/.ssh/safehouse_rsa
protocol 2
host 10.1.1.11
hostname 10.1.1.11
identityfile /home/klaatu/.ssh/safehouse_rsa
protocol 2
Once your ssh key has been generated, copy it to your server:
$ ssh-copy-id -i /home/klaatu/.ssh/safehouse_rsa klaatu@example.com
Test it out by ssh'ing into the server: You should not be prompted for a password.
$ ssh klaatu@10.1.1.11"
Assuming success, you now have password-less entry into your backup server (and so does rdiff-backup, since it will be running under your username).
{{anchor:recovery}}
=====Restoring (Recovering) Files=====
Once you have a backup, you obviously are able to restore files that you have either lost or changed beyond repair.
The command to get a file back off of a drive differs depending on how you are accessing the drive. For clarity, examples of both local and remote access are given.
Restore the most-recently backed-up version of a file:
$ rdiff-backup --restore-as-of now /safehouse/klaatu/paint/jlw.kra ~/paint/jlw.kra
$ rdiff-backup --restore-as-of now klaatu@example.local::/safehouse/klaatu/paint/jlw.kra ~/paint/jlw.kra
The ''--restore-as-of'' option (''-r'') can go back is time farther than just the most recent back-up. For instance, maybe you think the best good version of a file existed two days ago:
$ rdiff-backup --restore-as-of 2D /safehouse/klaatu/paint/jlw.kra ~/paint/jlw.kra
$ rdiff-backup --restore-as-of 2D klaatu@example.local::/safehouse/klaatu/paint/jlw.kra ~/paint/jlw.kra
Or maybe you aren't sure, and would rather view a few different versions. It's all backed up, so you can resurrect as many versions as you like:
$ rdiff-backup --restore-as-of 2D /safehouse/klaatu/paint/jlw.kra ~/paint/jlw-2days.kra
$ rdiff-backup --restore-as-of 5D /safehouse/klaatu/paint/jlw.kra ~/paint/jlw-5days.kra
Other acceptable time formats include 33m33s (33 minutes and 33 seconds ago) and full dates like 2015-01-01 for that New Years photo that you wanted to forget but are now having second thoughts about. For more options, see the ''TIME FORMATS'' section of the ''rdiff-backup'' man page.
If you know even more detail about your file, you can use ''rdiff-backup'' to restore directly from an incremental backup file. Increment files are stored in your backup destination (''/safehouse'', what ever drive or server that may exist on) in ''rdiff-backup-data/increments''.
They hold the previous versions of changed files. If you specify one directly:
rdiff-backup /safehouse/klaatu/rdiff-backup-data/increments/novel.2014-11-24T02:21:41-07:00.diff.gz ~
=====Dummy Checks=====
It's not a bad idea to check in on your backups every now and again, just to verify that what you think is happening is really happening.
To check your backups, log into your backup server or attach your backup drive, and have a look at the latest ten (or so) backup files created:
$ find /path/to/backup/dir -type f -printf "%C+ %p\n" | sort -rn | head -n 10
Adjust your backup scheme as necessary, depending on what you discover.
=====Documentation=====
There are several good article on ''rdiff-backup''. [[http://www.kirya.net/articles/backups-using-rdiff-backup]] is quite good.
[[sox|R]] [[start|S]] [[rescue|Q]]