zfs discuss - May 2008 - zfs equivalent of ufsdump and ufsrestore

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.

 

Thanks for any suggestions.

 

Joe



This message and its attachments may contain legally privileged or confidential
information.  It is intended solely for the named addressee.  If you are not the
addressee indicated in this message (or responsible for delivery of the message
to the addressee), you may not copy or deliver this message or its attachments
to anyone.  Rather, you should permanently delete this message and its
attachments and kindly notify the sender by reply e-mail.  Any content of this
message and its attachments that does not relate to the official business of
News America Incorporated or its subsidiaries must be taken not to have been
sent or endorsed by any of them.  No warranty is made that the e-mail or
attachment(s) are free from computer virus or other defect.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20080529/5aa21809/attachment.html>

"Poulos, Joe" <JPOULOS at newsamerica.com> 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:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       schilling at fokus.fraunhofer.de     (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Joerg Schilling wrote:
> "Poulos, Joe" <JPOULOS at newsamerica.com> 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

Darren J Moffat <darrenm at opensolaris.org> 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:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       schilling at fokus.fraunhofer.de     (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Joerg Schilling wrote:
> Darren J Moffat <darrenm at opensolaris.org> 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

Darren J Moffat schrieb:
> Joerg Schilling wrote:
>> "Poulos, Joe" <JPOULOS at newsamerica.com> 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

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

| 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

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

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

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 zfs-discuss-request at opensolaris.org:
> Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore
> To: Darren J Moffat <darrenm at opensolaris.org>
> Cc: zfs-discuss at opensolaris.org
> Message-ID: <483EC302.5060409 at maier-komor.de>
> 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

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

Thomas Maier-Komor <thomas at maier-komor.de> 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:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       schilling at fokus.fraunhofer.de     (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Mark Shellenbaum <Mark.Shellenbaum at Sun.COM> wrote:
> Joerg Schilling wrote:
> > Darren J Moffat <darrenm at opensolaris.org> 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:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       schilling at fokus.fraunhofer.de     (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Chris Siebenmann <cks at cs.toronto.edu> 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:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       schilling at fokus.fraunhofer.de     (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

> 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

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

> I''d like to take a backup of a live filesystem without modifying
 > the last  accessed time.

why not take a snapshot?

		Rob

> 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.

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
bill at bfccomputing.com           Cell: 603.252.2606
http://www.bfccomputing.com/    Page: 603.442.1833
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3833 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20080530/83e3c47f/attachment.bin>

On Fri, May 30, 2008 at 12:00 PM, Bill McGonigle <bill at
bfccomputing.com> 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 bhigh at freaks.com
"The good is the enemy of the best." - Nietzsche

"J.P. King" <jpk28 at cam.ac.uk> 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:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       schilling at fokus.fraunhofer.de     (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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.

On Sat, May 31, 2008 at 9:18 AM, David Magda <dmagda at ee.ryerson.ca>
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/

David Magda <dmagda at ee.ryerson.ca> 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:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       schilling at fokus.fraunhofer.de     (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

| 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

Chris Siebenmann <cks at cs.toronto.edu> 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:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       schilling at fokus.fraunhofer.de     (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily