You and rsync - what's your backup use

[jajodo]

I have found a combination of lucky backup and hard link backup useful, quick and it takes up little space.
Lucky backup runs and differentially copies my files to a directory "current"
Lucky backup then executes my one line script that makes hard links of files in current to a directory automatically named date and time:
So directory "current" is my latest backup and I have full backups from multiple dates each only taking up the space and time of a differential backup.

cp -alr /path/to/current /path/to/backup-`date +%Y%m%d--%T`

[jajodo]

I just looked at screenshots of back in time.
The backups are named very similarly to what you get if you use the cp command I use

[TheFu]

I just looked at screenshots of back in time.
The backups are named very similarly to what you get if you use the cp command I use

Back-in-time is using the normal rsync+hardlinked version method. What makes back-in-time very great is that it does hourly backups with hardlinks and deletes more and more of those backup sets as time moves forward So, for the last 48 hours, we have 1 backup set for each hour. More than 48 hours ago, we have 1 backup set for each day. More than a week ago and we have just 1 weekly backup. More than a month ago and we have 1 backup per month.

That selective deletion of older backup setups is very powerful.

Alas, all hard-link based versioned backups have a failure. The owner, group and permissions aren't also versioned. It doesn't usually matter, until it does. then it is the difference between a usable backup and lots of data that isn't very useful. For HOME directories, it usually doesn't matter, but for system level backups over many months, it may become a problem.

Don't believe me. Test it yourself.

# work in /tmp/
cd /tmp/
# create a hardlink for /etc/hosts as /tmp/hosts
ln /etc/hosts
# Check the permissions
ls -l /etc/hosts /tmp/hosts
-rw-r--r-- 2 root root 270 Mar  6 10:46 /etc/hosts
-rw-r--r-- 2 root root 270 Mar  6 10:46 /tmp/hosts

# change the group on /tmp/hosts
sudo chgrp $USER /tmp/hosts
# Check the permissions, again
$ ls -l /etc/hosts /tmp/hosts
-rw-r--r-- 2 root tf 270 Mar  6 10:46 /etc/hosts
-rw-r--r-- 2 root tf 270 Mar  6 10:46 /tmp/hosts

See how both have the wrong group now? You could change the permissions too, but that isn't safe.

# Be certain to put the group back to 'root' on the file.
sudo chgrp root /tmp/hosts
# And clean up that temp file
sudo rm /tmp/hosts

I've been burned by this problem. This is why I use rdiff-backup. It handles versioning of the owner, group, permissions, ACLs, and xattrs correctly.

[jajodo]

I've been burned by this problem. This is why I use rdiff-backup. It handles versioning of the owner, group, permissions, ACLs, and xattrs correctly.

I see your point. Preserving old, in my case undesired, permissions and groups is definitely not my use case.

I don't know much about rdiff-backup. If that handles versioning the way you need could you use rdiff-backup followed by the cp hard link command to avoid the whole "need to look up the rdiff-backup -r {timespec} command timespec" issue?

[TheFu]

I see your point. Preserving old, in my case undesired, permissions and groups is definitely not my use case.

I don't know much about rdiff-backup. If that handles versioning the way you need could you use rdiff-backup followed by the cp hard link command to avoid the whole "need to look up the rdiff-backup -r {timespec} command timespec" issue?

No need. That would be extremely inefficient when rdiff-backup is already more efficient than the hardlink method. Plus, don't touch files with any other tools inside a backup storage area. That's a mandated rule. Copying files out is fine - rsync, cp, whatever. Viewing and grepping is fine too. Just don't change anything under the backup tool's control, unless you want to corrupt things.