Re-estimating borgmatic projects after looking through the tickets in more details.

Google-Summer-of-Code-2023-Ideas.md

@@ -286,7 +286,7 @@ Other issues tagged [help wanted](https://github.com/borgbackup/borg/issues?q=is
 
 ### Restore a database backup to a different database or server
 **Difficulty**: Easy<br />
-**Length**: 175 hours<br />
+**Length**: 30 hours<br />
 **Skills required**: Python, Linux, relational database administration basics (PostgreSQL and/or MySQL/MariaDB)<br />
 **Description**: Today, borgmatic supports creating database backups and restoring those backups to the same database. However, this doesn't support use cases likes: 1. Running a test restore to another database or server without impacting the production database, or 2. In the event of a database loss, restoring a database to a newly created replacement server with a different hostname and/or credentials.<br />
 **Task outline**: Add command-line support to borgmatic's restore action to override the restored database name, hostname, port username, password, etc. and plumb those values through to the restore commands. Additionally, manually test on all database types borgmatic supports, update the existing documentation, and add/update tests for these features.<br />
@@ -295,7 +295,7 @@ Other issues tagged [help wanted](https://github.com/borgbackup/borg/issues?q=is
 
 ### Wrap all Borg sub-commands with borgmatic actions
 **Difficulty**: Easy<br />
-**Length**: 210 hours<br />
+**Length**: 150 hours<br />
 **Skills required**: Python, Linux<br />
 **Description**: borgmatic is effectively a wrapper around Borg backup, providing additional features like a configuration file, database integration, etc. But borgmatic only wraps a fraction of the sub-commands that Borg provides. And for those that it does wrap, it doesn't necessarily support all command-line flags as borgmatic options. Users can always drop back down to running Borg directly for those missing sub-commands (or use the `borgmatic borg` action), but that doesn't provide all the conveniences of borgmatic and its configuration file.<br />
 **Task outline**: Implement borgmatic actions for all Borg sub-commands that are not yet implemented. For each Borg flag within those sub-commands, decide whether it makes sense to add a new borgmatic configuration option for it—or whether it would be more appropriate as a borgmatic action command-line flag. Also as part of this work, consider implementing missing flags/options on existing borgmatic actions.<br />
@@ -304,7 +304,7 @@ Other issues tagged [help wanted](https://github.com/borgbackup/borg/issues?q=is
 
 ### Backup and restore SQLite databases
 **Difficulty**: Medium<br />
-**Length**: 185 hours<br />
+**Length**: 125 hours<br />
 **Skills required**: Python, Linux, relational database administration basics (especially SQLite)<br />
 **Description**: borgmatic supports creating database backups and restoring those backups for a handful of database types: PostgreSQL, MySQL/MariaDB, and MongoDB. But many users run applications against SQLite databases which, while lighter weight and lacking a daemon process, still are subject to many of the same consistency concerns that a more full-fledged database system has.<br />
 **Task outline**: Implement a borgmatic SQLite database hook (modeled after one of the existing database hooks) so that users can dump and restore consistent SQLite database snapshots with borgmatic. Additionally, update the existing documentation and tests accordingly.<br />
@@ -313,7 +313,7 @@ Other issues tagged [help wanted](https://github.com/borgbackup/borg/issues?q=is
 
 ### Bootstrap a borgmatic restore from nothing
 **Difficulty**: Medium<br />
-**Length**: 200 hours<br />
+**Length**: 80 hours<br />
 **Skills required**: Python, Linux, relational database administration basics (PostgreSQL and/or MySQL/MariaDB)<br />
 **Description**: borgmatic is great for restoring the occasional accidentally deleted file or database, but it's not as streamlined for the use case of spinning up an entire replacement system from nothing in the case of catastrophic server loss. That's because in order to function, borgmatic needs a configuration file with a list of Borg repositories to restore from, databases to restore, credentials, etc. <br />
 **Task outline**: Design and implement a better, more streamlined workflow for bootstrapping the restore of backed up files and databases to a totally blank system. This could include approaches like: 1. Automatically storing borgmatic configuration in a canonical location in any backup archive such that it can be restored or used upon restore, 2. Automatically storing borgmatic database configuration along with each backed up database dump so as to facilitate restore, and/or 3. Implementing a new borgmatic action like `borgmatic bootstrap` to provide the user with an entry point to some of these features. Additionally, update the documentation and tests accordingly.<br />
@@ -322,7 +322,7 @@ Other issues tagged [help wanted](https://github.com/borgbackup/borg/issues?q=is
 
 ### Perform ZFS filesystem snapshots
 **Difficulty**: Hard<br />
-**Length**: 225 hours<br />
+**Length**: 150 hours<br />
 **Skills required**: Python, Linux, relational database administration basics (PostgreSQL and/or MySQL/MariaDB)<br />
 **Description**: borgmatic creates backup archives by reading a collection of files on a filesystem. However, this can result in inconsistent backups if the files change as borgmatic/Borg are reading them, which may pose problems for some users / use cases. A common solution today is to take advantage of the snapshotting capabilities of various filesystems like ZFS to produce a consistent view of the filesystem from a particular point in time, but those snapshots are not natively integrated with borgmatic.<br />
 **Task outline**: Implement native ZFS support in borgmatic such that a snapshot is created before backups occur and then the snapshot is removed / cleaned up afterwards. This should ideally be integrated with borgmatic via a new general-purpose filesystem snapshotting hook internal API (analogous to the existing database hook internal API already in place) so that subsequent projects can support other filesystems. Additionally, update the documentation and tests accordingly.<br />