[BUGS] Remote backups, imap too

Jerahmy Pocott quakenet1 at optusnet.com.au
Sat Dec 8 18:36:21 EST 2007


On 08/12/2007, at 7:25 AM, Peter Jeremy wrote:

> Hi Jerahmy,
>
> On Sat, Dec 08, 2007 at 05:29:02AM +1100, Jerahmy Pocott wrote:
>> Just looking for some options/suggestions on remote backup tools,
>> I was thinking of using rsync, but then I was thinking maybe it's not
>> really good for backups?
>
> I'd say the first thing you need to decide on is what you want from
> your backups.  When I think "backup", I think of keeping a mixture of
> full and incremental backups (probably multiple copies from different
> dates) so that I can recover accidently lost/corrupted files from some
> time in the past as well as recovering from a dead HDD.  OTOH, rsync
> is intended to replicate a directory tree so you have a second copy of
> your directory tree at some point in time.

I inherited a fairly rudimentary backup system of mirroring the entire
filesystem daily, weekly and monthly to separate locations.

My thoughts were to have a weekly and monthly rotation, where each
day changed files would be backed up to a location for the day of the
week, at the end of the week an incremental backup based on the
previous weeks backup would be created (keeping deleted files) then
finally a full backup at the end of the month.

This would give 7 days before each daily was overwritten and 4 weeks
before the weekly, both of these should be accessible as a filesystem.


> Issues that you might want to consider when choosing between different
> tools include:
> - How many backups do you want to keep?
>   It's easier to manage individual files than complete directory  
> trees.

Needs to be entire trees

> - Do you need to compress backups to reduce storage requirements?
>   If yes, then directory trees are probably unsuitable.

Compression isn't needed, except for transport over network would be  
nice..

> - Do you use any fancy metadata options (ACLs, chflags etc)?
>   These may not be replicated using rsync.

Not really required. The files will mostly be accessed via samba server.

> - Do you need to accurately reproduce sparse files?
>   Only dump(8) can do this, though tar/cpio/rsync can handle sparse  
> files,

Unsure, probably not.

> - Do you need to access your backups as a filesystem?
>   If yes, then rsync is the better option

Yes

> - Do your backups need to be accessible/restorable from a different  
> OS?
>   If yes, then dump(8) is probably not a good option.

Accessible yes.

> - What security issues do you need to consider for both storage of the
>   backups and transfer of data between the host and backup server?
>   You may need to consider encryption.

Transfer is via ipsec tunnel.


>> have some of these 'lacie ethernet disk mini' things, they support
>> smb, afp, ftp, bonjour. I had considered using samba to mount them
>
> Of these, FreeBSD can only natively support SMB or FTP, though you can
> probably find an AFP client in ports.  I'm not sure about the other
> *BSD. I've successfully used smbfs (see mount_smbfs) at work, though
> only to read files from a SMB server.  AFAIK, SAMBA does not include a
> filesystem client, only an FTP-like client.
>
> Note that SMB was designed for use over a LAN and I'm not sure how
> well it behaves across a WAN.

My main concern here is how an smbfs mount behaves.. If it works like
a regular mount then that's great, but if it does strange things like  
lock
files or will make rsync think every single file has been changed due
to reporting different file sizes or dates or something, then there  
could
be some nasty issues..

rsync is able to only send the changes in a file over the network, but
can smbfs handle that?

I thought afp might be an attractive option since it is a unix  
filesystem
sharing protocol and understands the permissions etc..

Cheers!


More information about the BUGS mailing list