I have found that the use of mbuffer really speeds up the differential
transfer process:
#!/bin/sh
export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:
pool="zroot"
destination="tank"
host="1.2.3.4"
today=`date +"$type-%Y-%m-%d"`
yesterday=`date -v -1d +"$type-%Y-%m-%d"`
#
04.03.2013 19:04, David Magda:
On Mon, March 4, 2013 11:07, Volodymyr Kostyrko wrote:
02.03.2013 03:12, David Magda:
There are quite a few scripts out there:
http://www.freshports.org/search.php?query=zfs
A lot of them require python or ruby, and none of them manages
synchronizing sn
On Mon, March 4, 2013 11:07, Volodymyr Kostyrko wrote:
> 02.03.2013 03:12, David Magda:
>> There are quite a few scripts out there:
>>
>> http://www.freshports.org/search.php?query=zfs
>
> A lot of them require python or ruby, and none of them manages
> synchronizing snapshots over network.
Y
02.03.2013 03:12, David Magda:
On Mar 1, 2013, at 12:55, Volodymyr Kostyrko wrote:
Yes, I'm working with backups the same way, I wrote a simple script that
synchronizes two filesystems between distant servers. I also use the same
script to synchronize bushy filesystems (with hundred thousand
Quoth Phil Regnauld :
>
> > The only risk that makes me uncomfortable doing this is that the pool is
> > always active when the system is running. With UFS backup disks it's
> > not -- except when being actually written to they're unmounted, and this
> > materially decreases the risk of an insane
Karl Denninger (karl) writes:
>
> I think I'm going to play with this and see what I think of it. One
> thing that is very attractive to this design is to have the receiving
> side be a mirror, then to rotate to the vault copy run a scrub (to
> insure that both members are consistent at a checksu
On 3/2/2013 10:23 PM, Ben Morrow wrote:
> Quoth Karl Denninger :
>> Quoth Ben Morrow:
>>> I don't know what medium you're backing up to (does anyone use tape any
>>> more?) but when backing up to disk I much prefer to keep the backup in
>>> the form of a filesystem rather than as 'zfs send' stream
Quoth Karl Denninger :
> Quoth Ben Morrow:
> > I don't know what medium you're backing up to (does anyone use tape any
> > more?) but when backing up to disk I much prefer to keep the backup in
> > the form of a filesystem rather than as 'zfs send' streams. One reason
> > for this is that I believe
Quoth Ben Morrow:
> I don't know what medium you're backing up to (does anyone use tape any
> more?) but when backing up to disk I much prefer to keep the backup in
> the form of a filesystem rather than as 'zfs send' streams. One reason
> for this is that I believe that new versions of the ZFS cod
>The "recommended" approach is to do zfs send | zfs recv and store a
>replica of your pool (with whatever level of RAID that meets your
>needs). This way, you immediately detect an error in the send stream
>and can repeat the send. You then use scrub to verify (and recover)
>the replica.
I do zf
- Original Message -
From: "Karl Denninger"
Reality however is that the on-disk format of most database files is
EXTREMELY compressible (often WELL better than 2:1), so I sacrifice
there. I think the better option is to stuff a user parameter into the
filesystem attribute table (which a
On 3/2/2013 4:14 PM, Peter Jeremy wrote:
> On 2013-Mar-01 08:24:53 -0600, Karl Denninger wrote:
>> If I then restore the base and snapshot, I get back to where I was when
>> the latest snapshot was taken. I don't need to keep the incremental
>> snapshot for longer than it takes to zfs send it, s
On 2013-Mar-01 08:24:53 -0600, Karl Denninger wrote:
>If I then restore the base and snapshot, I get back to where I was when
>the latest snapshot was taken. I don't need to keep the incremental
>snapshot for longer than it takes to zfs send it, so I can do:
>
>zfs snapshot pool/some-filesystem@u
On Mar 1, 2013, at 21:14, Ben Morrow wrote:
> But since ZFS doesn't support POSIX.1e ACLs that's not terribly
> useful... I don't believe bsdtar/libarchive supports NFSv4 ACLs yet.
Ah yes, just noticed that. Thought it did.
https://github.com/libarchive/libarchive/wiki/TarNFS4ACLs
_
On Fri, 01 Mar 2013 18:55:22 +0100, Volodymyr Kostyrko
wrote:
01.03.2013 16:24, Karl Denninger:
Dabbling with ZFS now, and giving some thought to how to handle backup
strategies.
ZFS' snapshot capabilities have forced me to re-think the way that I've
handled this. Previously near-line (and
On Fri, 01 Mar 2013 21:34:39 +0100, Daniel Eischen
wrote:
On Fri, 1 Mar 2013, Ben Morrow wrote:
Quoth Daniel Eischen :
Yes, we still use a couple of DLT autoloaders and have nightly
incrementals and weekly fulls. This is the problem I have with
converting to ZFS. Our typical recovery is
Quoth David Magda :
> On Mar 1, 2013, at 15:39, Daniel Eischen wrote:
> > On Fri, 1 Mar 2013, kpn...@pobox.com wrote:
> >
> >> What about extended attributes? ACLs? Are those saved by tar?
> >
> > I think tar (as root or -p) will attempt to preserve those.
>
> Specifically bsdtar (with libarchiv
On Mar 1, 2013, at 12:55, Volodymyr Kostyrko wrote:
> Yes, I'm working with backups the same way, I wrote a simple script that
> synchronizes two filesystems between distant servers. I also use the same
> script to synchronize bushy filesystems (with hundred thousands of files)
> where rsync p
On Mar 1, 2013, at 15:39, Daniel Eischen wrote:
> On Fri, 1 Mar 2013, kpn...@pobox.com wrote:
>
>> What about extended attributes? ACLs? Are those saved by tar?
>
> I think tar (as root or -p) will attempt to preserve those.
Specifically bsdtar (with libarchive) and star:
https://github.com/l
On Mar 1, 2013, at 12:23, Daniel Eischen wrote:
> dump (and ufsdump for our Solaris boxes) _just work_, and we
> can go back many many years and they will still work. If we
> convert to ZFS, I'm guessing we'll have to do nightly
> incrementals with 'tar' instead of 'dump' as well as doing
> ZFS s
On 3/1/2013 1:25 PM, kpn...@pobox.com wrote:
> On Fri, Mar 01, 2013 at 09:45:32AM -0600, Karl Denninger wrote:
>> I rotate the disaster disks out to a safe-deposit box at the bank, and
>> they're geli-encrypted, so if stolen they're worthless to the thief
>> (other than their cash value as a drive
On Fri, 1 Mar 2013, kpn...@pobox.com wrote:
On Fri, Mar 01, 2013 at 12:23:31PM -0500, Daniel Eischen wrote:
Yes, we still use a couple of DLT autoloaders and have nightly
incrementals and weekly fulls. This is the problem I have with
converting to ZFS. Our typical recovery is when a user says
On 3/1/2013 2:34 PM, Daniel Eischen wrote:
> On Fri, 1 Mar 2013, Ben Morrow wrote:
>
>> Quoth Daniel Eischen :
>>>
>>> Yes, we still use a couple of DLT autoloaders and have nightly
>>> incrementals and weekly fulls. This is the problem I have with
>>> converting to ZFS. Our typical recovery is
On Fri, 1 Mar 2013, Ben Morrow wrote:
Quoth Daniel Eischen :
Yes, we still use a couple of DLT autoloaders and have nightly
incrementals and weekly fulls. This is the problem I have with
converting to ZFS. Our typical recovery is when a user says
they need a directory or set of files from a
On 03/01/2013 1:25 pm, kpn...@pobox.com wrote:
On Fri, Mar 01, 2013 at 09:45:32AM -0600, Karl Denninger wrote:
I rotate the disaster disks out to a safe-deposit box at the bank,
and
they're geli-encrypted, so if stolen they're worthless to the thief
(other than their cash value as a drive) and
Quoth Daniel Eischen :
>
> Yes, we still use a couple of DLT autoloaders and have nightly
> incrementals and weekly fulls. This is the problem I have with
> converting to ZFS. Our typical recovery is when a user says
> they need a directory or set of files from a week or two ago.
> Using dump fr
01.03.2013 16:24, Karl Denninger:
Dabbling with ZFS now, and giving some thought to how to handle backup
strategies.
ZFS' snapshot capabilities have forced me to re-think the way that I've
handled this. Previously near-line (and offline) backup was focused on
being able to handle both disasters
On Fri, 1 Mar 2013, Ben Morrow wrote:
Quoth Karl Denninger :
Dabbling with ZFS now, and giving some thought to how to handle backup
strategies.
[...]
Take a base snapshot immediately and zfs send it to offline storage.
Take an incremental at some interval (appropriate for disaster recovery)
Quoth Karl Denninger :
> Dabbling with ZFS now, and giving some thought to how to handle backup
> strategies.
[...]
>
> Take a base snapshot immediately and zfs send it to offline storage.
> Take an incremental at some interval (appropriate for disaster recovery)
> and zfs send THAT to stable stor
On 3/1/2013 10:08 AM, dweimer wrote:
> On 03/01/2013 9:45 am, Karl Denninger wrote:
>>>
>>> I briefly did something like this between two FreeNAS boxes, it seemed
>>> to work well, but my secondary Box wasn't quite up to par hardware.
>>> Combine that with the lack of necessary internet bandwidth
On 03/01/2013 9:45 am, Karl Denninger wrote:
I briefly did something like this between two FreeNAS boxes, it
seemed
to work well, but my secondary Box wasn't quite up to par hardware.
Combine that with the lack of necessary internet bandwidth with a
second physical location in case of somethin
On 3/1/2013 9:36 AM, dweimer wrote:
> On 03/01/2013 8:24 am, Karl Denninger wrote:
>> Dabbling with ZFS now, and giving some thought to how to handle backup
>> strategies.
>>
>> ZFS' snapshot capabilities have forced me to re-think the way that I've
>> handled this. Previously near-line (and offl
On 03/01/2013 8:24 am, Karl Denninger wrote:
Dabbling with ZFS now, and giving some thought to how to handle backup
strategies.
ZFS' snapshot capabilities have forced me to re-think the way that
I've
handled this. Previously near-line (and offline) backup was focused
on
being able to handle
On Fri, Mar 1, 2013 at 6:06 AM, Ronald Klop wrote:
> On Fri, 01 Mar 2013 15:24:53 +0100, Karl Denninger
> wrote:
>
>> Dabbling with ZFS now, and giving some thought to how to handle backup
>> strategies.
>>
>> ZFS' snapshot capabilities have forced me to re-think the way that I've
>> handled this
On Fri, 01 Mar 2013 15:24:53 +0100, Karl Denninger
wrote:
Dabbling with ZFS now, and giving some thought to how to handle backup
strategies.
ZFS' snapshot capabilities have forced me to re-think the way that I've
handled this. Previously near-line (and offline) backup was focused on
being a
35 matches
Mail list logo
