“Do not cross filesystem boundaries” means “do not look inside mount points”. A boundary between filesystems is a mount point. Effectively, this means “only act on the specified partition”, except that not all filesystems are on a partition. See What mount points exist on a typical Linux system?
When you make a backup, you should avoid a number of ...
There is a fourth field for the backup line, which can be used for such tasks. So your line should look like follows.
backup tom@laptop:/home/tom/ laptop/ exclude=/home/tom/music
You can add more per backup options by separating these with a comma. For further reading consult the man page of rsnapshot.
First off, you should read up a little on rsync's include/exclude syntax. I get the feeling that what you want to do is better done using ** globs than * globs. (** expands to any number of entries, whereas * expands only to a single entry possibly matching multiple directory entries. The details are in man rsync under Include/Exclude Pattern Rules.)
Rsnapshot takes a snapshot every day and every seven days the oldest daily snapshot becomes the new weekly snapshot. The other dailies are discarded. That's the basic idea, to store a relatively low number of snapshots, but with high granularity for the recent days and decreasing granularity for older data.
If I understand you correctly, you want to keep ...
You will be running as root on server A, which runs rsnapshot, and ssh-ing to your dedicated user backupmaker on B. Normally, you will want this user to be able to sudo rsync, so that you can read all the files to send back to A.
Assume, for example, you have a user on A who can sudo, and another user on B who can sudo. On B create user backupmaker and ...
In general rsnapshot is just making use of rsync so it should work fine with backing up a variety of files from file systems such as ext3, ext4, FAT, and NTFS.
The comment that you're referring to:
Backing up to external usb HDD's works perfectly, but one needs to use
a ext3 or similar formatted drive that supports hard links. So no
FAT32 or NTFS ...
There's a --fake-super option that stores the attributes that can't be set in extended attributes (Which means the target FS has to support extended attributes).
To check for extended attribute support, you can do it with setfattr or rsync itself. Then it demonstrates how it works:
~$ rsync --fake-super /bin/ls .
~$ getfattr -dm- ./ls
# file: ./ls
I know your question is about rsync, but this may be helpful regarding backups. This is roughly how I do my offsite backups.
Rsync-based alternative Rdiff-backup
Rdiff-backup may be worth a try.
It uses rsync (or librsync) under water and handles all magic about permissions and attributes already for you, even when the target filesystem does not support ...
This original advice applies only to Debian-based distributions:
The two crontab segments you've shown are not the same crontab. So your jobs are running twice (once from /etc/cron.d/rsnapshot and once from crontab -l).
Remove one set, for example with sudo crontab -r, and it'll start working properly.
The next suggestion is to ensure that sync_first is ...
Most of what you are trying to do can probably be accomplished simply by using the one_fs setting. Set the filesystems you want to include in your backups, then use that setting to ignore the rest (proc, sys, dev, etc.). I'd include /lost+found because that directory should always be empty unless you've backed-up a corrupted filesystem, in which case you ...
To simplify things, let's just consider two partitions. Assume that running mount actually produced the following output:
/dev/sda1 on / type ext4 (rw,errors=remount-ro)
/dev/sda2 on /home type ext4 (rw)
This is, of course, utterly unrealistic (/dev wouldn't be populated, tons of stuff relies on sysfsand procfs, etc). Let's just ignore that.
Crossing a ...
Since this is the top result for my google search, I think the following might help others too:
Thomas' command works, but it removes all globally defined exclude directives in /etc/rsnapshot.conf
In order to keep existing excludes you can use the following
backup tom@laptop:/home/tom/ laptop/ +rsync_long_args=--exclude=/home/tom/music
SSH is pretty slow as a protocol for massive transmission of data, I hit a fraction of my network/disk speeds when doing transfers like this too. One thing you can do to improve performance - tho I have no idea how you would implement it - switch the "cipher" to blowfish, which I believe is the fastest of the SSH cyphers. I'm not really qualified to ...
If it is intended as a backup (I'm looking at the tag), not as a remote copy of working directory, you should consider using tools like dar or good old tar. If some important file gets deleted and you won't notice it, you will have no chance to recover it after the weekly sync.
Second advantage is that using tar/dar will let you preserve ownership of the ...
The time it takes to encrypt is proportional to the size of the data, plus some constant overhead. You can't save time for the whole operation by splitting the data, except by taking advantage of multiple cores so that it takes the same CPU time overall (or very slightly little more) but less wall-clock time. Splitting can of course be advantageous if you ...
Testing configuration sudo rsnapshot configtest should get you a Syntax ok
Dry testing will be sudo rsnapshot -t daily
Complete test will be sudo rsnapshot daily
You can do the same with either hourly|weekly|monthly
If you have the output of rsnapshot available, you can safely repeat the rsync command that it used. You do not (and should not) delete hourly.0 if you're going to do this.
For example, on one of my systems this is (almost) what gets run by rsnapshot, so this could be copied and pasted and rerun:
/usr/bin/rsync -avzS --delete --delete-excluded --numeric-...
Take a look at this topic in the CentOS wiki, titled: rsnapshot Backups. It has examples that show how to backup using rsnapshot:
excerpt from that page
# crontab -e
#MAILTO="" ##Supresses output
#minute (0-59), #
#| hour (0-...
After the snapshot, you can use rsnapshot diff which calls rsnapshot-diff to note the differences between two snapshots. It just compares inode numbers so is fairly efficient.
Alternatively, before each backup create a file outside the backup tree to note the time, touch timestamp. Then before a new backup, create a new timestamp, touch timestamp.new, and ...
There is no “best way”. It all depends on your setup and requirements.
One way that also works if the backup directories contains lots of files would be to use snapshots on a lower level and send them to the remote server. ZFS can do that and probably LVM as well, but I never used that. You didn't state your file system or if you use a volume manager, ...
Are you sure you have a abc_backups directory at the root of your filesystem? I really doubt it (and even if you did, this is not a good practice). Also backup takes 2 arguments, not one as in your example. First the source (what you backup) and then the destination.
Based on your description, change your backup line like that:
I don't think that is a very sound idea.
If rsnapshot is run as root, then you should configure it
If rsnapshot is run as <username> then they can configure it. They can achieve this by using their own crontab entry.
I would opt for the first option.
But to answer your question specifically, remember the configuration file can be specified using -c ...
Unless you set rsync_short_args or rsync_long_args in the configuration file for rsnapshot, you'll use rsync -a to perform the copy.
The default action for rsync -a is to copy a symlink as a symlink, and to ignore the target of the symlink. (Obviously, if the target of the symlink is within your source file tree it will get copied, but that's because of its ...
A perhaps not so simple way is to connect as root but to limit the key used to connect to only run specific invocations of rsync; this requires an /root/.ssh/authorized_keys entry along the lines of
from="192.0.2.*",command="/root/limit-rsnap" ssh-rsa AAAAB3N...
which limits both where the backup is expected to originate from (this may not be ideal for ...
You normally want to run rsnapshot as root user and also copy the files as root on the remote side. Otherwise all user and group ownerships would be set to the user you are using to connect to the remote side, which will render your backup to useless.
To check why not all data was copied, look into the logs which by default is the system log or if you have ...
In actual fact the sudo option is not working itself because it says that it can't write on the /mnt/Server1/Backup folder
[dom ott 14, 01:15 ][antonio@gaia:~]sudo rsnapshot alpha
[sudo] password di User1:
rsnapshot encountered an error! The program was invoked ...
It could be hard work trying to rename remote daily.0 directories to keep in sync with renaming done locally by rsnapshot. This might be needed to avoid an rsync of the entire snapshot directory from local to remote having to do a lot of work. It would be much simpler to have separate snapshots independently generated, locally and remotely. You will even ...
Note the equals sign in Thomas' example. If you miss it, rsnapshot configtest fails with an error suggesting you use tabs!
You also don't need to prefix the exclude= with a plus, as some other Q&As suggest -- and if you do, rsnapshot configtest will fail with 'uninitialized value in concatenation or string'.
Here's an example with multiple excludes:
After some extended discussion it appears that the filesystem may corrupted. As an example, rm -rf fails - as root - on a normal tree of files.
After unmounting the filesystem, fsck identified it as NTFS.
Frustratingly I have seen NTFS fail on other Linux-based platforms under the heavy loads incurred from rsnapshot. There's nothing sufficiently repeatable ...
I find it is better to have a package list, the contents of /etc, /home, and any user/system data from /var and elsewhere. It is usually faster to reinstall the packages and copy back the working config.