3 ms·

> possibly by using sha-256 (or truncated sha256) or make it user selectable on new repositories Honestly I have not found that user-selectability of algorithm

by lucb1e 6y ago

> possibly by using sha-256 (or truncated sha256) or make it user selectable on new repositories Honestly I have not found that user-selectability of algorithms has made anything better. It might be convenient for the developer or a maintainer to somehow be able to change it without recompiling the whole thing, but I wouldn't include security parameters in regular config files that users change. In the 90s this made sense with encryption considered equivalent to ammunition (it still is, but laws have been relaxed) and needing to be changed on the fly, not-so-battle-tested algorithms that you want to quickly switch between, updates coming on CDs, etc. These days, we have security updates coming automatically and we know that some algorithms are pretty much rock solid for the foreseeable future. If one person reads up on it properly and then sets good values, a user (even if that user is a knowledgeable sysadmin) should really not have to tweak it. SHA2 sounds like a good choice, I would just stick with that. Do think about upgrade paths, but assume that you (or a future maintainer) will just provide an update when (if) SHA2 starts to be weakened in similar ways to SHA1. > a number of hosts to one repository Oh that sounds cool, especially with deduplication between them. Restic would be able to do that as well, but they couldn't run concurrently at all and it doesn't really seem to be meant for that sort of thing even if it does store the hostname with each backup ("snapshot"). This would certainly be an interesting feature to a lot of people, I had never even considered using the same repo for multiple systems! > [the sqlite database] should be backed up independently (at the end of the backup script I use sqlite3 commands to do a dump of it once a week [...] Oh, that is a very important gotcha. I would expect that when I made a backup, it contains whatever is needed for it to be restored. Glancing through the results when searching the page for 'database', it doesn't seem to be mentioned. Am I overlooking the backup script you mentioned, or is that just your own backup script and not on the page? > Other features unique to Snebu -- you can have the server "pull" backups without installing an agent on the clients (the "tarcrypt" will still need to be on the client if encryption is needed). You can have the clients "push" data to the server using a restricted user account that allows backups but not deletes or restores, and have a separate restore ID for example. You can give different administrators IDs on the the backup server access to different groups of hosts in a look-but-don't-touch, etc. Ooh that is really fancy! Especially the second one; how is that enforced, I assume with filesystem permissions? Something like allowing to create files but not change existing ones (chmod +w on the directory and chmod -rwx on the files iirc)?

derekp7 6y ago
> I would expect that when I made a backup, it contains whatever is needed for it to be restored The normal use case is for the Sqlite DB (the "backup catalog", labeled as the "meta" directory in /etc/snebu.conf), to be on the same external drive array as the rest of the backup data. And I've found that SQLite is extremely robust, esp. when used with a write-ahead log file (which Snebu does by default). However I found that if you use an external 2.5" USB hard drive, they typically have very bad seek times which makes the DB a constraining factor on performance. In those specific cases I either make sure the "meta" directory is located on a separate small flash drive, or on the backup server itself. >or is that just your own backup script and not on the page Just a simple script running on the backup server for host in host1 host2 host3 host4 do snebu-client backup --remote-client ${host} done cp /var/lib/snebu/catalog/* /var/lib/snebu/vault/catalog-backup/ Basically something like that. In reality it reads a list of hosts from a file, on anything that has an Oracle DB on it gets thrown in hot-backup mode first, and there is a bit more logic to rotate the backup directory to keep a week's worth of DB copies, but so far I think I'm just being paranoid (as I mentioned, SQLite is really solid). I run that daily in cron. As a to-do, I really should either put together a general purpose scheduling script, or add scheduling functionality to the DB where you could add host names, ssh private keys, and backup time. >how is that enforced If you have snebu installed and owned by a non-root user ("snebu") and set-uid, and make /var/lib/snebu owned by the snebu user, then only the snebu user can access it. So when a regular user executes it, the program looks at your EUID vs UID -- if they are different, it looks up your UID in the userpermissions table to see if you are allowed the given function on the given client name. If EUID = UID (if you run snebu as the snebu user, or if it isn't installed suid) then extended permissions aren't enforced by the application (standard file system protections are all that apply). BTW, there is one more trick that I don't have documented, but I will put a front end for it in the next version -- you can sync a backup from one Snebu install to a second one, by using some additional parameters to "listbackups" to give output similar to the documented "find" (so it can be fed into a "newbackup" instance on a target server). And you can issue a "snebu restore" (not "snebu-client restore") which outputs a tar file of that backup that can be fed into the second Snebu instance. Useful for cleanly syncing your on-site instance to an offsite one. But again it is a bit tricky to explain, so I'm working on how to present the functionality in a simple front-end (along with the ability of having the on-site server not encrypted, and encrypt the data on the way to the off-site server). That should be ready for the next minor release.

by lucb1e 6y ago

derekp7 6y ago

> I would expect that when I made a backup, it contains whatever is needed for it to be restored The normal use case is for the Sqlite DB (the "backup catalog", labeled as the "meta" directory in /etc/snebu.conf), to be on the same external drive array as the rest of the backup data. And I've found that SQLite is extremely robust, esp. when used with a write-ahead log file (which Snebu does by default). However I found that if you use an external 2.5" USB hard drive, they typically have very bad seek times which makes the DB a constraining factor on performance. In those specific cases I either make sure the "meta" directory is located on a separate small flash drive, or on the backup server itself. >or is that just your own backup script and not on the page Just a simple script running on the backup server for host in host1 host2 host3 host4 do snebu-client backup --remote-client ${host} done cp /var/lib/snebu/catalog/* /var/lib/snebu/vault/catalog-backup/ Basically something like that. In reality it reads a list of hosts from a file, on anything that has an Oracle DB on it gets thrown in hot-backup mode first, and there is a bit more logic to rotate the backup directory to keep a week's worth of DB copies, but so far I think I'm just being paranoid (as I mentioned, SQLite is really solid). I run that daily in cron. As a to-do, I really should either put together a general purpose scheduling script, or add scheduling functionality to the DB where you could add host names, ssh private keys, and backup time. >how is that enforced If you have snebu installed and owned by a non-root user ("snebu") and set-uid, and make /var/lib/snebu owned by the snebu user, then only the snebu user can access it. So when a regular user executes it, the program looks at your EUID vs UID -- if they are different, it looks up your UID in the userpermissions table to see if you are allowed the given function on the given client name. If EUID = UID (if you run snebu as the snebu user, or if it isn't installed suid) then extended permissions aren't enforced by the application (standard file system protections are all that apply). BTW, there is one more trick that I don't have documented, but I will put a front end for it in the next version -- you can sync a backup from one Snebu install to a second one, by using some additional parameters to "listbackups" to give output similar to the documented "find" (so it can be fed into a "newbackup" instance on a target server). And you can issue a "snebu restore" (not "snebu-client restore") which outputs a tar file of that backup that can be fed into the second Snebu instance. Useful for cleanly syncing your on-site instance to an offsite one. But again it is a bit tricky to explain, so I'm working on how to present the functionality in a simple front-end (along with the ability of having the on-site server not encrypted, and encrypt the data on the way to the off-site server). That should be ready for the next minor release.