> 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"

> 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.