rdiff-backup preserves metadata in separate files so it doesn't need to
be root on the storage node. If you can make that work, you can avoid
the rsync-to-root and use an rdiff-backup-specific non-root user.
I've been informed on this list before that rdiff-backup has
shortcomings when used
Grant emailgr...@gmail.com writes:
rdiff-backup preserves metadata in separate files so it doesn't need to
be root on the storage node. If you can make that work, you can avoid
the rsync-to-root and use an rdiff-backup-specific non-root user.
I've been informed on this list before that
I'm struggling to devise an incremental, automated backup scheme that
remotely and securely backs up data from one system to another,
preserves permissions and ownership, and keeps the backups safe even
if the backed-up system is compromised. Would the following work?
What are you calling
well, I mean somehow make a fresh copy from client to tape, such that
you aren't relying on intermediate nodes having reliable state from the
past.
This is basically the old-school backup philosophy.
___
rdiff-backup-users mailing list at
That's true, corruption really is still a problem. What can be done?
Write everything to tape and keep yearly backups forever :-) People
have been down on tape for a long time but I'm not sure they have
replicated the security properties.
So you're saying write directly from the clients
Basically run dump or something on the client, to a holding disk file on
the server with the tape. I don't see any issue with temporary disk
use. The point is that all the temp bits are written anew each time,
not assumed to be the same based on metadata.
amanda is a system that works this
Basically run dump or something on the client, to a holding disk file on
the server with the tape. I don't see any issue with temporary disk
use. The point is that all the temp bits are written anew each time,
not assumed to be the same based on metadata.
So what we are trying to avoid is
