BackupPC-users

[BackupPC-users] Concrete proposal for feature extension for pooling

2010-03-14 00:52:13
Subject: [BackupPC-users] Concrete proposal for feature extension for pooling
From: Saturn2888 <backuppc-forum AT backupcentral DOT com>
To: backuppc-users AT lists.sourceforge DOT net
Date: Sat, 13 Mar 2010 22:48:40 -0500
I'm still confused on what you meant about the migration system and the 
different digests available. I'd suggest some kind of converter if you are 
allowing us to change the digest as that could cause a lot of issues and some 
people might do it the md5 way and then get a hardware-based SHA processor and 
want to change it for performance reasons.

Jeffery has definitely been answering all the questions I've had about this in 
his posts. I've been thinking about this for months and from what Jeffery's 
asked, you've answered just as descriptively.

Big thing though, Jeffery brought up filesystems that can both compress and 
de-dupe. The two big ones right now are ZFS and BTRFS. In my opinion, ZFS is 
there and ready to be used. It's lzjb compression and block-level de-dupe would 
actually make a lot of what BackupPC does moot. The good thing is, BackupPC is 
portable apart from filesystems, the bad thing is, there is currently no way to 
migrate BackupPC to a filesystem like ZFS and expect great results. The reasons 
you noted, compression killing the block-level de-dupe and ,

To me, BackupPC's compression is much better for storage reasons than lzjb, but 
I'd like to see some hard numbers before anything comes around. The fact that 
there are multiple pools based on compressed data really does this in. There 
has to be a way to move backups between compressed and uncompressed and 
more/less compressed pools or else the benefit of filesystem migration or 
features would be non-existent.

Frankly, I'd love to keep my backups forever, but there's no great way to do 
this yet. There's really no way to synthesize old fulls with the incrementals 
up to the next full so you will end up losing data in the process. Sure, it's 
nice to see the pool size go down for a change, but it's also nice to be able 
to say "here's everything and now I've fused it in a package. Maybe have it so 
just the way backups are viewed, there is a way to access them from full to 
full such as the full and incrementals from 1-19-10 to 2-18-10, and then the 
full and incrementals from 2-19-10 to 3-18-10. I don't know how best to put it.

I've begun moving all of my Windows machines over to Rsyncd and because of the 
emulation of GNU using Cygwin, I'd have to say the performance is far below 
that of Samba on so many fronts. I have had more issues using Rsyncd in Windows 
with BackupPC than I ever had with Samba. My question is, with 4.x, is the 
FileSys::SmbClient support going to be added in? If so, what will be gained by 
using it instead of the standard SmbClient approach?

Are there plans to maybe create the BackupPC client again (I would love this 
idea)?

What about adding support for Unison or creating a way to make Unison 
worthwhile? Frankly, I don't think Unison is very feature-worthy at the moment, 
but I'm sure if people already had Unison servers, having BackupPC manage those 
with its snapshop methodology would be greatly appreciated without having to 
setup Rsyncd on the server.

Is there any hope for customization of Rsyncd such as adding in rsync -z 
compression for wireless or VPN'd clients, allowing passwords to be sent 
encrypted somehow, or for connecting to the Rsyncd client over SSH? If there's 
no benefit to doing that, then oops on my part.

What are the changes, if any, for adding an array of IPs and hostnames and 
priorities on each and even being able to specify if a machine is on IP 
12.34.56.78, that means it's not on the local network and will probably have a 
slower connection to be soft to random disconnections or fluctuations in 
connection speed.

As a side note, I'd like to say I don't condone of using the terminology WinXX 
for a number of reasons:
1. Unnecessary: Win or Windows machines makes more sense than WinXX
2. Redundant: All the Windows up to Windows Vista were XX so by saying WinXX, 
that is not necessarily specifying anything except the exclusion of 3.11 and 
below versions which are probably out of the scope of the documentation anyway.
3. Exclusionary: Windows Vista and Windows 7 do not abide by the XX 
specification making it seem like it's only Win95 to WinXP that is supported by 
BackupPC.
4. Confusing: Not everyone would understand what WinXX means because they might 
think it's a subset of WinXP, a random typo, or a concrete exclusion of the 
Vista+ line of Windows.

+----------------------------------------------------------------------
|This was sent by Saturn2888 AT gmail DOT com via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------



------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/