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`
# create
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
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.
Yes, but I
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
On Fri, 01 Mar 2013 21:34:39 +0100, Daniel Eischen deisc...@freebsd.org
wrote:
On Fri, 1 Mar 2013, Ben Morrow wrote:
Quoth Daniel Eischen deisc...@freebsd.org:
Yes, we still use a couple of DLT autoloaders and have nightly
incrementals and weekly fulls. This is the problem I have with
On Fri, 01 Mar 2013 18:55:22 +0100, Volodymyr Kostyrko c.kw...@gmail.com
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.
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 2013-Mar-01 08:24:53 -0600, Karl Denninger k...@denninger.net 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
On 3/2/2013 4:14 PM, Peter Jeremy wrote:
On 2013-Mar-01 08:24:53 -0600, Karl Denninger k...@denninger.net 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
- Original Message -
From: Karl Denninger k...@denninger.net
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
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 zfs send
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 code
Quoth Karl Denninger k...@denninger.net:
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
On 3/2/2013 10:23 PM, Ben Morrow wrote:
Quoth Karl Denninger k...@denninger.net:
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'
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 checksum
Quoth Phil Regnauld regna...@x0.dk:
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
On Fri, 01 Mar 2013 15:24:53 +0100, Karl Denninger k...@denninger.net
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
On Fri, Mar 1, 2013 at 6:06 AM, Ronald Klop ronald-freeb...@klop.yi.org wrote:
On Fri, 01 Mar 2013 15:24:53 +0100, Karl Denninger k...@denninger.net
wrote:
Dabbling with ZFS now, and giving some thought to how to handle backup
strategies.
ZFS' snapshot capabilities have forced me to
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 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 offline)
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
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 with a
Quoth Karl Denninger k...@denninger.net:
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
On Fri, 1 Mar 2013, Ben Morrow wrote:
Quoth Karl Denninger k...@denninger.net:
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
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
Quoth Daniel Eischen deisc...@freebsd.org:
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.
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
On Fri, 1 Mar 2013, Ben Morrow wrote:
Quoth Daniel Eischen deisc...@freebsd.org:
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
On 3/1/2013 2:34 PM, Daniel Eischen wrote:
On Fri, 1 Mar 2013, Ben Morrow wrote:
Quoth Daniel Eischen deisc...@freebsd.org:
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
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
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) and
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
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:
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
Quoth David Magda dma...@ee.ryerson.ca:
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
35 matches
Mail list logo
