On 02/19/2010 04:50 PM, Eric Luyten wrote:
> On Tue, February 16, 2010 9:49 am, Eric Luyten wrote:
> <...>
>> ZFS is awesome.
>>
>>
>> We have a ZFS pool composed of nine LUNs on an iSCSI-connected (2 x 1 Gbps)
>> EMC Celerra. All disks are 7200 rpm S-ATA.
>>
>>
>> On our previous storage system (F
a) iSCSI doesn't automatically mean SATA - virtually all iSCSI
enclosures on the market will accept either SAS or SATA. SAS and SATA
were designed that way.
b) iSCSI *can* add a bunch of latency, but not necessarily. It depends
on what's doing the iSCSI processing. Higher-end 1GbE and 10GbE cards
Eric Luyten wrote:
> Our Z pool was 83% full ...
> Deleted the December snapshots, which brought that figure down to 74%
>
> Performance came right back :-)
>
Running close to full you will eventually run into fragmentation
issues. Fortunately
you can grow the size of a pool while it's hot, g
On Tue, February 16, 2010 9:49 am, Eric Luyten wrote:
<...>
> ZFS is awesome.
>
>
> We have a ZFS pool composed of nine LUNs on an iSCSI-connected (2 x 1 Gbps)
> EMC Celerra. All disks are 7200 rpm S-ATA.
>
>
> On our previous storage system (FC-AL connected StorageTek with 15k and 10k
> rpm FC dis
On 16/02/2010 23:26, Vincent Fox wrote:
> Clement Hermann (nodens) wrote:
>> The snapshot approach (we use ext3 and lvm, soon ext4) is promising,
>> as a simple tar is faster than using the full backup suite on a
>> filesystem with a lot of small files (atempo here). But you need the
>> spare space
Hi,
> Is there really a significant downside to performing backups on a hot
> cyrus mailstore? Should I care if Suzie's INBOX was backed up at 3am and
> Sally's INBOX was backed up at 4am?
Whilst Cyrus is running, the state of any databases might be
inconsistent on disk. This will mean you mi
Clement Hermann (nodens) wrote:
> The snapshot approach (we use ext3 and lvm, soon ext4) is promising, as
> a simple tar is faster than using the full backup suite on a filesystem
> with a lot of small files (atempo here). But you need the spare space
> locally, or you need to do it over the net
On 16/02/2010 19:45, Vincent Fox wrote:
> Andrew Morgan wrote:
>> Is there really a significant downside to performing backups on a hot
>> cyrus mailstore? Should I care if Suzie's INBOX was backed up at 3am
>> and Sally's INBOX was backed up at 4am?
>>
>> Vincent, on a slightly related note, what
Andrew Morgan wrote:
> Is there really a significant downside to performing backups on a hot
> cyrus mailstore? Should I care if Suzie's INBOX was backed up at 3am
> and Sally's INBOX was backed up at 4am?
>
> Vincent, on a slightly related note, what is your server and SAN
> hardware?
>
I dunn
On Tue, 16 Feb 2010, Vincent Fox wrote:
> There are other commercial backup solutions however we were
> already a NetBackup shop. So we simply set our backups to run
> against the m...@yesterday path. A locally-written script managing
> the snapshot process rolls @yesterday into a date-coded for
On 02/16/2010 01:48 PM, Michael Bacon wrote:
--On February 16, 2010 9:35:56 AM -0800 Vincent Fox
wrote:
Michael Bacon wrote:
For those of you doing ZFS, what do you use to back up the data after a
zfs snapshot? We're currently on UFS, and would love to go to ZFS, but
haven't figured out how
--On February 16, 2010 9:35:56 AM -0800 Vincent Fox
wrote:
> Michael Bacon wrote:
>> For those of you doing ZFS, what do you use to back up the data after a
>> zfs snapshot? We're currently on UFS, and would love to go to ZFS, but
>> haven't figured out how to replace ufsdump in our backup st
Michael Bacon wrote:
> For those of you doing ZFS, what do you use to back up the data after a zfs
> snapshot? We're currently on UFS, and would love to go to ZFS, but haven't
> figured out how to replace ufsdump in our backup strategy.
>
There are other commercial backup solutions however we
Received wisdom I've had on zfs send and receive is that they're not
production-ready backup solutions, but were basically afterthoughts the zfs
team tacked on.
Michael
--On February 16, 2010 5:46:52 PM +0100 Dietmar Rieder
wrote:
> On 02/16/2010 05:32 PM, Michael Bacon wrote:
>> For those o
On 02/16/2010 05:32 PM, Michael Bacon wrote:
> For those of you doing ZFS, what do you use to back up the data after a zfs
> snapshot? We're currently on UFS, and would love to go to ZFS, but haven't
> figured out how to replace ufsdump in our backup strategy.
what about "zfs send"?
see
man zfs
For those of you doing ZFS, what do you use to back up the data after a zfs
snapshot? We're currently on UFS, and would love to go to ZFS, but haven't
figured out how to replace ufsdump in our backup strategy.
Michael Bacon
ITS Messaging
UNC Chapel Hill
--On February 16, 2010 9:49:07 AM +0100
On Tue, February 16, 2010 12:34 am, John Madden wrote:
> Out of curiousity, how good is zfs with full fs scans when running in
> the 100-million file count range? What do you see in terms of aggregate
> MB/s throughput?
ZFS is awesome.
We have a ZFS pool composed of nine LUNs on an iSCSI-connec
On Mon, February 15, 2010 6:27 pm, Vincent Fox wrote:
> I suppose replication and snapshots are out of the question for you?
>
>
> We run ZFS so snapshots are atomic and nearly instant.
> Thus we keep 14 days of daily snaps in our production pool
> for recovery purposes. In our setup the total of
John Madden wrote:
> Out of curiousity, how good is zfs with full fs scans when running in
> the 100-million file count range? What do you see in terms of
> aggregate MB/s throughput?
>
I'm not sure what you mean by "full fs scan" precisely, and
haven't tested anything very large. Since t
Out of curiousity, how good is zfs with full fs scans when running in
the 100-million file count range? What do you see in terms of
aggregate MB/s throughput?
--
John madden
Sr UNIX Systems Engineer
Ivy Tech Community College of Indiana
jmad...@ivytech.edu
On Feb 15, 2010, at 15:43, "V
John Madden wrote:
>
> We did quite a bit with snapshots (LVM) to when we were experimenting
> with block-level backups but there's a performance problem there -- we
> were saturating GbE. Snapshot doesn't really buy you anything in
> terms of getting the data to tape.
>
>
We run the tape backu
> Our NBU admin runs multiple streams by the way which helped a lot.
> So the various "letters" of the cyrus hashing are each broken out into
> their own full backup. Example out of /var/cyrus/mail/ the subdir
> A-K are in one stream, L-Q in another, etc. I'm not an NBU admin
> so I dunno why t
Vincent Fox wrote:
> I suppose replication and snapshots are out of the question for you?
Replication is something we haven't gotten into yet but there's probably
something there. We don't have a remote site, so there's no way to make
that work in a DR/backup sense.
We did quite a bit with sna
Forgot to mention we are running inline compression on
our ZFS pools. With "fast" LZJB compression on the
filesystems for metadata etc. still a savings of ~2.0.
The inboxes are all in /var/cyrus/mail which is set for
gzip-6 compression savings of ~ 1.7. Backups run
faster so it's win-win.
Combin
John Madden wrote:
> That still leaves full backups as a big issue (they take days to run)
> and NetBackup has a solution for that: You run one full backup and store
> it on disk somewhere and from then on, fulls are called "synthetic
> fulls," where the incrementals are applied periodically in
I suppose replication and snapshots are out of the question for you?
We run ZFS so snapshots are atomic and nearly instant.
Thus we keep 14 days of daily snaps in our production pool
for recovery purposes. In our setup the total of all the snaps
is about a 50% overhead on the production data whic
>> Is there a better strategy , probably within the cyrus framework , to
>> take backups efficiently
We're a large site (400k with 1GB quotas users and growing) and this has
for years been our biggest problem too. Typical backup systems (we run
NetBackup), which scan the entire filesystem looki
On Mon, Feb 15, 2010 at 10:28:13AM +, Gavin McCullagh wrote:
> Hi,
>
> I'm a relative newbie with cyrus, but I'm interested in this discussion...
Hehe - you should read through the mailing list archives for how FastMail
does backups for a really complex but _FAST_ solution :)
> > Things hav
Hi,
Quoting ram :
We have cyrus servers deployed at many places where clients have varying
mail storage.
We have been taking backups to help in situations of human errors
( where you get complaints like ..oops, I accidentaly deleted all my
mails!! ) and in case of hardware failures
Things ha
Hi,
I'm a relative newbie with cyrus, but I'm interested in this discussion...
On Mon, 15 Feb 2010, ram wrote:
> We have cyrus servers deployed at many places where clients have varying
> mail storage.
> We have been taking backups to help in situations of human errors
> ( where you get complai
We have cyrus servers deployed at many places where clients have varying
mail storage.
We have been taking backups to help in situations of human errors
( where you get complaints like ..oops, I accidentaly deleted all my
mails!! ) and in case of hardware failures
Things have been working fine b
31 matches
Mail list logo
