From owner-freebsd-questions@FreeBSD.ORG Wed Oct 16 11:26:04 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B0F7B226 for ; Wed, 16 Oct 2013 11:26:04 +0000 (UTC) (envelope-from freebsd-questions@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6EEB125A2 for ; Wed, 16 Oct 2013 11:26:04 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VWPEk-0001ZJ-QM for freebsd-questions@freebsd.org; Wed, 16 Oct 2013 13:25:58 +0200 Received: from cs78160219.pp.htv.fi ([62.78.160.219]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Oct 2013 13:25:58 +0200 Received: from jarmo.hurri by cs78160219.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Oct 2013 13:25:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-questions@freebsd.org From: Jarmo Hurri Subject: Re: Dropbox alternative Date: Wed, 16 Oct 2013 14:25:47 +0300 Lines: 62 Message-ID: <874n8hihj8.fsf@syk.fi> References: <86li1uzi1l.fsf@gly.ath.cx> <20131015194632.GB1705@treefort> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: cs78160219.pp.htv.fi User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) Cancel-Lock: sha1:R4rm4laPtJ3RWHVVUev5YKv4Nvs= X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 11:26:04 -0000 yudi v writes: > Out of all the options presented so far, Unison is the one that > closely matches my needs. It's bidirectional, runs on different > platforms (not mobile), and can be used with SSH. > Most other options listed here are of server/client design, they have > their strengths but my main priority is to reduce the risk of data > loss to the absolute minimum. Greetings. My situation is not identical to yours, but there are similarities, so I am offering my 2 cents. The following is most certainly much, much more hassle than any prepackaged system, but I am pleased with the result as far as risk of losing data is concerned, and you did state that your main priority was to reduce the risk of data loss to "the absolute minimum". I had to make similar decisions some time ago. I read about unison, but did not consider it to be industrial strength (tm), so decided to avoid it. I ended up doing the following: - One of my devices is a primary device from which I take backups using rsync. One of these backups is to a local NAS, another to a remote site (I sincerely think that one backup must be physically separated because of fire risks etc.). The local rsync keeps a history using the option --link-dest: http://www.interlinked.org/tutorials/rsync_time_machine.html The remote rsync is to a machine with ZFS keeping a history of 7 days with snapshots. - Rsync has no idea of user actions, so I do not use it to keep the different devices syncronized. It could not handle file corruption. I use a version control system to keep _valuable_ data syncronized: version control knows user actions, and I can access a previous state if something becomes corrupted. I use git, but it could be something else as well. Data is on devices in local repositories, and they share a common remote repository. This remote repo could be anywhere. Some of my remote repos are on github, some of them are elsewhere. I have one repo for system configuration, one for emails, one for a book I am writing etc. Most of my valuable data is text, since at work I use LaTeX, and most of my other stuff is in org mode: http://orgmode.org/ I synchronize the git repos explicitly (manually), but do have some scripts to help the task. For example, one script goes through all git repos and reports if they are not in sync with the remote repo. - Data that is not critical - e.g., music - is not in version control. Such data I upload initially to my primary device, from which it is rsynced to backups, and then I pull it to other machines from the backup if I need it. Have fun! Jarmo