Skip to content

sometimes backups are a good idea, even if implemented in a bad way

License

Notifications You must be signed in to change notification settings

ecovillage/sometimes

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

57 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Sometimes

Sometimes backups are good.

Too simple script (tss) to create backups or other regular tasks with file output via ssh.

Only ready to use for the insanest of all people.

Copyright 2018, 2019 Felix Wolfsteller, licensed under the GPLv3 or any later version (see LICENSE file for details).

Installation

Install the gem yourself as:

$ gem install sometimes

Or add this line to your application's Gemfile (but sometimes does not really expose any useful functionality to be used in other Ruby projects):

gem 'sometimes'

And then execute:

$ bundle

General

sometimes can be used like the following:

Two servers exists (called productive and backup). A copy of certain files on the productive server should be made every day (to the backup server). A certain number of these copies should be kept (e.g. copies of the last /three/ days, of the last /two weeks/ and one from the beginning of the year).

The connection shall be made from the backup server to the productive server. This is done via restricted ssh connections.

A cronjob on the backup server will run daily and connect via ssh (password-less key) to the productive server. Via an entry in the authorized_keys file of the relevant user on the productive server it is ensured that just a gzipped tarball is sent over the ssh-connection (and no other stuff can be executed, no tunnels can be created, ...).

The backup server than saves whatever comes out of the ssh-connection to a file with a timestamp as a name.

According to the given storage schedule (e.g. keep last three days copies), outdated old copies are deleted.

While all this behavior can be achieved with cron, rsync, shell-scripts, logrotate and co. this ruby gem tries to abstract some of that functionality (e.g. ssh is called internally) or re-implement it in a worse way (e.g. logrotate works, the storage scheduling in this gem is pretty fake).

Dump structure

# Assume this directory structure:
# $ tree
# .
# ├── filedumps
# │   ├── daily
# │   │   ├── 2018-01-04_2000.tgz
# │   │   └── 2018-01-05_2000.tgz
# │   ├── weekly
# │   │   └── 2018-01-02_2000.tgz
# │   ├── monthly
# │   │   └── 2018-01-01_2000.tgz
# │   ├── yearly
# │   │   ├── 2017-01-01_2000.tgz
# │   │   └── 2018-01-01_2000.tgz
# │   └── last

Configuration/Backup Definition Files

A configuration file (for the moment called BackupDefinition) explains what should be backupped where and how. It is stored in YAML format.

example:

# file exaback.yml
path: /tmp/exaback
key: /tmp/key
comment: exabackup files
store_size:
  daily: 3
  weekly: 2
  monthly: 2
  yearly: 1
user: back-up
host: 12.211.2.1
type: tgz
what: /var/exaback

Usage

  • Set up a dedicated user on the productive server and its permissions.
  • On the backup server, create a configuration file that defines what when where you want to back up.
  • On the backup server, create a directory where the backups should be put.
  • On the backup server, run sometimes-setup-keys -c <path_to_config_file>, which will result in three files:
    • A private key (for password-less connection to productive server)
    • A public key (for password-less connection to productive server)
    • A file with an examplary authorized_keys file line (for the productive server, for restricted and password-less connection)
  • On the backup server, run sometimes-info -c <path_to_config_file> to prove that you are willing to be forced into a weird workflow and off naming but also to create the relevant directories.
  • On the productive server, adjust the ~/.ssh/authorized_keys accordingly
  • On the backup server, install a cronjob, e.g. 0 1 * * * sometimes-execute -c <path_to_config_file>

Multiple entries.

Currently following scenarios (types) are supported:

  • tgz (simple filedump)
  • mysql (plain text file)

Development

After checking out the repo, run bin/setup to install dependencies. Then, run rake test to run the tests. You can also run bin/console for an interactive prompt that will allow you to experiment.

To install this gem onto your local machine, run bundle exec rake install. To release a new version, update the version number in version.rb, and then run bundle exec rake release, which will create a git tag for the version, push git commits and tags, and push the .gem file to rubygems.org.

Contributing

Bug reports and pull requests are welcome on GitHub at https://github.com/ecovillage/sometimes. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the Contributor Covenant code of conduct.

Code of Conduct

Everyone interacting in the Sometimes project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the code of conduct.

About

sometimes backups are a good idea, even if implemented in a bad way

Topics

Resources

License

Code of conduct

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published