Fixes for 2.1.0beta1:

[BackupPC.git] / doc-src / BackupPC.pod

diff --git a/doc-src/BackupPC.pod b/doc-src/BackupPC.pod
index 96e6c1f..75bcc63 100644 (file)
--- a/doc-src/BackupPC.pod
+++ b/doc-src/BackupPC.pod
@@ -267,6 +267,11 @@ releases of BackupPC:
 
 =item *
 
 
 =item *
 

+Develop a FAQ and move some significant parts of this document
+to the FAQ (eg: ssh setup, this roadmap etc).  Volunteers?
+
+=item *
+

 Adding hardlink support to rsync.
 
 =item *
 Adding hardlink support to rsync.
 
 =item *


@@ -299,14 +304,15 @@ file size, uid, gid), and better support for include and exclude.
 Currently smbclient incrementals only depend upon mtime, so
 deleted files or renamed files are not detected.  FileSys::SmbClient
 would also allow resuming of incomplete full backups in the
 Currently smbclient incrementals only depend upon mtime, so
 deleted files or renamed files are not detected.  FileSys::SmbClient
 would also allow resuming of incomplete full backups in the

-same manner as rsync will.
+same manner as rsync will.  (I'm not sure if FileSys::SmbClient
+has been updated for samba 3.x.)

 
 =item *
 
 
 =item *
 

-Support --listed-incremental or --incremental for tar,
-so that incrementals will depend upon any attribute change (eg: exist,
-mtime, file size, uid, gid), rather than just mtime.  This will allow
-tar to be to as capable as FileSys::SmbClient and rsync.
+Possibly support --listed-incremental or --incremental for tar, so that
+incrementals will depend upon any attribute change (eg: exist, mtime,
+file size, uid, gid), rather than just mtime.  This will allow tar to
+be to as capable as FileSys::SmbClient and rsync.

 
 =item *
 
 
 =item *
 


@@ -319,6 +325,53 @@ the last, giving a continuous chain of differential dumps.
 
 =item *
 
 
 =item *
 

+Improve the warning messages about locked files on WinXX machines,
+so that more file types than just outlook pst files will produce
+warning emails (and configuration settings for specifying the
+file extensions that produce email warngings).
+
+=item *
+
+Long term, support bare metal restore.  For *nix machines there's
+not a lot to do (althought rsync needs hardlink support).  For
+WinXX machines the file locking problem has to get resolved.
+Plus ACL save/restore would need to be supported.  This is
+really long term.
+
+=item *
+
+Support client pull for restores.  For example, BackupPC could
+emulate an rsync server.  That way you could boot a knoppix cd,
+and you wouldn't need perl, BackupPC, ssh setup or anything on
+the client to restore.  You would just run an rsync command like:
+
+    rsync -aH BackupPCServer::moduleName /path/to/emtpy/disk
+
+ModuleName could contain the client name, share name and backup number.
+There would have to be some way of specifying the password; perhaps
+the CGI could be used to "turn on" rsynd for a specific client and
+a specific time period (eg: only listens for X minutes, only serves
+up a specific client backup, accepts connections from a specific IP).
+BackupPC listens for and serves the request; it's not a real rsyncd on
+the server.
+
+=item *
+
+Add support for wget as an XferMethod.  This would allow ftp and http
+files to be backed up.  This might be useful, for example, for backing
+up the configuration of a router (via http), so that you have a
+backup copy of all the router setup screens in case the router
+fails.
+
+=item *
+
+Possibly support client push for backups, in addition to the
+existing server pull.  This would be helpful for clients behind
+firewalls who can connect to the server, but the server cannot
+see the client.
+
+=item *
+

 More speculative: Storing binary file deltas (in fact, reverse deltas)
 for files that have the same name as a previous backup, but that aren't
 already in the pool. This will save storage for things like mailbox
 More speculative: Storing binary file deltas (in fact, reverse deltas)
 for files that have the same name as a previous backup, but that aren't
 already in the pool. This will save storage for things like mailbox


@@ -2256,6 +2309,15 @@ are using that file).  Again, to avoid race conditions, BackupPC_nightly
 is only run when there are no BackupPC_dump or BackupPC_link processes
 running.
 
 is only run when there are no BackupPC_dump or BackupPC_link processes
 running.
 

+To improve the running time for BackupPC_nightly, several
+BackupPC_nightly processes can be run concurrently, based on
+the $Conf{MaxBackupPCNightlyJobs} setting.
+
+If BackupPC_nightly still takes too long to run,
+$Conf{BackupPCNightlyPeriod} can be used to split
+BackupPC_nightly's pool traversal across multiple nights,
+proportionally reducing its runtime each night.
+

 =back
 
 BackupPC also listens for TCP connections on $Conf{ServerPort}, which
 =back
 
 BackupPC also listens for TCP connections on $Conf{ServerPort}, which