Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

backup should look, feel and behave more 'unixy' #32

Open
bmaeser opened this issue Sep 7, 2015 · 1 comment
Open

backup should look, feel and behave more 'unixy' #32

bmaeser opened this issue Sep 7, 2015 · 1 comment
Labels

Comments

@bmaeser
Copy link

bmaeser commented Sep 7, 2015

i am using 'backup' for a couple of month now and absolutely love it. great tool, thanks for sharing it.
but i think, to use it properly on production servers it should behave more unixy.

just a couple of things:

  • config.rbshould be stored in /etc/backup/config.rb
  • $HOME/.backup/config.rb should extend and overwrite the global configuration in /etc
  • logs should go to /var/log/backup.log and i should be able to change the filename (not only the path)
  • logfile.max_bytes should default to Float::INFINITY (see possibility to disable logfile.max_bytes #31). logrotate does a pretty good job at handling logrotation, and is installed and configured on most systems anyway.
  • global models should go into /etc/backup/models and user-models into $HOME/.backup/models
  • tmp_path should default to somewhere in /tmp
  • data_path should default to somwhere in /var/ or /etc/backup/ (i am not sure here, we can't use /var/backup/ because it is used by debian based systems for internal backups)
  • timestamps in logs and .yaml-files should use system-time, not UTC

this allows a sysadmin to set sane defaults (like mailserver, backupserver,...) systemwide, witch normal system users can use or overwrite.

@tombruijn
Copy link
Member

Yep, it should.

You bring up some valid points and agree with pretty much all of them. These are things we've realized as well and have used in our plan for the next version of backup. This was however, is only a side effect of what is a complete rewrite.

The problem now is that the development on the next version is kind of hit and miss. We've got a working prototype but are experimenting with different approaches from time to time. @meskyanichi and I unfortunately can't dedicate all our free time to it.

I hope to give more updates from time to time, maybe share what we have in mind, but can't promise anything now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants