Fwd: Are there any remote backup systems that don't require ssh access??Recommendations?
Sorry, replied not replied-all. I don't do much email ok? ---------- Forwarded message ---------- On Wed, Feb 4, 2009 at 1:26 PM, Srdjan Todorovic <todorovic.s@googlemail.com
wrote:
Hi
2009/2/4 Chris G <cl@isbd.net>:
I still don't think it addresses the problem, unless it's an incremental backup. If someone breaks into 'my' machine (the machine being backed up) then they can send rubbish data to overwrite the good backups can't they? This is the specific possibility I'm trying to protect myself against a bit.
This is the old replication argument - Replication produces hot backups for failure, not backups for bad data. (and also other benefits..)
Now that I remember, there was an article in one of the Linux Format issues where you could use Subversion to hold incremental, versioned, logged home directories.
Anyone tried it in general? Anyone tried it specifically for this kind of backup setup? (or anyone tried other version control software (git?) for this?)
Me, I used a combination of SVN and Tortoise on windows to do "backups" of all my files for quite a long time. The system is perfect for a "smallish number of files" - that is my entire OS has something like 50k files in it, I wouldnt want to commit the lot to SVN ;) The idea is perfect because if I got a virus, that destroyed some files, that would then get automatically backed up, I could just run back to a particular date. I'm not sure about the efficiency of this backup system though. If you have a program that makes large changes to "binary working files" then you would probably end up in troubles.
Interesting thought. One problem would be that it's not automated (you would have to write a log)...
Not too difficult - I had a few shell scripts on cron and windows schedule that ran.
You can do ssh+svn:// so there might be a possibility of using ssh keys if you really wanted.
Which helps on the automatic scripting.
On Wed, Feb 04, 2009 at 02:51:29PM +0000, James Taylor wrote:
Sorry, replied not replied-all. I don't do much email ok? ---------- Forwarded message ---------- On Wed, Feb 4, 2009 at 1:26 PM, Srdjan Todorovic <[1]todorovic.s@googlemail.com> wrote:
Hi
2009/2/4 Chris G <[2]cl@isbd.net>: > I still don't think it addresses the problem, unless it's an > incremental backup. If someone breaks into 'my' machine (the machine > being backed up) then they can send rubbish data to overwrite the good > backups can't they? This is the specific possibility I'm trying to > protect myself against a bit.
This is the old replication argument - Replication produces hot backups for failure, not backups for bad data. (and also other benefits..)
Now that I remember, there was an article in one of the Linux Format issues where you could use Subversion to hold incremental, versioned, logged home directories.
Anyone tried it in general? Anyone tried it specifically for this kind of backup setup? (or anyone tried other version control software (git?) for this?)
Me, I used a combination of SVN and Tortoise on windows to do "backups" of all my files for quite a long time. The system is perfect for a "smallish number of files" - that is my entire OS has something like 50k files in it, I wouldnt want to commit the lot to SVN ;) The idea is perfect because if I got a virus, that destroyed some files, that would then get automatically backed up, I could just run back to a particular date. I'm not sure about the efficiency of this backup system though. If you have a program that makes large changes to "binary working files" then you would probably end up in troubles.
Interesting thought. One problem would be that it's not automated (you would have to write a log)...
Not too difficult - I had a few shell scripts on cron and windows schedule that ran.
You can do ssh+svn:// so there might be a possibility of using ssh keys if you really wanted.
Which helps on the automatic scripting.
Doesn't rdiff-backup do it rather better in some ways as it's specifically designed as a backup system as opposed to being a code control system. It gives you a basic 'replication' backup so its easy to restore in the case of failure of the original but in addition stores a history of changes so that, if you want/need to, you can go and get an older version. You have various controls that allow you to set how long you want to keep the history for as well. -- Chris Green
On 17 Feb 09:10, Chris G wrote:
Doesn't rdiff-backup do it rather better in some ways as it's specifically designed as a backup system as opposed to being a code control system.
It gives you a basic 'replication' backup so its easy to restore in the case of failure of the original but in addition stores a history of changes so that, if you want/need to, you can go and get an older version. You have various controls that allow you to set how long you want to keep the history for as well.
Depends on what you're backing up and what you want out of the backup... (Of course, I'd say that a single svn tree isn't a backup, and that you'd want backups of the svn archive, but hey ;) If you're dealing mostly with text/source code then using svn as the store is a perfectly good idea, and likely to save a fair amount of diskspace as time goes on - only the diffs would be stored, not a whole copy of the file. On the other hand, it means that there's no *easy* way to trim the backup to the last 10 days, for example. (Personally, I have very little in the way of "backups" for much of my stuff... I do, however, tend to have git archives of anything that I might need again in at least 2 places, and they're usually fairly upto date with each other). Cheers, -- Brett Parker
On Tue, Feb 17, 2009 at 09:44:39AM +0000, Brett Parker wrote:
On 17 Feb 09:10, Chris G wrote:
Doesn't rdiff-backup do it rather better in some ways as it's specifically designed as a backup system as opposed to being a code control system.
It gives you a basic 'replication' backup so its easy to restore in the case of failure of the original but in addition stores a history of changes so that, if you want/need to, you can go and get an older version. You have various controls that allow you to set how long you want to keep the history for as well.
Depends on what you're backing up and what you want out of the backup...
(Of course, I'd say that a single svn tree isn't a backup, and that you'd want backups of the svn archive, but hey ;)
If you're dealing mostly with text/source code then using svn as the store is a perfectly good idea, and likely to save a fair amount of diskspace as time goes on - only the diffs would be stored, not a whole copy of the file. On the other hand, it means that there's no *easy* way to trim the backup to the last 10 days, for example.
I think rdiff-backup stores diffs rather than complete copies of changed files so makes similar space savings. I agree completely that for text and source a code repository makes sense because it's characterised for exactly that requirement. -- Chris Green
participants (3)
-
Brett Parker -
Chris G -
James Taylor