Cedar Backup is open source software that is provided to you at no cost. It is provided with no warranty, not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. However, that said, someone can usually help you solve whatever problems you might see.
If you experience a problem, your best bet is to file an issue in the issue tracker at GitHub. [1] When the source code was hosted at SourceForge, there was a mailing list. However, it was very lightly used in the last years before I abandoned SourceForge, and I have decided not to replace it.
If you are not comfortable discussing your problem in public or
listing it in a public database, or if you need to send along
information that you do not want made public, then you can write
<support@cedar-solutions.com>
. That mail will go
directly to me. If you write the support address about a bug, a
“scrubbed” bug report will eventually end up in the
public bug database anyway, so if at all possible you should use the
public reporting mechanisms. One of the strengths of the open-source
software development model is its transparency.
Regardless of how you report your problem, please try to provide as much information as possible about the behavior you observed and the environment in which the problem behavior occurred. [2]
In particular, you should provide: the version of Cedar Backup that you are using; how you installed Cedar Backup (i.e. Debian package, source package, etc.); the exact command line that you executed; any error messages you received, including Python stack traces (if any); and relevant sections of the Cedar Backup log. It would be even better if you could describe exactly how to reproduce the problem, for instance by including your entire configuration file and/or specific information about your system that might relate to the problem. However, please do not provide huge sections of debugging logs unless you are sure they are relevant or unless someone asks for them.
Sometimes, the error that Cedar Backup displays can be rather
cryptic. This is because under internal error conditions, the text
related to an exception might get propogated all of the way up to
the user interface. If the message you receive doesn't make much
sense, or if you suspect that it results from an internal error,
you might want to re-run Cedar Backup with the
--stack
option. This forces Cedar Backup to dump
the entire Python stack trace associated with the error, rather
than just printing the last message it received. This is good
information to include along with a bug report, as well.
[2] See Simon Tatham's excellent bug reporting tutorial: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html .