We have one Windows server, which is there for many reasons. Taking backup on windows can be pain, one has to rely on third-party software. We use DeltaCopy, which relies on rsync (an awesome piece of open-source software), statically linked Cygwin libraries/binaries.
It is easy to setup and doesn’t conflict with any existing Cygwin installation.
DeltaCopy has saved us from many disasters(disk failure, etc.), some of those happened during last one month. Had we not taken daily, weekly and monthly backup snapshots, we would have lost months of work.
Thanks to DeltaCopy and developers/company/community behind it. This post is my way of thanking them, by spreading some words.
Using DeltaCopy is very intuitive, however, feel free to leave comments, if you need any help setting it up.
Most of us have heard about “Don’t live with broken windows” or “Broken Window Theory” in software world, through books (Pragmatic Programmers by Andy Hunt and Dave Thomas, The Tipping Point by Malcolm Gladwell) and other sources (wikipedia, blogs, articles, etc).
Like many others, I have also experienced that Broken Window Theory applies to many business and personal-life (and many others) other than software-development.
Over the time I have read books and articles, as listed below to learn more and apply in day to day life. You might following links useful.
In most common early start-up mistakes, Mark Suster talks about very interesting and insightful points. However, I feel like adding one more point, quite known but often taken granted, more specific to software or web start-ups.
If you are a software or web start-up, it’s really important to use the experience of founders (if they are come from technical background) or your core team to have following in order, as soon as possible.
Guidelines and best-practices: code, documentation (wiki), version-control (branching/tagging – when and how?), bug-tracking, testing (unit-tests, functional-tests), deployment, performance objectives and related stuff.
I would not go crazy (get distracted too much) about these initially but have these in place and encourage(mandatory – certain cases) everyone to contribute, follow, discuss and document. It’s lot easier to adapt things at an earlier stage rather than later.
I strongally recommend you to read Martin Fowler‘s article Technical Debt to learn more about the importance of having things in order.
