[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rdiff-backup-users] Incremental, automated, remote, secure
From: |
Grant |
Subject: |
Re: [rdiff-backup-users] Incremental, automated, remote, secure |
Date: |
Thu, 18 Jul 2013 08:05:00 -0700 |
>>> 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 to transfer data over the internet and it is
>> better to use rsync over the internet and rdiff-backup locally on one
>> side of the other. I did find out that rsync --fake-super will store
>> permissions and ownership in ACLs so that negates the need for remote
>> root.
>
> Well, if you have that much extra space, perhaps. I do rdiff-backup
> over the internet (as root on some box, to a non-root user on another
> box) all the time, and haven't had trouble.
Sometimes I'm on the road with my laptop tethered to my cell phone and
then I have trouble using rdiff-backup over the internet.
>>> The scary risk is silent corruption and losing old backups. So you need
>>> to keep periodic backups essentially forever.
>>
>> If the clients rsync data to the backup server and the server runs
>> rdiff-backup locally on that rsynced data, and another system pulls
>> that rsynced data from the server and maintains its own rdiff-backup
>> repository, I think I should very likely be OK as far as corruption.
>> Offsite backups would negate the corruption threat completely I think.
>> Does that sound right?
>
> No, but this is really hard. What if the backup disk has bad bits in
> the block of some file? What if the bits go bad on the machine being
> backed up? What if you then diligently copy those bits for 2 years, and
> only keep 1 year of backups?
That's true, corruption really is still a problem. What can be done?
- Grant
- Re: [rdiff-backup-users] Incremental, automated, remote, secure, Greg Troxel, 2013/07/01
- Re: [rdiff-backup-users] Incremental, automated, remote, secure, Grant, 2013/07/18
- Re: [rdiff-backup-users] Incremental, automated, remote, secure, Greg Troxel, 2013/07/18
- Re: [rdiff-backup-users] Incremental, automated, remote, secure,
Grant <=
- Re: [rdiff-backup-users] Incremental, automated, remote, secure, Greg Troxel, 2013/07/18
- Re: [rdiff-backup-users] Incremental, automated, remote, secure, Grant, 2013/07/18
- Re: [rdiff-backup-users] Incremental, automated, remote, secure, Greg Troxel, 2013/07/18
- Re: [rdiff-backup-users] Incremental, automated, remote, secure, Grant, 2013/07/18
- Re: [rdiff-backup-users] Incremental, automated, remote, secure, Greg Troxel, 2013/07/18
- Re: [rdiff-backup-users] Incremental, automated, remote, secure, Grant, 2013/07/18
- Re: [rdiff-backup-users] Incremental, automated, remote, secure, Dominic Raferd, 2013/07/19
- Re: [rdiff-backup-users] Incremental, automated, remote, secure, Greg Troxel, 2013/07/19
- Re: [rdiff-backup-users] Incremental, automated, remote, secure, Dominic Raferd, 2013/07/19
- Re: [rdiff-backup-users] Incremental, automated, remote, secure, Greg Troxel, 2013/07/19
- Prev by Date:
Re: [rdiff-backup-users] Incremental, automated, remote, secure
- Next by Date:
Re: [rdiff-backup-users] Incremental, automated, remote, secure
- Previous by thread:
Re: [rdiff-backup-users] Incremental, automated, remote, secure
- Next by thread:
Re: [rdiff-backup-users] Incremental, automated, remote, secure
- Index(es):