A place to discuss Backup software and online services
You are not signed in.
In my previous post, I was asking about some things that would trigger a backup to occur on a linux host. So, here's a list of the tests that I ran:
Things that did NOT trigger a backup:
1) Changing permissions
2) Changing ownership
3) Changing inode
(I'm really happy about #3... that means I can move files to a new disk and, provide all the paths stay the same, they will not get backed up again)
Things that DID trigger a backup
1) Changing the timestamp (either forwards or backwards)
2) Changing the file size (even if you force the timestamp to be unchanged)
3) Changing the file in a way that keeps the same size
I tested moving timestamps backwards to simulate if you placed an older copy of the file in place. So, ANY timestamp change triggers a backup, even if you do not modify the file.
Also, I did want to make sure that the backup wasn't triggered just on the file size, so I did a set of modifications that kept the same file size, and as expected, they triggered a backup. That was probably just being a bit paranoid, but just wanted to be sure.
So, it's a reasonable backup solution for linux provided you're basically a single user.
Trying to do system-level backups is probably not great because:
o It doesn't handle permissions and ownerships at all (which renders it virtually useless for a system-level install)
o It doesn't handle symlinks correctly (they should be backed up as a symlink, NOT as a file/directory that the link points at
o I assume that it probably doesn't handle other types of special files (hard links, semaphores, sockets, etc.) though I didn't test them out.
All in all, I'm happy to use it as a user-level backup solution.
Offline