I'd like to see configuration options for separately setting the base directories for dbfilename and appendfilename, as opposed to both of these using the working directory set by dir.

My purpose for this is to be able to perform a BGSAVE and have the dump.rdb created on a separate physical volume from the aof file. I can set dbfilename to an absolute path, however the temp file used for this is using the working dir, which defeats my purpose to an extent :) (The same is true for an aof rewrite.)

Looking at this, it seems the best solution would be to have a aof-dir and rdb-dir option in the config, which would simply default to dir if not set. Then, rdbSave, rdbRemoveTempFile, etc... as well as rewriteAppendOnlyFile[Background], aofRemoveTempFile, etc... could all use a server.[rdb,aof]_dir variable. Then these file operations could be done using full paths instead of relying on paths relative to the working directory.

ETA: If you don't want to add additional configuration options, you could set and use the server.[rdb,aof]_dir variables based on the whether or not the setting for dbfilename and appendfilename is specified as a relative or absolute path.

Comment From: yoav-steinberg

This seems like a decent requirement. Another, perhaps simpler, way to handle it is to use the absolute path as a base location for the temp files. @oranagra WDYT?

Comment From: yossigo

@yoav-steinberg I think the main benefit of having dir and relative paths (possibly excluding ..) is better security, as dir can be mutable and file names can still change.

Comment From: yoav-steinberg

Ok, turns out paths aren't valid filenames anymore (see #1094). Se we should add an option for configuring aof/rdb dirs as originally proposed. PRs welcome...

Comment From: oranagra

if i understand the use case here (using BGSAVE, and not config set save), it is meant to manually extract a snapshot into another storage location (different than where the AOF and possibly the periodic snapshots are stored). the best way to achieve that today IMHO is with redis-cli --rdb, you can configure redis to use repl-diskless-sync, and even run redis-cli on remote computer to extract the rdb file to any storage path you like.

Comment From: yoav-steinberg

@oranagra So maybe one way of looking at this is:

  1. For the RDB backup/manual snapshot we now have the redis-cli and repl-diskless-sync solution. So there's no need to change anything.
  2. For the seperate rdb and aof case, this is becoming non-relevant because of the multipart aof/aof preamble plans which will (correct me if I'm wrong) disable any real use case of having both AOF and periodic RDB snapshots configured at the same time (because any snapshot is also an AOF rewrite).

So if you agree with both above points then we can probably close this ticket.

Comment From: oranagra

i tend to agree. the only reason i see someone would still like to enable both RDB and AOF is if for some reason he wants to avoid short intervals of AOF rewrite so that he can look further back into the history.

i.e. a periodic snapshot can be used as a "snapshot", and AOF used to avoid loosing more than 1 second. in the past (before multi-part aof) AOFRW had a big overhead so you wanted to avoid doing them a lot, but on the other hand it meant longer recovery. but maybe there's some use case for users not to recover to the tail of the AOF, but rather trim it's tail and "undo" the last hour. they can do that with periodic snapshots, but with AOF they can be more accurate about the exact time. see #9326.

after typing all that text, i think the use case is a niche, and i suppose in all others there's no reason to enable both AOF and RDB, so we might not wanna support that. in which case i agree there's no reason for separate dir config.

Comment From: yoav-steinberg

So I'm just referencing #9539 from here so we know that when it's in we won't need this feature anymore. Marking to be closed.