On Mon, Sep 10, 2012 at 08:03:43PM +0300, Andrei POPESCU wrote:
> http://www.taobackup.com/

Yes indeed, great read.

Also this: http://www.jwz.org/doc/backups.html

A single external drive, normally stored away from the server, would be enough
to have a backup that would survive the host going up in flames.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120912125418.GC26534@debian

Denis Witt <denis.witt@concepts-and-training.de> writes:

> Anyway, I have some comparison data. I have a backup server that saves
> data from 5 other server at our hosting company using rsnapshot. The
> backups are kept for 14 days.
>
> rsnapshot:
> bup:
> obnam:
> rdiff-backup:

How about amanda? It hasn't been mentioned yet and might be an
interesting alternative.


--
Debian testing amd64


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87mx0vxk31.fsf@yun.yagibdah.de">http://lists.debian.org/87mx0vxk31.fsf@yun.yagibdah.de

On Tue, Sep 11, 2012 at 04:04:16PM +0200, Ralf Mardorf wrote:
> The cheapest, but anyway reliable German retailer for all kinds of
> electronic gear:
> http://www.reichelt.de/index.html?;ACTION=103;LA=2;MANUFACTURER=adaptec;S ID=12UE9B@H8AAAIAAEcGSWU702e805c66e3a1b7cce75cd098 027793
> Perhaps you'll have good luck and find what you need.
>
> Regards,
> Ralf

Thanks, Ralf.

If I don't find some hardware at local suppliers, I'll try at Reichelt.


Regards,
Veljko


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120913101958.GA8508@angelina.example.org">http://lists.debian.org/20120913101958.GA8508@angelina.example.org

On Tue, Sep 11, 2012 at 08:34:51AM -0500, Stan Hoeppner wrote:
> One of the big reasons (other than cost) that I mentioned this card is
> that Adaptec tends to be more forgiving with non RAID specific
> (ERC/TLER) drives, and lists your Seagate 3TB drives as compatible. LSI
> and other controllers will not work with these drives due to lack of
> RAID specific ERC/TLER.

Those are really valuable informations. I wasn't aware that not all
drives works with RAID cards.

> So now you've run into one of the problems I mentioned that is avoided
> by booting from a real RAID controller.

Yes, but problem was easily solvable.


Regards,
Veljko


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120913102025.GB8508@angelina.example.org">http://lists.debian.org/20120913102025.GB8508@angelina.example.org

On Wed, Sep 12, 2012 at 01:50:04PM +0100, Jon Dowland wrote:
> On Tue, Sep 11, 2012 at 05:44:46PM -0500, Stan Hoeppner wrote:
> > Which is why I recommend XFS. It is exceptionally fast at
> > traversing large btrees. You'll need the 3.2 bpo kernel for
> > Squeeze. The old as dirt 2.6.32 kernel doesn't contain any of the
> > recent (last 3 years) metadata optimizations.
>
> Yes. You are becoming a bit of a broken record on that front
>
> I have not performed any such timings but I am willing to believe you
> that XFS will be faster. I'd still not recommend rsnapshot, because
> faster merely mitigates the big design flaw, it does not remove it,
> and rdiff-backup is virtually a drop-in replacement.
>
Can you please explain what design flaw is that? Isn't directory with
complete backup (but not occupying that much space due to hard links
usage) very usable for backup? If slow work can be avoided by the use of
XFS, what would be wrong about rsnapshot?

Regards,
Veljko


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120913102055.GC8508@angelina.example.org">http://lists.debian.org/20120913102055.GC8508@angelina.example.org

On Wed, Sep 12, 2012 at 01:54:18PM +0100, Jon Dowland wrote:
> On Mon, Sep 10, 2012 at 08:03:43PM +0300, Andrei POPESCU wrote:
> > http://www.taobackup.com/
>
> Yes indeed, great read.
>
> Also this: http://www.jwz.org/doc/backups.html
>
> A single external drive, normally stored away from the server, would be enough
> to have a backup that would survive the host going up in flames.

I'm using this concept for my private machines. I'm always backing up to
remote location.

Regards,
Veljko


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120913102108.GD8508@angelina.example.org">http://lists.debian.org/20120913102108.GD8508@angelina.example.org

On Tue, Sep 11, 2012 at 05:44:46PM -0500, Stan Hoeppner wrote:
> On 9/11/2012 10:29 AM, Jon Dowland wrote:
>
> > Actually, lots and lots of small files is the worst use-case for rsnapshot, and
> > the reason I believe it should be avoided. It creates large hard-link trees and
> > with lots and lots of small files, the filesystem metadata for the trees can
> > consume more space than the files themselves. Also performing operations that
> > need to recurse over large link trees (such as simply removing an old
> > increment) can be very slow in that case.
>
> Which is why I recommend XFS. It is exceptionally fast at traversing
> large btrees. You'll need the 3.2 bpo kernel for Squeeze. The old as
> dirt 2.6.32 kernel doesn't contain any of the recent (last 3 years)
> metadata optimizations.
>
> --
> Stan

Unlike my boss, whom I faild to persuade to buy RAID card, you confince
me to use XFS. I created 1TB LV for backup (and will resize it when
necessary). Will default XFS be OK in my case?

Regards,
Veljko


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120913102131.GE8508@angelina.example.org">http://lists.debian.org/20120913102131.GE8508@angelina.example.org

On Wed, Sep 12, 2012 at 06:49:22PM +0200, lee wrote:
> Denis Witt <denis.witt@concepts-and-training.de> writes:
>
> > Anyway, I have some comparison data. I have a backup server that saves
> > data from 5 other server at our hosting company using rsnapshot. The
> > backups are kept for 14 days.
> >
> > rsnapshot:
> > bup:
> > obnam:
> > rdiff-backup:
>
> How about amanda? It hasn't been mentioned yet and might be an
> interesting alternative.

I've heard of it, but don't know anyone who uses it. Any experience with
it?

Regards,
Veljko


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120913102144.GF8508@angelina.example.org">http://lists.debian.org/20120913102144.GF8508@angelina.example.org

On Wed, Sep 12, 2012 at 10:46:37AM +0200, Denis Witt wrote:
> On Tue, 11 Sep 2012 16:29:22 +0100
> Jon Dowland <jmtd@debian.org> wrote:
>
> > Denis' answer is very good, I won't re-iterate his points.
>
> Thanks. And also thanks for pointing out the Hardlinks thing, I
> over-read the "lots of small files" part in Velkjos Mail.
>
> Anyway, I have some comparison data. I have a backup server that saves
> data from 5 other server at our hosting company using rsnapshot. The
> backups are kept for 14 days.
>
> rsnapshot:
>
> The Backup has 186GB. 51 GB for the full backup (daily.0) and
> about 11GB for each incremental backup (daily.1 - daily.13). The backup
> includes typical small webserver files but also big logfiles and two
> ZOPE Databases (ZEOs) with about 5GB each.
>
> bup:
>
> I imported them with "bup import-rsnapshot", the overall size is 15GB
> (for all 14 days) which is quite amazing. Anyway the lack of a
> possibility to delete old backup versions is (for me) a major drawback.
> What I liked was the possibility to mount the Backup with FUSE. After
> mounting the Backup one can access every backup generation as normal
> files. Each generation has its own folder with a timestamp. The files
> inside the backup have no metadata (timestamp is always 1.1.1970, etc.).
>
> The only way I can think of at the moment to get rid of old backup
> generations using bup is to mount (FUSE) the backup restore all backup
> generations you want to keep to an additional drive, delete the bup git
> repository, create a new one and backup the restore again. Of course
> this might take a lot of additional space on you disk for the
> (temporary) restore which might not be available. If any has some
> better approach I would love to hear.
>
> obnam:
>
> With obnam I made a backup of daily.0 (51GB). There was nearly no
> reduction in the size for the first backup run (47GB). The next backup
> run (one day later, which creates 11GB new data with rsnapshot) has only
> added a few MB and therefore was pretty fast.
>
> The repository approach of obnam comes very handy. You can pull or push
> backups to the repository server and can access the backups from any
> other machine (if you have SSH access). Configuration is not necessary
> but a small config containing some default parameters comes in handy:
>
> [config]
> repository = sftp://192.168.1.10/backup/obnam/
> log = /var/log/obnam.log
> log-level = warning
> client-name = dx
>
> If you now run "obnam backup /var/www" the backup of /var/www will be
> pushed to the repository. obnam locks the repository for the client so
> one cannot accidentally run two backups of the same host (client) at
> the same time. Running several backups of different hosts is no problem.
>
> During a backup run obnam makes "snapshots" every few 100MB so if the
> backup fails (e.g. disconnect from the repository server) the backup
> can be resumed from the last snapshot.
>
> A nice feature is some kind of built in nagios plugin:
>
> obnam nagios-last-backup-age --warn-age=1 --client=dx
> OK: backup is recent. last backup was 2012-09-12 10:05:47.
>
> obnam nagios-last-backup-age --warn-age=1 --client=backup
> WARNING: backup is old. last backup was 2012-09-11 18:03:43.
>
> obnam nagios-last-backup-age --client=cat --critical-age=1
> CRITICAL: backup is old. last backup was 2012-09-11 17:01:23.
>
> The restore is a bit more complex, as there is (at the moment) no FUSE
> filesystem available for obnam. Instead you need to know the name of
> the file/folder and in which backup generation your file/folder exists.
>
> "obnam generations" shows all available backups:
>
> 101 2012-09-11 18:01:07 .. 2012-09-11 18:02:10 (26474 files,
> 8598496965 bytes)
> 108 2012-09-12 10:05:47 .. 2012-09-12 10:06:36 (26474 files,
> 8598500897 bytes)
>
> Then you can use "obnam ls --generation=101" to show the files.
>
> rdiff-backup:
>
> If have no real comparison data for rdiff-backup but I expect similar
> results as with obnam (about 50GB for the first backup, only several MB
> for each following daily backup).
>
> rdiff-backup can (like bup) mount the backup (all generations) using
> FUSE.
>
> Best regards
> Denis Witt

This is excellent comparison. Taking everything in consideration, I
thing I narrowed my choice to obnam, rdiff-backup and rsnapshot. I'll
try them all and see how they behave on my machine.

obnam and rdiff-backup seems to use less space, but I also like very
clear representation of backups on rsnapshot. But during few days of
testing each of them I'll know what to use.

I also stumbled upon this one: http://rbackup.lescigales.org/

Best regards,
Veljko


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120913102245.GG8508@angelina.example.org">http://lists.debian.org/20120913102245.GG8508@angelina.example.org

On 13/09/12 11:21, Veljko wrote:
> On Wed, Sep 12, 2012 at 06:49:22PM +0200, lee wrote:
>> Denis Witt <denis.witt@concepts-and-training.de> writes:
>>
>>> Anyway, I have some comparison data. I have a backup server that saves
>>> data from 5 other server at our hosting company using rsnapshot. The
>>> backups are kept for 14 days.
>>>
>>> rsnapshot:
>>> bup:
>>> obnam:
>>> rdiff-backup:
>>
>> How about amanda? It hasn't been mentioned yet and might be an
>> interesting alternative.
>
> I've heard of it, but don't know anyone who uses it. Any experience with
> it?

When I used tape for backup, I used Amanda, and it did what it was
supposed to do very well, with tape contents indexes, and a media
rotation pattern.

However, in a non-tape environment with only a few machines, I found it
excessively complex, and was happy to abandon it in favour of some
scripts around rsync to a NAS, which is much easier to administer.


--
Tony van der Hoff | mailto:tony@vanderhoff.org
Buckinghamshire, England |


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 5051C085.2030700@vanderhoff.org">http://lists.debian.org/5051C085.2030700@vanderhoff.org