8 Jan
2019
8 Jan
'19
11:44 p.m.
I use rsync for most of my backups. For a restore I can rsync the files back
and touch /.autorelabel to restore the SE Linux labels. That combination gets
all setuid files etc, but doesn't get file capabilities.
Below is an example. Is there a good way of preserving capabilities apart
from running "getcap /bin/* /sbin/* /usr/bin/* /usr/sbin/*" and storing the
output? Currently /bin/ping seems to be the only commonly used program using
filesystem capability flags. Also is there a way of telling Debian to restore
capabilities apart from "apt-get --reinstall install iputils-ping"?
root@sevm:~# cp -a /bin/ping .
root@sevm:~# rsync -va /bin/ping ping2
sending incremental file list
ping
sent 61,328 bytes received 35 bytes 122,726.00 bytes/sec
total size is 61,240 speedup is 1.00
root@sevm:~# getcap ping ping2
ping = cap_net_raw+ep
root@sevm:~#
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
9 Jan
9 Jan
7:25 a.m.
Dear Russell,
I hope you don't mind me jumping in like this...
On 08/01/2019 12:44, Russell Coker via luv-main wrote:
I use rsync for most of my backups. For a restore I
can rsync the
files back and touch /.autorelabel to restore the SE Linux labels.
Do you mind if I ask you what your backup regime is? I often ask
people when the topic comes up because it's such an important thing.
I'm always interested in potentially improving my knowledge and
practice.
For context: I'm designing a small network with a lot of multimedia
files streaming onto on user computers from local disks and a primary
NAS. I'm investigating options for a backup server. The NAS will
have a backup NAS. And, of course, offsite backups. And archival
backups. Etc.
Thank you for any advice.
Kind regards,
Andrew
--
OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
7:34 a.m.
On Wednesday, 9 January 2019 7:25:35 AM AEDT Andrew Luke Nesbit via luv-main
wrote:
I hope you don't mind me jumping in like this...
On 08/01/2019 12:44, Russell Coker via luv-main wrote:
Firstly I use BTRFS or ZFS for everything that matters. The first stage of
backup is filesystem snapshots, that covers the most common restore case of
"oops I deleted the wrong file".
Next I rsync files to a disk with a BTRFS filesystem and use BTRFS snapshots
on that for multiple backups (going back months or years as most files don't
change much). Some of those disks with backups are stored offsite.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
I use rsync for most of my backups. For a
restore I can rsync the
files back and touch /.autorelabel to restore the SE Linux labels.
Do you mind if I ask you what your backup regime is? I often ask
people when the topic comes up because it's such an important thing.
I'm always interested in potentially improving my knowledge and
practice.
20 Jan
20 Jan
7:24 a.m.
Dear Russell,
On 08/01/2019 20:34, Russell Coker wrote:
On Wednesday, 9 January 2019 7:25:35 AM AEDT Andrew
Luke Nesbit via luv-main
Thank you for explaining this to me/us. I have been thinking about what
you wrote in the hope that the penny would drop, but no such luck so far...
Are you saying that the snapshot _itself_ is literally the first-stage
backup?
Do you mind if I ask you what your backup regime
is? I often ask
people when the topic comes up because it's such an important thing.
I'm always interested in potentially improving my knowledge and
practice.
Firstly I use BTRFS or ZFS for everything that matters. The first stage of
backup is filesystem snapshots, that covers the most common restore case of
"oops I deleted the wrong file". Next I rsync files to a disk with a BTRFS filesystem
and use BTRFS snapshots
on that for multiple backups (going back months or years as most files don't
change much).
Are the files you rsync to the disk with Btrfs are the snapstop files
you mentioned earlier? Or regular files in the "working portion" of the
main disk/array/NAS?
Some of those disks with backups are stored offsite.
How do you make this decision, and how is this implemented?
Kind regards,
Andrew
--
OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
21 Jan
21 Jan
2:31 p.m.
On Sunday, 20 January 2019 7:24:33 AM AEDT Andrew Luke Nesbit via luv-main
wrote:
The snapshot files. If you rsync from the files that are writable you risk
getting inconsistent sets of files, EG a compiled executable with a version of
the source that doesn't match and you also risk inconsistency internally to
files (EG databases in use and filesystem images that are mounted or being
used in VMs).
When I feel like it, or when I'm visiting a relative who has a safe to put
them in. I don't have the type of answer you probably expected.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
On 08/01/2019 20:34, Russell Coker wrote:
Yes.
On Wednesday, 9 January 2019 7:25:35 AM AEDT
Andrew Luke Nesbit via
luv-main>
Thank you for explaining this to me/us. I have been thinking about what
you wrote in the hope that the penny would drop, but no such luck so far...
Are you saying that the snapshot _itself_ is literally the first-stage
backup? Do you mind if I ask you what your backup regime
is? I often ask
people when the topic comes up because it's such an important thing.
I'm always interested in potentially improving my knowledge and
practice.
Firstly I use BTRFS or ZFS for everything that matters. The first stage
of
backup is filesystem snapshots, that covers the most common restore case
of
"oops I deleted the wrong file". Next I rsync
files to a disk with a BTRFS filesystem and use BTRFS
snapshots on that for multiple backups (going back months or years as
most files don't change much).
Are the files you rsync to the disk with Btrfs are the snapstop files
you mentioned earlier? Or regular files in the "working portion" of the
main disk/array/NAS? Some of those
disks with backups are stored offsite.
How do you make this decision, and how is this implemented? 
9 Jan
9 Jan
10:09 a.m.
On 8/1/19 11:44 pm, Russell Coker via luv-main wrote:
Below is an example. Is there a good way of
preserving capabilities apart
from running "getcap /bin/* /sbin/* /usr/bin/* /usr/sbin/*" and storing the
output?
Since the capabilities are stored using extended attributes, then using
the '-X' flag on rsync should do the trick. You may need to be root user
to be able to create these on the destination (or alternatively use
fake-super on rsync).
regards, Glenn
--
pgp: 833A 67F6 1966 EF5F 7AF1 DFF6 75B7 5621 6D65 6D65
12:14 p.m.
On Wed, 9 Jan 2019, Glenn McIntosh wrote:
On 8/1/19 11:44 pm, Russell Coker via luv-main wrote:
rsync flags I frequently see people forget to use on rsync when they want
the destination to be exactly the same as the source:
rsync -HAXS
Bugger, my backup software — BackupPC — doesn't support --sparse (it
actually reimplements some of rsync in perl). Apparently I've never
noticed. As of 13 years ago, hard links weren't supported either, but
that was scheduled to be fixed in the next version. I wonder if it was
fixed by the time my first backup of my current pool was performed in
2008? Meanwhile, where did the intervening years between 2008 and 2018
disappear to?
--
Tim Connors
Below is an example. Is there a good way of
preserving capabilities apart
from running "getcap /bin/* /sbin/* /usr/bin/* /usr/sbin/*" and storing the
output?
Since the capabilities are stored using extended attributes, then using
the '-X' flag on rsync should do the trick. You may need to be root user
to be able to create these on the destination (or alternatively use
fake-super on rsync).
10 Jan
10 Jan
6:46 p.m.
On Wednesday, 9 January 2019 12:14:47 PM AEDT Tim Connors via luv-main wrote:
On Wed, 9 Jan 2019, Glenn McIntosh wrote:
Thanks Tim and Glenn. Not surprising that rsync could do what I wanted but I
just didn't know where to look.
getfattr from the attr package on debian can give a list of xattrs that are in
use.
# getfattr -m - /bin/ping
getfattr: Removing leading '/' from absolute path names
# file: bin/ping
security.capability
security.selinux
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
On 8/1/19 11:44 pm, Russell Coker via luv-main
wrote:
rsync flags I frequently see people forget to use on rsync when they want
the destination to be exactly the same as the source:
rsync -HAXS Below is an example. Is there a good way of
preserving capabilities
apart
from running "getcap /bin/* /sbin/* /usr/bin/* /usr/sbin/*" and storing
the
output?
Since the capabilities are stored using extended attributes, then using
the '-X' flag on rsync should do the trick. You may need to be root user
to be able to create these on the destination (or alternatively use
fake-super on rsync).
6:50 p.m.
On Thu, 10 Jan 2019, Russell Coker wrote:
On Wednesday, 9 January 2019 12:14:47 PM AEDT Tim
Connors via luv-main wrote:
Guess what bit me today when another senior admin moved a bastion host
over to its new location?
Fortunately, thanks to you, this was fresh in my memory and I knew exactly
where to look.
I took the opportunity of making it a teachable moment. I still haven't
convinced the storage admins of same yet though.
--
Tim Connors
rsync flags I frequently see people forget to use
on rsync when they want
the destination to be exactly the same as the source:
rsync -HAXS
Thanks Tim and Glenn. Not surprising that rsync could do what I wanted but I
just didn't know where to look.
1528
days inactive
1541
days old
8 comments
4 participants
participants (4)
-
Andrew Luke Nesbit -
Glenn McIntosh -
Russell Coker -
Tim Connors