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/
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
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:
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.
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/
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
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".
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?
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
On Sunday, 20 January 2019 7:24:33 AM AEDT Andrew Luke Nesbit via luv-main wrote:
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>
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".
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?
Yes.
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?
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).
Some of those disks with backups are stored offsite.
How do you make this decision, and how is this implemented?
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 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
On Wed, 9 Jan 2019, Glenn McIntosh wrote:
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).
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
On Wednesday, 9 January 2019 12:14:47 PM AEDT Tim Connors via luv-main wrote:
On Wed, 9 Jan 2019, Glenn McIntosh wrote:
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).
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. 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 Thu, 10 Jan 2019, Russell Coker wrote:
On Wednesday, 9 January 2019 12:14:47 PM AEDT Tim Connors 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
Thanks Tim and Glenn. Not surprising that rsync could do what I wanted but I just didn't know where to look.
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
participants (4)
-
Andrew Luke Nesbit -
Glenn McIntosh -
Russell Coker -
Tim Connors