Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
Chris Siebenmann <[EMAIL PROTECTED]> wrote: > | My impression is that the "only" real problem with incrementals from > | ufsdump or star is that you would like to have a database that tells > | you in which incremental a specific file with a specific time stamp > | may be found. > > In our situation here, this is done by the overall backup system > driving ufsdump et al (Amanda in our case). I think this is the best > way, because you don't necessarily want to keep the index on the machine > that you are backing up. You would need to push the Amanda people to support star if you like to backup a filesystem other than UFS. Currently Amanda will use GNU tar with all well known problems with GNU tar based backups (e.g. GNU tar will not always accept it's own archives for restore). Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
| My impression is that the "only" real problem with incrementals from | ufsdump or star is that you would like to have a database that tells | you in which incremental a specific file with a specific time stamp | may be found. In our situation here, this is done by the overall backup system driving ufsdump et al (Amanda in our case). I think this is the best way, because you don't necessarily want to keep the index on the machine that you are backing up. - cks ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
David Magda <[EMAIL PROTECTED]> wrote: > > On May 31, 2008, at 06:03, Joerg Schilling wrote: > > > The other method works as root if you use -atime (see man page) and is > > available since 13 years. > > Would it be possible to assign an RBAC role to a regular user to > accomplish this? If so, would you know which one? > > Historically backups ran as root so that all files and devices could > be accessed without running into ACL issues, but that may no longer > be necessary now. The current interface to reset actime uses an ioctl on the file. If you do it this way, you need root privs in order not to set ctime with this operation. Another (ppossible) way to implement this feature would be a open(2) flag O_NOATIME. There was already a discussion to implement this on Solaris. BTW: I just checked the source asnd it turns out that the ioctl _FIOSATIME is not available in ZFS. It seems that there is a need to enhance the OpenSolaris kernel ;-) Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
On Sat, May 31, 2008 at 9:18 AM, David Magda <[EMAIL PROTECTED]> wrote: > > On May 31, 2008, at 06:03, Joerg Schilling wrote: > >> The other method works as root if you use -atime (see man page) and is >> available since 13 years. > > Would it be possible to assign an RBAC role to a regular user to > accomplish this? If so, would you know which one? You can use "ppriv -D -e star ..." to figure out which privileges you lack to be able to reset the atime. I suspect that in order to perform backups (and reset atime), you would need to have file_dac_read and file_dac_write. A backup program that has those privileges has everything they need to gain full root access. I wish that there was a flag to open(2) to say not to update the atime and that there was a privilege that could be granted to allow this flag without granting file_dac_write. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
On May 31, 2008, at 06:03, Joerg Schilling wrote: > The other method works as root if you use -atime (see man page) and is > available since 13 years. Would it be possible to assign an RBAC role to a regular user to accomplish this? If so, would you know which one? Historically backups ran as root so that all files and devices could be accessed without running into ACL issues, but that may no longer be necessary now. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
"J.P. King" <[EMAIL PROTECTED]> wrote: > > > A cleanly written filesystem provides clean and abstract interfaces to do > > anything you like with the filesystem, it's content and metadata. In such an > > environment, there is no need for a utility that knows the disk layout (like > > ufsdump does). > > I'd like to take a backup of a live filesystem without modifying the last > accessed time. Can star do this? Cos otherwise it has a serious failing > as far as I am concerned. I don't blame star for this, but I observe that > (ufs)dump can do this. There are two ways to do this. The preferred method is to use a snapshot ;-) The other method works as root if you use -atime (see man page) and is available since 13 years. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
On Fri, May 30, 2008 at 12:00 PM, Bill McGonigle <[EMAIL PROTECTED]> wrote: > I'm curious - is the current stream format tagged with a version number? Richard Elling posted something about the send format on 5/14/2008: > To date, the only incompatibility is with send streams created prior > to Nevada build 36 (there probably aren't very many of those, ZFS was > introduced in Nevada build 27), which cannot be received by "zfs receive" > on Nevada build 89 and later. > > Note that this incompatibility doesn't affect Solaris 10 at all. All > s10 releases use the new stream format. > > More details (and instructions on how to resurrect any pre build 36 streams) > can be found here: > > http://opensolaris.org/os/community/on/flag-days/pages/2008042301 -B -- Brandon High [EMAIL PROTECTED] "The good is the enemy of the best." - Nietzsche ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
On May 30, 2008, at 10:49, J.P. King wrote: For _my_ purposes I'd be happy with zfs send/receive, if only it was guaranteed to be compatible between versions. How often are you going to be doing restores from these, and for how long? Since the zfs send/receive stream format has only changed once (IIRC) and OpenSolaris can run under virtualization environments, or on cheap hardware, it seems like you should be able to restore today's 'zfs send' backup just about forever. Syncing atimes onto a brand-new ZFS-version-25 2-exabyte personal storage array in 2014 might be tricky, if nobody's written a ZFS stream version filter by then. I just ask these questions to distinguish what's easy in practice vs. theory. I'm curious - is the current stream format tagged with a version number? -Bill - Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 [EMAIL PROTECTED] Cell: 603.252.2606 http://www.bfccomputing.com/Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf smime.p7s Description: S/MIME cryptographic signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
> Is there a way to efficiently replicating a complete zfs-pool > including all filesystems and snapshots? zfs send -R -R Generate a replication stream package, which will replicate the specified filesystem, and all descendant file sys- tems, up to the named snapshot. When received, all properties, snapshots, des- cendent file systems, and clones are preserved. If the -i or -I flags are used in con- junction with the -R flag, an incremental replication stream is generated. The current values of properties, and current snapshot and file system names are set when the stream is received. If the -F flag is specified when this stream is recieved, snapshots and file systems that do not exist on the sending side are des- troyed. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
> I'd like to take a backup of a live filesystem without modifying > the last accessed time. why not take a snapshot? Rob ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
On 30 May 2008, at 15:49, J.P. King wrote: > For _my_ purposes I'd be happy with zfs send/receive, if only it was > guaranteed to be compatible between versions. I agree that the > inability > to extract single files is an irritation - I am not sure why this is > anything more than an implementation detail, but I haven't gone into > it in > depth. I would presume it is because zfs send/receive works at the block level, below the ZFS POSIX layer - i.e., below the filesystem level. I would guess that a stream is simply a list of the blocks that were modified between the two snapshots, suitable for "re-playing" on another pool. This means that the stream may not contain your entire file. An interesting point regarding this is that send/receive will be optimal in the case of small modifications to very large files, such as database files or large log files. The actual modified/appended blocks would be sent rather than the whole changed file. This may be an important point depending on your file modification patterns. Jonathan ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
> A cleanly written filesystem provides clean and abstract interfaces to do > anything you like with the filesystem, it's content and metadata. In such an > environment, there is no need for a utility that knows the disk layout (like > ufsdump does). I'd like to take a backup of a live filesystem without modifying the last accessed time. Can star do this? Cos otherwise it has a serious failing as far as I am concerned. I don't blame star for this, but I observe that (ufs)dump can do this. In case you are wondering why I would care - it is because we moderately regularly have to deal with hacking incidents. And there is nothing more fustrating than having evidence wiped by a backup solution. Especially if this means that we can't be sure how far back to go in the backups to get a guaranteed clean copy. For _my_ purposes I'd be happy with zfs send/receive, if only it was guaranteed to be compatible between versions. I agree that the inability to extract single files is an irritation - I am not sure why this is anything more than an implementation detail, but I haven't gone into it in depth. > J?rg Julian -- Julian King Computer Officer, University of Cambridge, Unix Support ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
Chris Siebenmann <[EMAIL PROTECTED]> wrote: > The first issue alone makes 'zfs send' completely unsuitable for the > purposes that we currently use ufsdump. I don't believe that we've lost > a complete filesystem in years, but we restore accidentally deleted > files all the time. (And snapshots are not the answer, as it is common > that a user doesn't notice the problem until well after the fact.) My impression is that the "only" real problem with incrementals from ufsdump or star is that you would like to have a database that tells you in which incremental a specific file with a specific time stamp may be found. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
Mark Shellenbaum <[EMAIL PROTECTED]> wrote: > Joerg Schilling wrote: > > Darren J Moffat <[EMAIL PROTECTED]> wrote: > > > >>> The closest equivalent to ufsdump and ufsrestore is "star". > >> I very strongly disagree. The closest ZFS equivalent to ufsdump is 'zfs > >> send'. 'zfs send' like ufsdump has initmiate awareness of the the > >> actual on disk layout and is an integrated part of the filesystem > >> implementation. > > > > I strongly disagree. Like ufsdump, star creates archives that allow a file > > based access. This does not work with zfs send. > > > > But star doesn't support Solaris Extended attributes and ZFS ACLs. This > means you *may* loose critical data if you use star. Whereas zfs send > preserves everything. This is not a result of a failure of star. The fact that star currently does not support all zfs properties has several reasons: - The ACL library interface in libsec was wrong in the first version because people did hot ask me how such a library interface needs to look like. - I have been unable to find discussion partners to develop a useful archive format for extended attributes. The archive format used by Sun tar is not useful as it is based on an outdated TAR extension machanism defined by POSIX in 1988. The format from Sun tar is not extensible and it is not detectable. new features of course need to be implemented using (detectable) methods from POSIX.1-2001. - Finally I was waiting a long time with the star-1.5final release because I thought I may need to change things for the star Solaris integration. Unfortunately it turned out that collaboration at that point did not work. As a result, star-1.5-final has been published 6 weeks ago. Once there is a will for collaboration, things may change quickly Star has been designed to be extensible without limitations. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
Thomas Maier-Komor <[EMAIL PROTECTED]> wrote: > > I very strongly disagree. The closest ZFS equivalent to ufsdump is 'zfs > > send'. 'zfs send' like ufsdump has initmiate awareness of the the > > actual on disk layout and is an integrated part of the filesystem > > implementation. > > > > star is a userland archiver. > > > > The man page for zfs states the following for send: > > The format of the stream is evolving. No backwards compati- > bility is guaranteed. You may not be able to receive your > streams on future versions of ZFS. > > I think this should be taken into account when considering 'zfs send' > for backup purposes... A cleanly written filesystem provides clean and abstract interfaces to do anything you like with the filesystem, it's content and metadata. In such an environment, there is no need for a utility that knows the disk layout (like ufsdump does). Star has the advantage that it can do anything ufsdump can do without knowing about the UFS disk layout and it creates archives that are guaranteed to be readable my any POSIX compliant archiver. You may lose the ability to get all properties and metadata from a backup if you don't use star for extration but any other POSIX archives is able to extract the content of any single file in the archive. If you like to keep backup archives for a longer time, it is a good idea to do this in a well documented POSIX compliant archive format as star does. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
On 29 May 2008, at 17:52, Chris Siebenmann wrote:
> The first issue alone makes 'zfs send' completely unsuitable for the
> purposes that we currently use ufsdump. I don't believe that we've
> lost
> a complete filesystem in years, but we restore accidentally deleted
> files all the time. (And snapshots are not the answer, as it is common
> that a user doesn't notice the problem until well after the fact.)
>
> ('zfs send' to live disks is not the answer, because we cannot afford
> the space, heat, power, disks, enclosures, and servers to spin as many
> disks as we have tape space, especially if we want the fault isolation
> that separate tapes give us. most especially if we have to build a
> second, physically separate machine room in another building to put
> the
> backups in.)
However, the original poster did say they were wanting to backup to
another disk and said they wanted something lightweight/cheap/easy.
zfs send/receive would seem to fit the bill in that case. Let's answer
the question rather than getting into an argument about whether zfs
send/receive is suitable for an enterprise archival solution.
Using snapshots is a useful practice as it costs fairly little in
terms of disk space and provides immediate access to fairly recent,
accidentally deleted files. If one is using snapshots, sending the
streams to the backup pool is a simple procedure. One can then keep as
many snapshots on the backup pool as necessary to provide the amount
of history required. All of the files are kept in identical form on
the backup pool for easy browsing when something needs to be restored.
In event of catastrophic failure of the primary pool, one can quickly
move the backup disk to the primary system and import it as the new
primary pool.
It's a bit-perfect incremental backup strategy that requires no
additional tools.
Jonathan
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
Hi list, I'd recommend using zfs send /receive and use a secondary machine that keeps the received filesystems in a backup pool. This gives you the advantage of being able to scrub your backups. I'd like to add another question: Is there a way to efficiently replicating a complete zfs-pool including all filesystems and snapshots? Since it is currently impossible to change the vdev-structure of a pool the "easiest workaround" would be: 1. create the new pool. 2. create all the filesystems on the new pool 3. send all snapshots from the old pool and receive them in the new pool. If there was a way to do this for a whole pool or at least a full filesystem including history, this could be done with relative ease borrowing some cheap disk space. Any ideas? ralf --- this mail is made from 100% recycled electrons Am 29.05.2008 um 17:40 schrieb [EMAIL PROTECTED]: > Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore > To: Darren J Moffat <[EMAIL PROTECTED]> > Cc: zfs-discuss@opensolaris.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >>> >> >> I very strongly disagree. The closest ZFS equivalent to ufsdump is >> 'zfs >> send'. 'zfs send' like ufsdump has initmiate awareness of the the >> actual on disk layout and is an integrated part of the filesystem >> implementation. >> >> star is a userland archiver. >> > > The man page for zfs states the following for send: > > The format of the stream is evolving. No backwards compati- > bility is guaranteed. You may not be able to receive your > streams on future versions of ZFS. > > I think this should be taken into account when considering 'zfs send' > for backup purposes... > > - Thomas ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
Chris Siebenmann wrote:
> | I very strongly disagree. The closest ZFS equivalent to ufsdump is
> | 'zfs send'. 'zfs send' like ufsdump has initmiate awareness of the
> | the actual on disk layout and is an integrated part of the filesystem
> | implementation.
>
> I must strongly disagree in turn, at least for Solaris 10. 'zfs send'
> suffers from three significant defects:
>
> - you cannot selectively restore files from a 'zfs send' archive;
> restoring is an all or nothing affair.
>
> - incrementals can only be generated relative to a snapshot, which
> means that doing incrementals may require you to use up significant
> amounts of disk space.
>
> - it is currently explicitly documented as not being forward or backwards
> compatible. (I understand that this is not really the case and that this
> change of heart will be officially documented at some point; I hope that
> people will forgive me for not basing a backup strategy on word of future
> changes.)
>
> The first issue alone makes 'zfs send' completely unsuitable for the
> purposes that we currently use ufsdump. I don't believe that we've lost
> a complete filesystem in years, but we restore accidentally deleted
> files all the time. (And snapshots are not the answer, as it is common
> that a user doesn't notice the problem until well after the fact.)
>
> ('zfs send' to live disks is not the answer, because we cannot afford
> the space, heat, power, disks, enclosures, and servers to spin as many
> disks as we have tape space, especially if we want the fault isolation
> that separate tapes give us. most especially if we have to build a
> second, physically separate machine room in another building to put the
> backups in.)
>
It does depend on your requirements. I use ZFS send/receive to save my
stuff
to (multiple) USB drives. One is stored onsite in a fire safe and the other
is stored offsite. There is no requirement that the target device is
spinning
except when you are copying. By using this method, I can follow the
declining price of disks over time: by the time I have 500 GBytes of
pictures,
a 1TByte disk will cost $70.
I have also sent snapshots to DVDs, but in truth tape will be easier because
it can store much more. Contrary to popular belief, tapes are still the
best
long-term storage medium. The commercial backup products work with
ZFS without needing to use the send/receive interfaces.
-- richard
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
Jonathan Hogg wrote: > On 29 May 2008, at 15:51, Thomas Maier-Komor wrote: > > >>> I very strongly disagree. The closest ZFS equivalent to ufsdump is >>> 'zfs >>> send'. 'zfs send' like ufsdump has initmiate awareness of the the >>> actual on disk layout and is an integrated part of the filesystem >>> implementation. >>> >>> star is a userland archiver. >>> >>> >> The man page for zfs states the following for send: >> >> The format of the stream is evolving. No backwards compati- >> bility is guaranteed. You may not be able to receive your >> streams on future versions of ZFS. >> To date, there has been one incompatibility jump, required to fix a bug. For details, see: http://www.opensolaris.org/os/community/on/flag-days/pages/2008042301/ >> I think this should be taken into account when considering 'zfs send' >> for backup purposes... >> > > Presumably, if one is backing up to another disk, one could zfs > receive to a pool on that disk. That way you get simple file-based > access, full history (although it could be collapsed by deleting older > snapshots as necessary), and no worries about stream format changes. > > You can also implement different policies. For example, the backup file system may use compression with gzip-9 while the primary uses no compression for better interactive performance. -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
| I very strongly disagree. The closest ZFS equivalent to ufsdump is
| 'zfs send'. 'zfs send' like ufsdump has initmiate awareness of the
| the actual on disk layout and is an integrated part of the filesystem
| implementation.
I must strongly disagree in turn, at least for Solaris 10. 'zfs send'
suffers from three significant defects:
- you cannot selectively restore files from a 'zfs send' archive;
restoring is an all or nothing affair.
- incrementals can only be generated relative to a snapshot, which
means that doing incrementals may require you to use up significant
amounts of disk space.
- it is currently explicitly documented as not being forward or backwards
compatible. (I understand that this is not really the case and that this
change of heart will be officially documented at some point; I hope that
people will forgive me for not basing a backup strategy on word of future
changes.)
The first issue alone makes 'zfs send' completely unsuitable for the
purposes that we currently use ufsdump. I don't believe that we've lost
a complete filesystem in years, but we restore accidentally deleted
files all the time. (And snapshots are not the answer, as it is common
that a user doesn't notice the problem until well after the fact.)
('zfs send' to live disks is not the answer, because we cannot afford
the space, heat, power, disks, enclosures, and servers to spin as many
disks as we have tape space, especially if we want the fault isolation
that separate tapes give us. most especially if we have to build a
second, physically separate machine room in another building to put the
backups in.)
- cks
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
On 29 May 2008, at 15:51, Thomas Maier-Komor wrote: >> I very strongly disagree. The closest ZFS equivalent to ufsdump is >> 'zfs >> send'. 'zfs send' like ufsdump has initmiate awareness of the the >> actual on disk layout and is an integrated part of the filesystem >> implementation. >> >> star is a userland archiver. >> > > The man page for zfs states the following for send: > > The format of the stream is evolving. No backwards compati- > bility is guaranteed. You may not be able to receive your > streams on future versions of ZFS. > > I think this should be taken into account when considering 'zfs send' > for backup purposes... Presumably, if one is backing up to another disk, one could zfs receive to a pool on that disk. That way you get simple file-based access, full history (although it could be collapsed by deleting older snapshots as necessary), and no worries about stream format changes. Jonathan ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
Darren J Moffat schrieb: > Joerg Schilling wrote: >> "Poulos, Joe" <[EMAIL PROTECTED]> wrote: >> >>> Is there a ZFS equivalent of ufsdump and ufsrestore? >>> >>> >>> >>> Will creating a tar file work with ZFS? We are trying to backup a >>> ZFS file system to a separate disk, and would like to take advantage of >>> something like ufsdump rather than using expensive backup software. >> The closest equivalent to ufsdump and ufsrestore is "star". > > I very strongly disagree. The closest ZFS equivalent to ufsdump is 'zfs > send'. 'zfs send' like ufsdump has initmiate awareness of the the > actual on disk layout and is an integrated part of the filesystem > implementation. > > star is a userland archiver. > The man page for zfs states the following for send: The format of the stream is evolving. No backwards compati- bility is guaranteed. You may not be able to receive your streams on future versions of ZFS. I think this should be taken into account when considering 'zfs send' for backup purposes... - Thomas ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
Joerg Schilling wrote: > Darren J Moffat <[EMAIL PROTECTED]> wrote: > >>> The closest equivalent to ufsdump and ufsrestore is "star". >> I very strongly disagree. The closest ZFS equivalent to ufsdump is 'zfs >> send'. 'zfs send' like ufsdump has initmiate awareness of the the >> actual on disk layout and is an integrated part of the filesystem >> implementation. > > I strongly disagree. Like ufsdump, star creates archives that allow a file > based access. This does not work with zfs send. > But star doesn't support Solaris Extended attributes and ZFS ACLs. This means you *may* loose critical data if you use star. Whereas zfs send preserves everything. -Mark ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
Darren J Moffat <[EMAIL PROTECTED]> wrote: > > The closest equivalent to ufsdump and ufsrestore is "star". > > I very strongly disagree. The closest ZFS equivalent to ufsdump is 'zfs > send'. 'zfs send' like ufsdump has initmiate awareness of the the > actual on disk layout and is an integrated part of the filesystem > implementation. I strongly disagree. Like ufsdump, star creates archives that allow a file based access. This does not work with zfs send. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
Joerg Schilling wrote: > "Poulos, Joe" <[EMAIL PROTECTED]> wrote: > >> Is there a ZFS equivalent of ufsdump and ufsrestore? >> >> >> >> Will creating a tar file work with ZFS? We are trying to backup a >> ZFS file system to a separate disk, and would like to take advantage of >> something like ufsdump rather than using expensive backup software. > > The closest equivalent to ufsdump and ufsrestore is "star". I very strongly disagree. The closest ZFS equivalent to ufsdump is 'zfs send'. 'zfs send' like ufsdump has initmiate awareness of the the actual on disk layout and is an integrated part of the filesystem implementation. star is a userland archiver. -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
"Poulos, Joe" <[EMAIL PROTECTED]> wrote: > Is there a ZFS equivalent of ufsdump and ufsrestore? > > > > Will creating a tar file work with ZFS? We are trying to backup a > ZFS file system to a separate disk, and would like to take advantage of > something like ufsdump rather than using expensive backup software. The closest equivalent to ufsdump and ufsrestore is "star". Star includes the ability do do true incremental dumps/restores using the same basic method as ufsdump/ufsrstore do. Star just uses a portable tar/POSIX.1-2001 based archive to store the results. See "man star" and seach for the sections: INCREMENTAL BACKUPS BACKUP SCHEDULES INCREMENTAL RESTORES SYNCHRONIZING FILESYSTEMS Source: ftp://ftp.berlios.de/pub/star/ A binary package for star-1.5-final is on Blastwave.org Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
