hello
what i'm thinking about is:
keep it simple
1.
i'm really happy to throw away all sort of tapes.
when you need them, they are not working, are to slow ore
capacity is too small.
use hd*s instead. they are much faster, bigger, cheaper and data are much safer
on it. for example a external
On Mar 8, 2010, at 7:55 AM, Erik Trimble wrote:
Assume your machine has died the True Death, and you are starting with new
disks (and, at least a similar hardware setup).
I'm going to assume that you named the original snapshot
'rpool/ROOT/whate...@today'
(1) Boot off the OpenSolaris
Let's say for a moment I should go for this solution, with the rpool tucked
away on an usb-stick in the same case as the LTO-3 tapes it matches
timelinewise (I'm using HP C8017A kits) as a zfs send -R to a file on the USB
stick. (If, and that's a big if, I get amanda or bacula to do a job I'm
On 8 mars 2010, at 11:33, Svein Skogen wrote:
Let's say for a moment I should go for this solution, with the rpool tucked
away on an usb-stick in the same case as the LTO-3 tapes it matches
timelinewise (I'm using HP C8017A kits) as a zfs send -R to a file on the
USB stick. (If, and
Svein Skogen wrote:
Let's say for a moment I should go for this solution, with the rpool tucked away on an
usb-stick in the same case as the LTO-3 tapes it matches timelinewise (I'm
using HP C8017A kits) as a zfs send -R to a file on the USB stick. (If, and that's a big
if, I get amanda or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08.03.2010 13:55, Erik Trimble wrote:
Svein Skogen wrote:
Let's say for a moment I should go for this solution, with the rpool
tucked away on an usb-stick in the same case as the LTO-3 tapes it
matches timelinewise (I'm using HP C8017A kits)
And again ...
Is there any work on an upgrade of zfs send/receive to handle resuming on next
media?
I was thinking something along the lines of zfs send (when device goes full)
returning
send suspended. To resume insert new media and issue zfs resume IDNUMBER
and receive handling:
zfs
Svein Skogen wrote:
And again ...
Is there any work on an upgrade of zfs send/receive to handle resuming on next
media?
I was thinking something along the lines of zfs send (when device goes full)
returning
send suspended. To resume insert new media and issue zfs resume IDNUMBER
and
Is there any work on an upgrade of zfs send/receive to handle resuming
on next media?
Please see Darren's post, pasted below.
-Original Message-
From: opensolaris-discuss-boun...@opensolaris.org [mailto:opensolaris-
discuss-boun...@opensolaris.org] On Behalf Of Darren Mackay
Is there any work on an upgrade of zfs send/receive to handle resuming
on next media?
See Darren's post, regarding mkfifo. The purpose is to enable you to use
normal backup tools that support changing tapes, to backup your zfs send
to multiple split tapes. I wonder though - During a restore,
Svein Skogen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04.03.2010 13:18, Erik Trimble wrote:
Svein Skogen wrote:
And again ...
Is there any work on an upgrade of zfs send/receive to handle resuming
on next media?
I was thinking something along the lines of zfs send
Just disregard this thread. I'm resolving the issue using other methods (not
including Solaris).
//Svein
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
To be clear, you can do what you want with the following items (besides
your server):
(1) OpenSolaris LiveCD
(1) 8GB USB Flash drive
As many tapes as you need to store your data pools on.
Make sure the USB drive has a saved stream from your rpool. It should
also have a downloaded copy of
Does this work with dedup? If you have a deduped pool and send it to a file,
will it reflect the smaller size, or will this rehydrate things first?
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
valrh...@gmail.com wrote:
Does this work with dedup?
Does what work? Context, Please! (I'm reading this on webmail with
limited history..)
If you have a deduped pool and send it to a file, will it reflect the smaller size, or
will this rehydrate things first?
That depends on the
On Thu, Mar 4, 2010 at 1:28 PM, valrh...@gmail.com valrh...@gmail.comwrote:
Does this work with dedup? If you have a deduped pool and send it to a
file, will it reflect the smaller size, or will this rehydrate things
first?
zfs send without any options will send the normal (ie non-deduped or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04.03.2010 13:18, Erik Trimble wrote:
Svein Skogen wrote:
And again ...
Is there any work on an upgrade of zfs send/receive to handle resuming
on next media?
I was thinking something along the lines of zfs send (when device goes
full)
On 04/03/2010 21:28, valrh...@gmail.com wrote:
Does this work with dedup? If you have a deduped pool and send it to a file, will it
reflect the smaller size, or will this rehydrate things first?
See zfs(1M) for the description of the -D flag to 'zfs send'.
--
Darren J Moffat
How does this work with an incremental backup?
Right now, I do my incremental backup with:
zfs send -R -i p...@snapshot1 p...@snapshot2 | ssh r...@192.168.1.200 zfs
receive -dF destination_pool
Does it make sense to put a -D in there, and if so, where? THanks!
--
This message posted from
On Mar 4, 2010, at 4:33 AM, Svein Skogen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04.03.2010 13:18, Erik Trimble wrote:
Svein Skogen wrote:
And again ...
Is there any work on an upgrade of zfs send/receive to handle resuming
on next media?
I was thinking something
20 matches
Mail list logo
