__color__	__group__	ticket	summary	component	version	type	owner	created	_changetime	_description	_reporter
3	 Release	27	Concurrency Management	component1		enhancement	jesus	1226932266	1226932266	Add the ability to manage concurrency in zetaback backups.  Running against a lot of hosts may require multiple concurrent jobs running.  Zetaback already supports correct function when run concurrently.  This enhancement should add intelligence to the daemon to determine when concurrency is a good idea and when it is not.    Thoughts:     * Launching 8 jobs and having each ssh into every machine to build a todo list is dumb.   * Parallel jobs against the same target host can be self-defeating due to spindle contention (two at the same time but more than twice as slow)   * Consider a ramp up philosophy... start one, measure, if it is not enough double efforts, repeat.  Add a hard configurable limit to concurrency.   * Scanning is not an insignificant effort (getting the remote FS list).  Making that more parallel is self-defeating.  Maybe a local cache of that would be good (1 hour TTL)?	jesus
3	 Release	37	Alert on failures	component1		enhancement	somebody	1274301609	1274301609	When zetaback cannot connect to a system (failed login or no network) there should be an option to generate an alert. The trivial option would be to send email to someone saying that the configured datasets on $host could not be backed up because of $y.	ballen
4	 Release	28	Provide optimal method for backing up the server itself	component1		enhancement	somebody	1227210926	1227210926	It's increasingly likely that Zetaback servers will be deployed where the OS boots from ZFS, and one would want to back up the server's root filesystem and other rpool bits.  This works today, with some caveats:   * The root pool should be on different spindles from the zetaback store, otherwise it doesn't gain anything.   * If the zetaback store is on ZFS, it must be excluded to avoid backing up everything twice.   * The server's public key needs to be in its own .ssh/authorized_keys file.    It would be sweet if we could bypass having to ssh to ourselves, saving non-trivial CPU resources.  We'd need some way to indicate or discover that we're backing up the server itself, and just skip to the zfs send/receive.	esproul
4	 Release	32	Make migration of zetaback servers less painful	component1		enhancement	somebody	1240869244	1240869244	Currently if one wants to move the zetaback server to another host, one must copy all of zetaback's store to the new host before running zetaback on the new host, to avoid doing all full backups (and coalescing all backups, which negatively affects performance.)  This requires a large amount of time for environments with a large amount of data, even in the best case where zfs snapshots can be used to move the data.    A solution to ease migration would be to allow the specification of multiple store locations that would be merged together when scanning for, restoring from or reporting on existing backups.  Only the first specified directory would get new backups.    The use case for migration would be the following:   1. Mount the original store on the new server, perhaps with NFS   1. Disable zetaback from running on the original server   1. Enable zetaback on the new server, with its local store specified first and the remote mount second   1. New backups would be written to the local store, but existing backups would be read from the remote store for evaluating the backup schedule and for doing any required restores or reporting.   1. When the maximum retention period has expired, all backups on the remote store are no longer valid, and the remote store can simply be unmounted and deleted.	esproul
5	 Release	34	Make archives viewable	component1		enhancement	somebody	1246561936	1246561936	Right now, zetaback archives are a one-way street.  Once a backup has been archived, it "disappears" from zetaback's view.  The only way to examine what's in the archive is to look at the filesystem.  However, the on-disk files have the dataset name base64-encoded, so it's not immediately obvious without some shell trickery to see what you've got.    I propose that we add a summary option to view archived backups, with the same simple/expanded choice as one currently has for viewing active backups.  I choose to extend the '-s' option only, since the information from '-l' is (IMHO) too minimal for the archive exploration case.    Use case:   * '-sa' to view a list of archives with timestamp, type and size (same output as '-s')   * '-sax' to view an expanded list of archives, similar to '-sx'	esproul