11

We are migrating from A VMS environment to a Linux environment for some old alpha servers we are decommissioning. The one challenge I have not been able to overcome is file versioning. VMS keeps multiple copies of the same file by using a version flag. I have found multiple options on source forge however I have not found anyone who has experience with any of these in a major production environment. the reson this is needed is because the feeds from other systems do not take unique file names into account. We are trying to keep our scope as light as possible.

Any help is greatly appreciated.

The 2 main ones that appear to be available are:

  • Wayback
  • EtcKeeper - not sure If you can apply it to only one directory or multiple.

Has anyone used these in an enterprise environment? Are there other options I should be considering?

  • not sure that etckeeper can do it, it needs someone to tell it to commit. Unless there is a fuse filesystem for it. Fuse allows user space filesystems, and there for there are many such systems, some overlay systems, such as revision control are available. so worth searching through the available fuse filesystems. – ctrl-alt-delor Dec 13 '13 at 21:12
3

I would look into an actual versioning file system if you're absolutely sure you want this functionality still. Most of them are covered on Wikipedia, titled: Versioning file system. This is the list of options from that article for Linux.

excerpt

No mainstream Linux file system supports versioning, but a number of experimental/research and lesser-known solutions do, namely:

2

You can use copyfs to provide systematic versioning of the files in a file hierarchy. Copyfs keeps all versions of all files. It uses the underlying filesystem of your choice to store the file contents.

Etckeeper isn't the right tool. It's a layer on top of a revision control system designed to do a better job on the system configuration file directory (/etc). Depending on your requirements, you may be able to use a revision control system such as subversion, git, mercurial, etc. These can be useful if you can insert a commit action in your workflow whenever a new version of a file appears.

Another approach may be to rename or move files as they come in. Linux provides the inotify facility to react to filesystem events such as the creation or closing of a file.

  • copyfs website says it is unmaintained. – ivo Welch Mar 3 '15 at 3:55
2

Looking around a few years after this question was asked, none of the versioning file systems listed above are being actively developed or maintained as far as I can tell (happy to be corrected if wrong). The status quo seems to be server / cloud backup, and keep the versioning in the server app. For my backup problems, I think this makes sense: it rolls the problems of off-site backup, versioning, and bulk storage cost into one solution. It simply no longer makes sense to have multiple versions of every document you've touched hogging space on your own filesystem.

For light loads (small files), Github with scheduled commits or auto-commit works.

For bigger things, github helpfully points out

Git is not adequately designed to serve as a backup tool. However, there are many solutions specifically designed for performing backups that are worth checking out, including Arq, Carbonite, Mozy and CrashPlan.

As I write this, of those recommended CrashPlan and Mozy have apps for Linux. Both support versioning, but check the time limits before you buy.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.