-
Rsnapshot currently requires that ssh sources specify a username (USER@HOST:PATH), and rsync has no such requirement. The rsnapshot requirement should be relaxed for users who want to let ssh pick up the proper username from its configuration. See https://sourceforge.net/mailarchive/forum.php?thread_name=4AD8423A.4020002%40vevida.nl&forum_name=rsnapshot-discuss .
2009-11-21 14:28:55 UTC by hashproduct
-
Rsnapshot strips trailing slashes from backup points when --relative is on. This was a workaround for a bug in rsync < 2.6.5 which can probably be carefully removed now. It has two ill effects:
- A symlink to a directory is not followed even if it was originally specified with a trailing slash.
When --relative is on and a symlink to a directory is given as a backup point, even with a...
2009-11-21 13:32:47 UTC by hashproduct
-
Users who have multiple backup points with similar content (e.g., multiple machines with the same OS) would like to use --link-dest among the backup points to save disk space and (when applicable) network usage. This can be done with rsync_long_args, but the extra --link-dest argument is inserted before the default one (should be after like a rename-hints dir, see artifact #2901726) and the...
2009-11-21 13:18:51 UTC by hashproduct
-
This would be consistent with rsnapshot itself and would avoid some portability problems with regular expressions. See https://sourceforge.net/mailarchive/message.php?msg_name=1225119001.26837.12.camel%40mattlaptop2.local .
2009-11-21 13:11:34 UTC by hashproduct
-
There's some interest in using rsnapshot-copy for incremental mirroring, but it is not currently designed to do that. See https://sourceforge.net/mailarchive/message.php?msg_name=1208090388.2278.72.camel%40localhost .
To support incremental mirroring, rsnapshot-copy would need to match up snapshots by mtime and rearrange the destination snapshots into the right sequence before proceeding;...
2009-11-21 13:08:31 UTC by hashproduct
-
Renaming a large directory on the source normally breaks the chain of hard links because the data is not where rsnapshot would expect it in the previous snapshot. This can be remedied by performing the same rename on the previous snapshot, but I don't like to modify previous snapshots. A gentler alternative is to pass an additional --link-dest directory with a symlink in the right place so...
2009-11-21 13:02:51 UTC by hashproduct
-
Instead of deleting an old snapshot dir, rsnapshot may be able to get a performance boost by overwriting it directly with the new snapshot. This requires protection against tweaking the attributes. See https://sourceforge.net/mailarchive/forum.php?thread_name=bd11588a0812180058k7d592883iebc5f10e6b4a154%40mail.gmail.com&forum_name=rsnapshot-discuss .
2009-11-21 12:45:21 UTC by hashproduct
-
Oops, I meant also to link to this one: https://sourceforge.net/mailarchive/message.php?msg_name=1202164822.2323.8.camel%40localhost.
2009-11-21 12:34:04 UTC by hashproduct
-
When rsnapshot runs rsync on a destination that already contains files hard-linked from a previous snapshot, rsync may tweak the attributes of those files, effectively corrupting the attributes as seen via the previous snapshot. This can happen in two scenarios: (1) when link_dest is off and (2) when retrying a backup with sync_first.
My proposed --no-tweak-hlinked rsync option (...
2009-11-21 12:32:51 UTC by hashproduct
-
Give each snapshot a fixed name, possibly but not necessarily depending on the time it was taken. This would make it easier to incrementally mirror a snapshot root, e.g., with rsnapshot-copy. This was discussed in the following thread, along with some other ideas that might merit separate consideration...
2009-11-21 12:18:54 UTC by hashproduct
