Put stdin data and files in the same snapshot

I’m currently backing up a database and some corresponding files by running

mysqldump ... | restic backup --stdin


restic backup /some/files


This works, but creates two separate snapshots. I’d like to have the DB dump and the files in the same snapshot, as they belong together logically.

When trying

mysqldump ... | restic backup --stdin /some/files

I get the following error:

Fatal: --stdin was specified and files/dirs were listed as arguments

Is there a way to achieve this with restic version 0.9.6 or would this be a new feature?

There’s currently no way to do that. What people do is simply dump the database into a temporary file and include that in the backup run. Can’t you do that?

We just live with separate backups (tagged appropriately, and we use forget --group-by host,tags). There aren’t really any downsides to this approach. It’s pretty rare that you would restore the whole thing in one go. Usually you’d restore the system backup, get the DB service operating again, then import the database dump. Since a two-phase restore is usually required, it doesn’t help much to restore a system+DB snapshot.

Plus you can use restic dump ... | gunzip | mysql to restore without needing temporary files on restore, as well, so you’d need two operations to restore anyway (restore + dump). Putting everything into one snapshot requires that you have enough free disk space to store an entire dump on the DB server.

Having a single snapshot for system+DB just isn’t worth the hassle, IMO.

Thanks for the feedback.

I’d like to avoid temporary files for the DB dump, but I still need identify which dumps and files belong together.

What’s the recommended tagging approach here? Should the tags be the same timestamps?

You can tag them however you want, but I would recommend you use simple tags instead of a novel like description of what you’re backing up. Perhaps system-<yymmddHH> and db-<yymmddHH> or similar (depending on how often you run the backup)? You don’t really need the dates in there as you will have the dates in the snapshot info anyway. Think about how you’d go about restoring, and you’ll find a tagging strategy that is useful.

I use the tags system and database. I’m not sure why you’d need or want the date in the tag; that seems silly. The snapshot already contains the date and time it was taken. If you take backups daily then you can correlate the two snapshots based on the date in the snapshot.