Solaris du does not work at all, because it doesn't support the -c parameter. If you have rsync version 2. Be advised, however, that if a remote host is unavailable during a backup, rsnapshot will take an extra step and roll back the files from the previous backup. Using GNU cp, this would not be necessary. Everyone's backup scheme may be different. In order to specify how much data to save, you need to tell rsnapshot which "intervals" to keep, and how many of each.
An interval, in the context of the rsnapshot config file, is a unit of time measurement. These can actually be named anything as long as it's alphanumeric, and not a reserved word , but by convention we will call ours hourly and daily.
In this example, we want to take a snapshot every four hours, or six times a day these are the hourly intervals. We also want to keep a second set, which are taken once a day, and stored for a week or seven days.
This happens to be the default, so as you can see the config file reads:. Please note that the hourly interval is specified first. This is very important. The first interval line is assumed to be the smallest unit of time, with each additional line getting successively larger.
Thus, if you add a yearly interval, it should go at the bottom, and if you add a minutes interval, it should go before hourly. It's also worth noting that the snapshots get "pulled up" from the smallest interval to the largest. In this example, the daily snapshots get pulled from the oldest hourly snapshot, not directly from the main filesystem. If you are installing for the first time, this is the default setting. This is the section where you tell rsnapshot what files you actually want to back up.
You put a "backup" parameter first, followed by the full path to the directory or network path you're backing up. The third column is the relative path you want to back up to inside the snapshot root.
Let's look at an example:. In this example, backup tells us it's a backup point. Using the word localhost as the destination directory is just a convention. You might also choose to use the server's fully qualified domain name instead of localhost. If you are taking snapshots of several machines on one dedicated backup server, it's a good idea to use their various hostnames as directories to keep track of which files came from which server.
In addition to full paths on the local filesystem, you can also backup remote systems using rsync over ssh. With this parameter, the second column is the full path to an executable backup script, and the third column is the local path you want to store it in just like with the "backup" parameter.
For example:. Feel free to modify it for your system. Your backup script simply needs to dump out the contents of whatever it does into it's current working directory.
The reason for this is that rsnapshot creates a temp directory, changes to that directory, runs the backup script, and then syncs the contents of the temp directory to the local path you specified in the third column. A typical backup script would be one that archives the contents of a database. It might look like this:. Make sure the destination path you specify is unique.
The backup script will completely overwrite anything in the destination path, so if you tried to specify the same destination twice, you would be left with only the files from the last script. Fortunately, rsnapshot will try to prevent you from doing this when it reads the config file. Please remember that these backup scripts will be invoked as the user running rsnapshot.
In our example, this is root. Make sure your backup scripts are owned by root, and not writable by anyone else. If you fail to do this, anyone with write access to these backup scripts will be able to put commands in them that will be run as the root user. If they are malicious, they could take over your server. When you have made all your changes, you should verify that the config file is syntactically valid, and that all the supporting programs are where you think they are.
To do this, run rsnapshot with the configtest argument:. If all is well, it should say Syntax OK. If there's a problem, it should tell you exactly what it is. Make sure your config file is using tabs and not spaces, etc.
The final step to test your configuration is to run rsnapshot in test mode. This will print out a verbose list of the things it will do, without actually doing them. To do a test run, run this command:. This tells rsnapshot to simulate an "hourly" backup. It should print out the commands it will perform when it runs for real.
Please note that the test output might be slightly different than the real execution, but only because the test doesn't actually do things that may be checked for later in the program. For example, if the program will create a directory and then later test to see if that directory exists, the test run might claim that it would create the directory twice, since it didn't actually get created during the test. This should be the only type of difference you will see while running a test.
Now that you have your config file set up, it's time to set up rsnapshot to be run from cron. As the root user, edit root's crontab by typing:. You could alternately keep a crontab file that you load in, but the concepts are the same. You want to enter the following information into root's crontab:. It is usually a good idea to schedule the larger intervals to run a bit before the lower ones.
For example, in the crontab above, notice that daily runs 30 minutes before hourly. This helps prevent race conditions where the daily would try to run before the hourly job had finished. This same strategy should be extended so that a weekly entry would run before the daily and so on. We have a snapshot root under which all backups are stored.
Within this directory, other directories are created for the various intervals that have been defined. In the beginning it will be empty, but once rsnapshot has been running for a week, it should look something like this:. Inside each of these directories is a "full" backup of that point in time. In the example:. Each subsequent time rsnapshot is run with the hourly command, it will rotate the hourly. X directories, and then "copy" the contents of the hourly.
When rsnapshot daily is run, it will rotate all the daily. X directories, then copy the contents of hourly. Unless the files change between snapshots, the "full" backups are really just multiple hard links to the same files. This is how rsnapshot can be so efficient on space. I cannot for the life of me figure out how to resolve that? There is nothing more annoying than going through short tutorials like this and it is not workign because of the author can't write correct statements!
Unless that author does it on purpose to force users to think and find solutions on their own. This feature is only available to subscribers. Get your subscription here. Log in or Sign up. Suggested articles. When entered as is, the configtest run fails.
There should be no spaces, but only tabs between the segments 2. Please correct it. You have to use RSA key authentication without passphrase in most cases. In untrusted networks DO NOT expose root account, use a backup user with advanced privileges for example, modify sudoers file to permit rsync command without password for this user.
In other words, you cannot push backups to a remote server. You can pull them locally from a remote server. I have over 15 years of professional experience designing and developing web applications. I am also very experienced in managing web projects.
Skip to content. Tube train. Contents hide. This is particularly useful if you are backing up to removable media, such as a FireWire or USB drive.
0コメント