Git Product home page Git Product logo

nbackup's Introduction

nBackup

A simple Bash script for making local backups with different views.

Why

Obviously there are a lot of backup solutions that already exist. None of them met my requirements or were far more complicated than I need. I am a fan of the KISS principle and feel backups shouldn't be complex because then recovery is complicated and you don't want complex when shit's hit the fan and you need to recover critical data urgently.

Features

  • dependency-less - backups can be copied to a new system and restored without having to install a slew of programs/dependencies
  • browsable in 3 ways - backups can be viewed/browsed in three different ways right from the command-line:
    1. current - the current version of the backup
    2. snapshot-in-time folders - if you want to view/restore all the data from a specific backup
    3. running file versions - if you want to quickly view previous versions of a specific file
  • delete old backups - old backups can be deleted based on an and or or combination of:
    1. count - keep at least this many old backups
    2. minimum age - keep old backups that are newer than this many seconds, minutes, hours, days, weeks, months, or years
  • e-mail status - status/output sent to e-mail
  • speed over space - storage is cheap, processing time is not; there is no compression, tarring, or encryption (For my use-case, after nBackup takes a backup, I use https://rclone.org to send encrypted copies to my public cloud storage solution.)

How It Works

This script implements the ideas covered here and here. I won't go into the details here -- read the articles if you're curious, but at a high level, the script works by making rsync backups of your data, then using hard-links to identify different versions. By using hard-links you save on space by only saving new copies of files if they have changed.

How To Use It

  1. clone the repo: git clone https://github.com/imthenachoman/nBackup
  2. copy nBackup.includes somewhere and add the folders you do want backed up
  3. copy nBackup.excludes somewhere and add the folders you do not want backed up
  4. copy nBackup.conf to ~/.nBackup.conf and edit per your requirements
  5. make sure BACKUP_INCLUDES_FILE and BACKUP_EXCLUDES_FILE in ~/.nBackup.conf point to correct paths for #2 and #3
  6. secure the permissions for ~/.nBackup.conf:
    1. chmod 600 ~/.nBackup.conf
    2. chown $(whoami):$(whoami) ~/.nBackup.conf
  7. execute nBackup.sh

Example End Result

Assuming your source folder looks like so:

  • source
    • file 001 (inode # 10)
    • file 002 (inode # 20)
    • file 003 (inode # 30)

And you do the following:

  1. take a backup
  2. delete source/file 003, add source/file 004, take a backup
  3. modify source/file 002, add some new files to source/folder 100, take a backup

This is how your backup folder would look:

  • backup
    • 20190101 -- first backup
      • source
        • file 001 (inode # 10)
        • file 002 (inode # 20)
        • file 003 (inode # 30)
    • 20190201 -- second backup; deleted source/file 003 and added source/file 004
      • source
        • file 001 (inode # 10)
        • file 002 (inode # 20)
        • file 004 (inode # 40)
    • 20190301 -- third backup; modifiedsource/file 002 and added some new files to source/folder 100
      • source
        • file 001 (inode # 10)
        • file 002 (inode # 21) -- points to a different file than the previous backups
        • file 004
        • folder 100
          • file 005 (inode # 50)
          • file 006 (inode # 60)
    • current
      • source
        • file 001 (inode # 10)
        • file 002 (inode # 21) -- points to the most recent version of the file
        • file 004 (inode # 40)
        • folder 100
          • file 005 (inode # 50)
          • file 006 (inode # 60)
    • combined
      • source
        • file 001.20190101 (inode # 10)
        • file 002.20190101 (inode # 20)
        • file 002.20190201 (inode # 21) -- notice there are two versions of this file in the same folder so you can quickly find the one you want
        • file 003.20190101 (inode # 30)
        • file 004.20190201 (inode # 40)
        • folder 100
          • file 005.20190301 (inode # 50)
          • file 006.20190301 (inode # 60)

Notice how the files share a common inode. This is because, since the file(s) didn't change, they point to the same file. When a file changes, the old versions point to the original and the new version points to a new file. This saves a lot of space.

Note: The actual file/folders will include date/time stamp but I have removed the time for this example. You can customize the date/time format you want to use.

nbackup's People

Contributors

imthenachoman avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

nbackup's Issues

Varying frequency file removal

In the inspiration you linked they touch on having a unique script call for daily snapshots and lower frequency snapshots.

I would like to implement a varying frequency backup call. For example, in the previous day keep a backup every hour, in the previous week keep a backup every day, in the previous month keep a backup every week, etc.

I can certainly fork the repository and implement this logic. But it would make sense to push the changes upstream.

Given this, how would you approach the logic to cause zero changes to old .conf files?

I can see some changes would be needed in the functions deleteOld<XXX>Backups to include an additional argument to filterFilesToDelete. Additionally I would need to rebuild filterFilesToDelete to account for this logic.

Let me know if you have any ideas, I'll start building on the logic in the week.

Thanks.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.