Hi experts, as a backup for a data reception service, I am planning to use a logging facility/framework to pipe all received messages to a rolling series of backup files. The format of the received messages is simple, i.e. one line with id, timestamp and a vector of values and very much resembles the common format of log events. The backup files are a safety net to guard against bugs or unintended filtering in the downstream processing pipeline. Looking at Logback, its *RollingFileAppender* and the provided Triggers/Policies, the framework contains everything I need and it is well tested and designed. So I created a customized Logger class that instantiates Appender, Context and Policy/Trigger and also supplies a suitable event *Encoder* to create the messages as single- line strings. After a few tests the basic setup seems to work and I am pleased with the simplicity/flexibility of Logback's API and the overall processing speed. My only concern is robustness im my application scenario so the following questions primarily concern the possibilities of data loss, side effects and log pollution in this special setup. (In other words: Am I using Logback for a purpose that is within its design scope?) 1) Data loss: Is it generally safe to use logback for logging critical data to an external resource or may the framework lose data rows under certain circuumstances? (I don't intend to use Async appenders so far.) 2) Write Exceptions: Do clients of *UnsynchronizedAppenderBase#doAppend* always receive a *LogbackException* if an event could not be written to the log? I there a chance that an Event is not appended without notice? 3) Log pollution: Does Logback write any other messages except the exlicitly passed event to the log file (such as warnings or status messages)? (I've spotted various addWarn/addStatus etc. calls in the Class hierarchy but I am not sure if and where these messages are written to any logging targets). 4) Side effects with global logger configuration: When instantiating an configuring *RollingFileAppender* directly from Java code with a fresh *ContextBase* must I consider any side effects if I also use Logback as my global logging framework (e.g. via logback-classic / sl4j)? 5) Support for binary event encoding: Currently, the logged events are plain text. Am I right to assume that I could liberately encode events in an arbitrary binary format with Logback? (provided I supply a suitable Encoder class) I realize this list of questions might be a bit longer than usual. On the other hand the answers largely depend on Logback's fundamental design decisions and may thus not take too long to answer. Kind regards, Matthias