[DNG] backups from ext4 to ntfs - extended attributes and access control lists

[Edward Bartolo via Dng]

I use fsarchiver. The backup is a single very large file that can be
restored using the same program. You can even restore a partition to a
larger one. Do not backup mounted partitions.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] backups from ext4 to ntfs - extended attributes and access control lists

[spiralofhope]

On 2019-06-14 10:28, Mark Rousell wrote:

Although your notes are all about command line, you might like to add
a link for this handy shell extension to your notes: Link Shell
Extension



Done, thanks.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] backups from ext4 to ntfs - extended attributes and access control lists

[Mark Rousell]

On 12/06/2019 22:15, spiralofhope wrote:
> Notes:
>
>   https://blog.spiralofhope.com/?p=13539

Nicely structured notes.

Although your notes are all about command line, you might like to add a
link for this handy shell extension to your notes: Link Shell Extension



-- 
Mark Rousell
 
 
 

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] backups from ext4 to ntfs - extended attributes and access control lists

[spiralofhope]

On 2019-05-28 15:53, Rick Moen wrote:
[1] Last I heard, Microsoft OSes had nothing quite like a symlink, 
which was
one reason why Cygwin was a bit of a kludge.  (They may have fixed 
that;

I wouldn't know

...

Yes, they are possible.

Notes:

  https://blog.spiralofhope.com/?p=13539

Tested in Windows 10, it's called a "Junction", using:

  mklink  /J
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] backups from ext4 to ntfs - extended attributes and access control lists

[Alexander Bochmann]

...on Tue, May 28, 2019 at 04:17:44PM -0700, Bruce Ferrell wrote:

 > You *could* make a tarball and copy that to NTFS.  Imperfect but no semantic 
 > loss that way

Last I checked, --no-xattrs --no-acls --no-selinux still was the 
default for GNU tar.

So if you want to keep any of those, you need tho enable them, 
as appropriate, when creating or extracting an archive.

Alex.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] backups from ext4 to ntfs - extended attributes and access control lists

[Rick Moen]

Quoting Martin Steigerwald (mar...@lichtvoll.de):

[tip about the stat(1) system utility:]
 
> At the moment not in all cases all the metadata. Recent kernels have an 
> extended statx() syscall that AFAIK is not yet fully supported in user 
> space tools. It will support things like a creation time or the maximum 
> filename length or file size of a filesystem while unlike stat() also being 
> extendable.

Good to know!  Thanks.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] backups from ext4 to ntfs - extended attributes and access control lists

[Martin Steigerwald]

Rick Moen - 29.05.19, 04:14:
> Quoting Bruce Ferrell (bferr...@baywinds.org):
> > I am absolutely astounded by the number of time I've seen *IX
> > "admins" at fortune X companies copy a tree to a windows share and
> > wonder why it's broken when they try to restore from it. NFS, if not
> > done correctly, can do that same thing too. So...
> 
> Reminds me of something I forgot to mention earlier.  Most Linux folks
> have heard of the stat(2) system call, but did you know there's also
> an informative stat(1) system _utility_?  Play with it on diverse
> sorts of file/directory targets, and see how informative it is.  It
> shows in human-readable form _all_ metadata available about any
> filesystem object.

At the moment not in all cases all the metadata. Recent kernels have an 
extended statx() syscall that AFAIK is not yet fully supported in user 
space tools. It will support things like a creation time or the maximum 
filename length or file size of a filesystem while unlike stat() also being 
extendable. Once fully supported desktop environments or cp/rsync and so 
on could bail out on copying a file larger than 4 GiB to a FAT32 
partition instead of copying 4 GiB and then stopping due to an error.

-- 
Martin


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] backups from ext4 to ntfs - extended attributes and access control lists

[Rick Moen]

Quoting Mark Rousell (mark.rous...@signal100.com):

> As an aside: Windows NT has had symlinks in NTFS since Vista, so about
> 12 years.  :-)

Good to know.  Thank you!

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] backups from ext4 to ntfs - extended attributes and access control lists

[Rick Moen]

Quoting tom (t...@206-212-236-243.static.onlinenw.com):

> huh, interesting. I've always just used ext2 on my floppies. still do.

Double-check your calendar.  It might need new batteries.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] backups from ext4 to ntfs - extended attributes and access control lists

[Mark Rousell]

On 28/05/2019 23:53, Rick Moen wrote:
> [1] Last I heard, Microsoft OSes had nothing quite like a symlink,
> which was one reason why Cygwin was a bit of a kludge. (They may have
> fixed that; I wouldn't know, having avoided running their OSes on my
> _won_ machines since Windows for Workground 3.11 in 1992.

As an aside: Windows NT has had symlinks in NTFS since Vista, so about
12 years.  :-)

-- 
Mark Rousell
 
 
 

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] backups from ext4 to ntfs - extended attributes and access control lists

[tom]

On Tue, 28 May 2019 19:14:25 -0700
Rick Moen  wrote:

> Quoting Bruce Ferrell (bferr...@baywinds.org):
> 
> > Sorry Rick... I missed that.
> 
> No worries (as our Australian friends say).
> 
> > I am absolutely astounded by the number of time I've seen *IX
> > "admins" at fortune X companies copy a tree to a windows share and
> > wonder why it's broken when they try to restore from it. NFS, if not
> > done correctly, can do that same thing too. So...
> 
> Reminds me of something I forgot to mention earlier.  Most Linux folks
> have heard of the stat(2) system call, but did you know there's also
> an informative stat(1) system _utility_?  Play with it on diverse
> sorts of file/directory targets, and see how informative it is.  It
> shows in human-readable form _all_ metadata available about any
> filesystem object.
> 
> Around 2001 when I was writing an article for _Linux Journal_ about
> then-new USB flash drives called 'Floppies for the New Millennium', it
> belatedly occurred to me to wonder how the vfat filesystem (typically
> used on flash drives) dealt with storage of native *ix's three time
> stamps (ctime, mtime, atime) on a filesystem (vfat) incapable of
> storing more than a single time stamp.  The answer is logical:  All
> three get instantiated by overloading the single DOS time stamp,
> which thus gets rewritten every time any of them must be updated.
> And, point is, one can observe this kludge at work
> using /usr/bin/stat.
> 
> Anyway, to second what you said:  Any storage target that's not
> Linux-native, and NTFS is case in point, is going to unavoidably
> introduce some degree of silent metadata loss (absent encapsulation,
> such as in a tarball), so beware.
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

huh, interesting. I've always just used ext2 on my floppies. still do.

-- 
 ___ 
/ The onset and the waning of love make \
| themselves felt in the uneasiness |
| experienced at being alone together.  |
|   |
\ -- Jean de la Bruyere /
 --- 
\
 \
   /\   /\   
  //\\_//\\ 
  \_ _//   /
   / * * \/^^^]
   \_\O/_/[   ]
/   \_[   /
\ \_  /  /
 [ [ /  \/ _/
_[ [ \  /_/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] backups from ext4 to ntfs - extended attributes and access control lists

[Rick Moen]

Quoting Bruce Ferrell (bferr...@baywinds.org):

> Sorry Rick... I missed that.

No worries (as our Australian friends say).

> I am absolutely astounded by the number of time I've seen *IX
> "admins" at fortune X companies copy a tree to a windows share and
> wonder why it's broken when they try to restore from it. NFS, if not
> done correctly, can do that same thing too. So...

Reminds me of something I forgot to mention earlier.  Most Linux folks
have heard of the stat(2) system call, but did you know there's also an
informative stat(1) system _utility_?  Play with it on diverse sorts of
file/directory targets, and see how informative it is.  It shows in
human-readable form _all_ metadata available about any filesystem object.

Around 2001 when I was writing an article for _Linux Journal_ about
then-new USB flash drives called 'Floppies for the New Millennium', it
belatedly occurred to me to wonder how the vfat filesystem (typically
used on flash drives) dealt with storage of native *ix's three time
stamps (ctime, mtime, atime) on a filesystem (vfat) incapable of storing
more than a single time stamp.  The answer is logical:  All three get
instantiated by overloading the single DOS time stamp, which thus gets
rewritten every time any of them must be updated.  And, point is, one
can observe this kludge at work using /usr/bin/stat.

Anyway, to second what you said:  Any storage target that's not
Linux-native, and NTFS is case in point, is going to unavoidably
introduce some degree of silent metadata loss (absent encapsulation,
such as in a tarball), so beware.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] backups from ext4 to ntfs - extended attributes and access control lists

[Bruce Ferrell]

On 5/28/19 5:43 PM, Rick Moen wrote:

Quoting Bruce Ferrell (bferr...@baywinds.org):


You *could* make a tarball and copy that to NTFS.  Imperfect but no
semantic loss that way

Not intending to complain, but I literally, actually _just now_ said that:

  I don't know for certain because, frankly, NTFS is so unpromising a
  target for Linux backups that it never would occur to me to try, except,
  if I were absolutely forced to use NTFS as a target, backing up trees
  inside some container archiving format such as tar or cpio that is
  specifically designed to encapsulate *ix metadata.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Sorry Rick... I missed that.

I am absolutely astounded by the number of time I've seen *IX "admins" at fortune X companies copy a tree to a windows share and wonder why it's broken when they try to restore 
from it. NFS, if not done correctly, can do that same thing too. So...


sigh


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] backups from ext4 to ntfs - extended attributes and access control lists

[Rick Moen]

Quoting Bruce Ferrell (bferr...@baywinds.org):

> You *could* make a tarball and copy that to NTFS.  Imperfect but no
> semantic loss that way

Not intending to complain, but I literally, actually _just now_ said that:

 I don't know for certain because, frankly, NTFS is so unpromising a
 target for Linux backups that it never would occur to me to try, except,
 if I were absolutely forced to use NTFS as a target, backing up trees
 inside some container archiving format such as tar or cpio that is
 specifically designed to encapsulate *ix metadata.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] backups from ext4 to ntfs - extended attributes and access control lists

[Bruce Ferrell]

On 5/28/19 3:53 PM, Rick Moen wrote:

Quoting Joel Roth via Dng (dng@lists.dyne.org):


I've been backing up my root ext4 filesystem to ntfs for some time, gettings 
errors
from rsync about failing to copy extended attributes.

Will it affect the ability of my devuan OS or any major
components to function if I lose extended attributes or ACLs?

I think there is an excellent chance you'll suffer semantic loss in
either that area or other types of *ix file metadata, and maybe of
special file types, maybe even symlinks.[1]  Like, have you checked that
rights and ownership are fully preserved?  mtime, ctime, and atime?
I strongly, strongly doubt that.

I don't know for certain because, frankly, NTFS is so unpromising a
target for Linux backups that it never would occur to me to try, except,
if I were absolutely forced to use NTFS as a target, backing up trees
inside some container archiving format such as tar or cpio that is
specifically designed to encapsulate *ix metadata.  (And, even then,
extended file attributes and ACLs are exotic enough that I would test.)



One common use seems to be the immutable flag.

Well, there, you can ask yourself:  Do I or any other UID0 user employ
chattr +i on this system?  I greatly doubt that any Devuan package does
so without sysadmin volition to do so.  But, equally, I'd be astonished
if the immutable flag survives an ordinary transit from ext4 to NTFS and
back (absent extraordinary workarounds to encapsulate file metadata).

[1] Last I heard, Microsoft OSes had nothing quite like a symlink, which was
one reason why Cygwin was a bit of a kludge.  (They may have fixed that;
I wouldn't know, having avoided running their OSes on my _won_ machines
since Windows for Workground 3.11 in 1992.)

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


You *could* make a tarball and copy that to NTFS.  Imperfect but no semantic 
loss that way

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] backups from ext4 to ntfs - extended attributes and access control lists

[Rick Moen]

Quoting Joel Roth via Dng (dng@lists.dyne.org):

> I've been backing up my root ext4 filesystem to ntfs for some time, gettings 
> errors
> from rsync about failing to copy extended attributes.
> 
> Will it affect the ability of my devuan OS or any major
> components to function if I lose extended attributes or ACLs?

I think there is an excellent chance you'll suffer semantic loss in
either that area or other types of *ix file metadata, and maybe of
special file types, maybe even symlinks.[1]  Like, have you checked that
rights and ownership are fully preserved?  mtime, ctime, and atime?  
I strongly, strongly doubt that.

I don't know for certain because, frankly, NTFS is so unpromising a
target for Linux backups that it never would occur to me to try, except,
if I were absolutely forced to use NTFS as a target, backing up trees
inside some container archiving format such as tar or cpio that is
specifically designed to encapsulate *ix metadata.  (And, even then,
extended file attributes and ACLs are exotic enough that I would test.)


> One common use seems to be the immutable flag.

Well, there, you can ask yourself:  Do I or any other UID0 user employ
chattr +i on this system?  I greatly doubt that any Devuan package does
so without sysadmin volition to do so.  But, equally, I'd be astonished
if the immutable flag survives an ordinary transit from ext4 to NTFS and
back (absent extraordinary workarounds to encapsulate file metadata).  

[1] Last I heard, Microsoft OSes had nothing quite like a symlink, which was
one reason why Cygwin was a bit of a kludge.  (They may have fixed that;
I wouldn't know, having avoided running their OSes on my _won_ machines
since Windows for Workground 3.11 in 1992.)

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] backups from ext4 to ntfs - extended attributes and access control lists

[Antony Stone]

On Wednesday 29 May 2019 at 00:11:55, Joel Roth via Dng wrote:

> Hi,
> 
> I've been backing up my root ext4 filesystem to ntfs for some time,

Depending on the purpose of your backup, this may be a poor choice of target 
file system.

> gettings errors from rsync about failing to copy extended attributes.

Indeed.  NTFS has no clue about such things, so although the *content* of the 
backed-up files will be correct, the ownerships, permissions and extended 
attributes will not.

> Will it affect the ability of my devuan OS or any major components to
> function if I lose extended attributes or ACLs?

I would say yes, although I've never dared to try backing up a Linux system to 
NTFS and then trying to restore it again.

> One common use seems to be the immutable flag.

Yes, NTFS will have no clue about that.

I recommend that you back up to an extX (X=2, 3, 4) file system if your plan is 
to be able to restore a working system from it.


I would also comment that *any* backup strategy should start with the 
following three simple steps:

1. make a backup

2. restore that backup to new media (don't over-write the original system)

3. check that the restored system starts, and works as expected

Only after those three steps have shown that your backup mechanism actually 
works should you implement a regular backup of the current system.  Otherwise 
you run a real risk of thinking you have a backup, when in fact you merely 
have a copy of something which might help you to re-create the original 
working system, but isn't something you can simply restore and re-start.


Regards,


Antony.

-- 
The next sentence is untrue.
The previous sentence is also not true.

   Please reply to the list;
 please *don't* CC me.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] backups from ext4 to ntfs - extended attributes and access control lists

[Joel Roth via Dng]

Hi,

I've been backing up my root ext4 filesystem to ntfs for some time, gettings 
errors
from rsync about failing to copy extended attributes.

Will it affect the ability of my devuan OS or any major
components to function if I lose extended attributes or ACLs?

One common use seems to be the immutable flag.

Thanks!

Joel

-- 
Joel Roth
  

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng