<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I didn't see anything in your strace logs that would indicate the lustre xattrs were "restored",<br>
rather that they were "created" (as they always are) when the files or directories are created.<br>
<br></blockquote><div><br></div><div>Agreed. The strace output I provided was for the "tar zxvf /scratch.tgz" command that did not extract the xattrs. As you wrote, in that scenario the xattrs were created when the files and directories were extracted/created.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">"trusted.lov" - holds layout for a regular file, or the directory default layout (== lustre.lov)<br>
"trusted.lma" - holds FID for current file, some flags<br>
"trusted.lmv" - holds layout for a striped directory (DNE 2), not present otherwise<br>
"trusted.link" - holds parent directory FID+filename for each link to a file (for lfs fid2path)<br>
<br></blockquote><div><br></div><div>Andreas, time and time again, you are always such a big help in understanding Lustre in depth. Thank you very much for putting together this list of xattrs! Its nice to have a better understanding of how many exist, what they hold, and their names. I hope to see them soon in the Lustre manual - <a class="gmail-issue-link" href="https://jira.hpdd.intel.com/browse/LUDOC-373" id="gmail-key-val" rel="44998" style="font-family:arial,sans-serif;font-size:14px;color:rgb(0,92,158);text-decoration:none">LUDOC-373</a></div><div><br></div><div>Regards,</div><div>Brett</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Cheers, Andreas<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
> On Mon, Mar 20, 2017 at 1:51 AM, Dilger, Andreas <<a href="mailto:andreas.dilger@intel.com">andreas.dilger@intel.com</a>> wrote:<br>
>> On Mar 19, 2017, at 20:57, Brett Lee <<a href="mailto:brettlee.lustre@gmail.com">brettlee.lustre@gmail.com</a>> wrote:<br>
>>><br>
>>> Help from down under! :) Thanks Malcolm!!<br>
>>><br>
>>> Using the correct extract syntax, both directories and files restored with the expected stripe size and stripe count. This means that Zmanda should be able to work as a backup solution for some Lustre file systems, especially if able to using multiple per-directory "agents" to perform backups in parallel.<br>
>><br>
>> I tested this on RHEL7, and it seems tar needs a bit of encouragement to restore Lustre xattrs:<br>
>><br>
>> tar xvf <tarfile> --xattrs-include="lustre.*"<br>
>><br>
>> This will restore the important "lustre.lov" xattr with the file layout (Lustre itself discards the other "lustre.*" xattrs silently) for regular files via mknod+setxattr. It still doesn't restore the default lustre.lov xattr onto the directory, even though it backed those xattrs up.<br>
>><br>
>> Unfortunately, I didn't see the tar process even trying to access any config file like /etc/xattr.conf or /etc/tar.conf whatever, so I don't think there is any way to make this the default without recompiling tar. Sadly, I thought we'd gotten away from this once RHEL6 had patched their tar and GNU tar had added xattr support natively in 1.27, but it seems that we'll need to patch it again. One option would be to add "lustre.*" to the xattrs-include list if extracting to a Lustre filesystem (e.g. checked via statfs() at the start).<br>
>><br>
>> Cheers, Andreas<br>
>><br>
>>> Go Lustre!<br>
>>><br>
>>> Folks, my bad for only checking one source - the 3rd hit via Google for "backup restore xattrs tar":<br>
>>> <a href="https://www.cyberciti.biz/faq/linux-tar-rsync-preserving-acls-selinux-contexts/" rel="noreferrer" target="_blank">https://www.cyberciti.biz/faq/<wbr>linux-tar-rsync-preserving-<wbr>acls-selinux-contexts/</a><br>
>>> I wasn't aware that "tar" was so dynamic in this respect. Alas, this again justifyies the adage "trust, but verify" - and especially with backups.<br>
>>><br>
>>> Brett<br>
>>> --<br>
>>> Protect Yourself Against Cybercrime<br>
>>> PDS Software Solutions LLC<br>
>>> <a href="https://www.TrustPDS.com" rel="noreferrer" target="_blank">https://www.TrustPDS.com</a><br>
>>><br>
>>> On Sun, Mar 19, 2017 at 3:34 PM, Cowe, Malcolm J <<a href="mailto:malcolm.j.cowe@intel.com">malcolm.j.cowe@intel.com</a>> wrote:<br>
>>> The version of tar included in RHEL 7 doesn\u2019t restore the lustre xattrs by default \u2013 you can use the following to extract files with the requisite xattrs:<br>
>>><br>
>>><br>
>>><br>
>>> tar --xattrs-include=lustre.* -xf <backup>.tar<br>
>>><br>
>>><br>
>>><br>
>>> This assumes the files were backed up with the --xattrs flag:<br>
>>><br>
>>><br>
>>><br>
>>> tar --xattrs -cf <backup>.tar <file list><br>
>>><br>
>>><br>
>>><br>
>>> Note, that you don\u2019t appear to need to whitelist the Lustre xattrs when backing up, only when restoring.<br>
>>><br>
>>><br>
>>><br>
>>> Malcolm.<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> From: lustre-discuss <<a href="mailto:lustre-discuss-bounces@lists.lustre.org">lustre-discuss-bounces@lists.<wbr>lustre.org</a>> on behalf of "Dilger, Andreas" <<a href="mailto:andreas.dilger@intel.com">andreas.dilger@intel.com</a>><br>
>>> Date: Monday, 20 March 2017 at 8:11 am<br>
>>> To: Brett Lee <<a href="mailto:brettlee.lustre@gmail.com">brettlee.lustre@gmail.com</a>><br>
>>> Cc: Lustre discussion <<a href="mailto:lustre-discuss@lists.lustre.org">lustre-discuss@lists.lustre.<wbr>org</a>><br>
>>><br>
>>><br>
>>> Subject: Re: [lustre-discuss] Backup software for Lustre<br>
>>><br>
>>><br>
>>><br>
>>> The use of openat() could be problematic since this precludes storing the xattr before the file is opened. That said, I don't see anywhere in your strace log that (f)setxattr() is called to restore the xattrs, for either the regular files or directories, even after the file is opened or written?<br>
>>><br>
>>><br>
>>><br>
>>> Does the RHEL tar have a whitelist of xattrs to be restored? The fact that there are Lustre xattrs after the restore appears to just be normal behavior for creating a file, not anything related to tar restoring xattrs.<br>
>>><br>
>>> Cheers, Andreas<br>
>>><br>
>>><br>
>>><br>
>>> On Mar 19, 2017, at 10:45, Brett Lee <<a href="mailto:brettlee.lustre@gmail.com">brettlee.lustre@gmail.com</a>> wrote:<br>
>>><br>
>>> Sure, happy to help. I did not see mknod+setxattr in the strace output. Included is a trimmed version of the strace output, along with a few more bits of information. Thanks!<br>
>>><br>
>>> # cat /proc/fs/lustre/version<br>
>>> lustre: 2.7.19.8<br>
>>> # cat /etc/redhat-release<br>
>>> CentOS Linux release 7.3.1611 (Core)<br>
>>> # uname -r<br>
>>> 3.10.0-514.2.2.el7_lustre.x86_<wbr>64<br>
>>> # rpm -qa|grep tar<br>
>>> tar-1.26-31.el7.x86_64<br>
>>> # sha1sum `which tar` `which gtar`<br>
>>> ea17ec98894212b2e2285eb2dd99aa<wbr>d76185ea7d /usr/bin/tar<br>
>>> ea17ec98894212b2e2285eb2dd99aa<wbr>d76185ea7d /usr/bin/gtar<br>
>>><br>
>>> Striping was set on the four directories before creating the files.<br>
>>> mkdir -p /scratch/1; lfs setstripe -c 1 --stripe-size 128K /scratch/1; lfs getstripe /scratch/1<br>
>>> mkdir -p /scratch/2; lfs setstripe -c 2 --stripe-size 256K /scratch/2; lfs getstripe /scratch/2<br>
>>> mkdir -p /scratch/3; lfs setstripe -c 3 --stripe-size 768K /scratch/3; lfs getstripe /scratch/3<br>
>>> mkdir -p /scratch/4; lfs setstripe -c 4 --stripe-size 1M /scratch/4; lfs getstripe /scratch/4<br>
>>> After tar, all files and directories all had the default Lustre striping.<br>
>>><br>
>>> # tar ztvf /scratch.tgz<br>
>>> drwxr-xr-x root/root 0 2017-03-19 10:54 scratch/<br>
>>> drwxr-xr-x root/root 0 2017-03-19 10:57 scratch/4/<br>
>>> -rw-r--r-- root/root 4194304 2017-03-19 10:57 scratch/4/4.dd<br>
>>> drwxr-xr-x root/root 0 2017-03-19 10:57 scratch/3/<br>
>>> -rw-r--r-- root/root 4194304 2017-03-19 10:57 scratch/3/3.dd<br>
>>> drwxr-xr-x root/root 0 2017-03-19 10:57 scratch/1/<br>
>>> -rw-r--r-- root/root 4194304 2017-03-19 10:57 scratch/1/1.dd<br>
>>> drwxr-xr-x root/root 0 2017-03-19 10:57 scratch/2/<br>
>>> -rw-r--r-- root/root 4194304 2017-03-19 10:57 scratch/2/2.dd<br>
>>><br>
>>> # strace tar zxvf /scratch.tgz > strace.out 2>&1<br>
>>> execve("/usr/bin/tar", ["tar", "zxvf", "/scratch.tgz"], [/* 22 vars */]) = 0<br>
>>> ...<br>
>>> (-cut - loading libraries)<br>
>>> ...<br>
>>> fstat(1, {st_mode=S_IFREG|0644, st_size=10187, ...}) = 0<br>
>>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4a63d9f000<br>
>>> write(1, "scratch/\n", 9scratch/<br>
>>> ) = 9<br>
>>> mkdirat(AT_FDCWD, "scratch", 0700) = -1 EEXIST (File exists)<br>
>>> newfstatat(AT_FDCWD, "scratch", {st_mode=S_IFDIR|0755, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0<br>
>>> write(1, "scratch/4/\n", 11scratch/4/<br>
>>> ) = 11<br>
>>> mkdirat(AT_FDCWD, "scratch/4", 0700) = 0<br>
>>> write(1, "scratch/4/4.dd\n", 15scratch/4/4.dd<br>
>>> ) = 15<br>
>>> openat(AT_FDCWD, "scratch/4/4.dd",<br>
>>> read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0"..., 10240) = 10240<br>
>>> O_WRONLY|O_CREAT|O_EXCL|O_<wbr>NOCTTY|O_NONBLOCK|O_CLOEXEC, 0600) = 4<br>
>>> write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0"..., 5632) = 5632<br>
>>> read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0"..., 10240) = 10240<br>
>>> write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0"..., 5632) = 5632<br>
>>> ...<br>
>>> (-cut)<br>
>>> ...<br>
>>> write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0"..., 512) = 512<br>
>>> dup2(4, 4) = 4<br>
>>> fstat(4, {st_mode=S_IFREG|0600, st_size=4194304, ...}) = 0<br>
>>> utimensat(4, NULL, {{1489935825, 0}, {1489935444, 0}}, 0) = 0<br>
>>> fchown(4, 0, 0) = 0<br>
>>> fchmod(4, 0644) = 0<br>
>>> close(4) = 0<br>
>>> write(1, "scratch/3/\n", 11scratch/3/<br>
>>> ) = 11<br>
>>> newfstatat(AT_FDCWD, "scratch/4", {st_mode=S_IFDIR|0700, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0<br>
>>> utimensat(AT_FDCWD, "scratch/4", {{1489935825, 0}, {1489935444, 0}}, AT_SYMLINK_NOFOLLOW) = 0<br>
>>> fchownat(AT_FDCWD, "scratch/4", 0, 0, AT_SYMLINK_NOFOLLOW) = 0<br>
>>> fchmodat(AT_FDCWD, "scratch/4", 0755) = 0<br>
>>> mkdirat(AT_FDCWD, "scratch/3", 0700) = 0<br>
>>> write(1, "scratch/3/3.dd\n", 15scratch/3/3.dd<br>
>>> ) = 15<br>
>>> openat(AT_FDCWD, "scratch/3/3.dd", O_WRONLY|O_CREAT|O_EXCL|O_<wbr>NOCTTY|O_NONBLOCK|O_CLOEXEC, 0600) = 4<br>
>>> write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0"..., 6656) = 6656<br>
>>> read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0"..., 10240) = 10240<br>
>>> write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0"..., 10240) = 10240<br>
>>> ...<br>
>>> (-cut - pick up with last file...)<br>
>>> ...<br>
>>> d(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0"..., 10240) = 10240<br>
>>> --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=2476, si_status=0, si_utime=7, si_stime=0} ---<br>
>>> write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0"..., 10240) = 10240<br>
>>> read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0"..., 10240) = 10240<br>
>>> write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0"..., 10240) = 10240<br>
>>> read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0"..., 10240) = 10240<br>
>>> write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0"..., 10240) = 10240<br>
>>> read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0"..., 10240) = 10240<br>
>>> write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0"..., 10240) = 10240<br>
>>> read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0"..., 10240) = 10240<br>
>>> write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0"..., 10240) = 10240<br>
>>> read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0"..., 10240) = 10240<br>
>>> write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\<wbr>0\0\0"..., 7680) = 7680<br>
>>> dup2(4, 4) = 4<br>
>>> fstat(4, {st_mode=S_IFREG|0600, st_size=4194304, ...}) = 0<br>
>>> utimensat(4, NULL, {{1489935825, 0}, {1489935432, 0}}, 0) = 0<br>
>>> fchown(4, 0, 0) = 0<br>
>>> fchmod(4, 0644) = 0<br>
>>> close(4) = 0<br>
>>> clock_gettime(CLOCK_REALTIME, {1489935825, 628399394}) = 0<br>
>>> clock_gettime(CLOCK_REALTIME, {1489935825, 628414336}) = 0<br>
>>> close(3) = 0<br>
>>> wait4(2476, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 2476<br>
>>> newfstatat(AT_FDCWD, "scratch/2", {st_mode=S_IFDIR|0700, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0<br>
>>> utimensat(AT_FDCWD, "scratch/2", {{1489935825, 0}, {1489935432, 0}}, AT_SYMLINK_NOFOLLOW) = 0<br>
>>> fchownat(AT_FDCWD, "scratch/2", 0, 0, AT_SYMLINK_NOFOLLOW) = 0<br>
>>> fchmodat(AT_FDCWD, "scratch/2", 0755) = 0<br>
>>> newfstatat(AT_FDCWD, "scratch", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0<br>
>>> utimensat(AT_FDCWD, "scratch", {{1489934977, 0}, {1489935261, 0}}, 0) = 0<br>
>>> fchownat(AT_FDCWD, "scratch", 0, 0, 0) = 0<br>
>>> close(1) = 0<br>
>>> munmap(0x7f4a63d9f000, 4096) = 0<br>
>>> close(2) = 0<br>
>>> exit_group(0) = ?<br>
>>> +++ exited with 0 +++<br>
>>><br>
>>><br>
>>><br>
>>> Brett<br>
>>><br>
>>> --<br>
>>><br>
>>> Protect Yourself Against Cybercrime<br>
>>><br>
>>> PDS Software Solutions LLC<br>
>>><br>
>>> <a href="https://www.TrustPDS.com" rel="noreferrer" target="_blank">https://www.TrustPDS.com</a><br>
>>><br>
>>><br>
>>><br>
>>> On Sun, Mar 19, 2017 at 7:39 AM, Dilger, Andreas <<a href="mailto:andreas.dilger@intel.com">andreas.dilger@intel.com</a>> wrote:<br>
>>><br>
>>> I ran a test locally with RHEL 6.8 and the included tar 1.26 using strace, and tar is properly using mknod+setxattr to restore the "lov" xattr, and the stripe count and stripe size to be preserved.<br>
>>><br>
>>><br>
>>><br>
>>> The OST index is not preserved with the xattr restore, since that may cause imbalance if the files were backed up in a different filesystem (e.g. one with fewer OSTs). The MDS will balance OST allocation as needed for the current OST usage.<br>
>>><br>
>>><br>
>>><br>
>>> Could you please run your tar on RHEL 7 with strace to see if it is doing this correctly?<br>
>>><br>
>>><br>
>>> Cheers, Andreas<br>
>>><br>
>>><br>
>>> On Mar 18, 2017, at 21:51, Brett Lee <<a href="mailto:brettlee.lustre@gmail.com">brettlee.lustre@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi Andreas, I expected that to be the case, but found out it was not. Instead, the restore restores everything - unless directed otherwise.<br>
>>><br>
>>> Backup == cmd + add xattrs.<br>
>>> Restore == cmd + exclude xattrs.<br>
>>><br>
>>> Brett<br>
>>> --<br>
>>> Protect Yourself Against Cybercrime<br>
>>> PDS Software Solutions LLC<br>
>>> <a href="https://www.TrustPDS.com" rel="noreferrer" target="_blank">https://www.TrustPDS.com</a><br>
>>><br>
>>> On Mar 18, 2017 9:28 PM, "Dilger, Andreas" <<a href="mailto:andreas.dilger@intel.com">andreas.dilger@intel.com</a>> wrote:<br>
>>><br>
>>> Do you need to specify --xattrs (or similar) during the restore phase as well?<br>
>>><br>
>>> Cheers, Andreas<br>
>>><br>
>>><br>
>>> On Mar 17, 2017, at 15:12, Brett Lee <<a href="mailto:brettlee.lustre@gmail.com">brettlee.lustre@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi. In what I thought was a valid test, I was unable to confirm that a backup and restore retained the layouts. Perhaps my expectation or process was incorrect? The process was:<br>
>>><br>
>>> 1. Create 4 files, each with different stripe sizes and stripe counts (verified with getstripe).<br>
>>> 2. Back up the files using tar-1.26-31.el7.x86_64.<br>
>>> 3. Recreate a file system and restore the files.<br>
>>><br>
>>> Backup command: tar --xattrs -zcvf /scratch.tgz /scratch<br>
>>><br>
>>> Restore command: tar zxvf /scratch.tgz<br>
>>><br>
>>><br>
>>> After restoration, getstripe showed that each file had the default stripe count (1) and stripe size (1MB).<br>
>>><br>
>>> FWIW: After restoring, getfattr produced the same result for each file:<br>
>>> # getfattr -d -m - -R <file><br>
>>> lustre.lov=<wbr>0s0AvRCwEAAAAdAAAAAAAAAAAEAAAC<wbr>AAAAAAAQAAEAAAAFAAAAAAAAAAAAAA<wbr>AAAAAAAAAAAAAAAAA=<br>
>>> trusted.link=0s3/<wbr>HqEQEAAAAuAAAAAAAAAAAAAAAAAAAA<wbr>ABYAAAACAAAEAAAAAAUAAAAAMS5kZA<wbr>==<br>
>>> trusted.lma=<wbr>0sAAAAAAAAAAAABAAAAgAAAB0AAAAA<wbr>AAAA<br>
>>> trusted.lov=<wbr>0s0AvRCwEAAAAdAAAAAAAAAAAEAAAC<wbr>AAAAAAAQAAEAAAAFAAAAAAAAAAAAAA<wbr>AAAAAAAAAAAAAAAAA=<br>
>>><br>
>>> Brett<br>
>>><br>
>>> --<br>
>>><br>
>>> Protect Yourself Against Cybercrime<br>
>>><br>
>>> PDS Software Solutions LLC<br>
>>><br>
>>> <a href="https://www.TrustPDS.com" rel="noreferrer" target="_blank">https://www.TrustPDS.com</a><br>
>>><br>
>>><br>
>>><br>
>>> On Wed, Mar 15, 2017 at 5:03 AM, Dilger, Andreas <<a href="mailto:andreas.dilger@intel.com">andreas.dilger@intel.com</a>> wrote:<br>
>>><br>
>>> I believe Zmanda is already using GNU tar (or RHEL tar) for the actual backup storage? I that case it should already work, since we fixed tar long ago to backup and restore xattrs in a way that preserves Lustre layouts.<br>
>>><br>
>>> Cheers, Andreas<br>
>>><br>
>>><br>
>>> On Mar 14, 2017, at 15:47, Brett Lee <<a href="mailto:brettlee.lustre@gmail.com">brettlee.lustre@gmail.com</a>> wrote:<br>
>>><br>
>>> Thanks for the details, Andreas!<br>
>>><br>
>>><br>
>>><br>
>>> Maybe OpenSFS can fund Zmanda so that their backup software can include the Lustre metadata... :)<br>
>>><br>
>>><br>
>>><br>
>>> Brett<br>
>>><br>
>>> --<br>
>>><br>
>>> Protect Yourself Against Cybercrime<br>
>>><br>
>>> PDS Software Solutions LLC<br>
>>><br>
>>> <a href="https://www.TrustPDS.com" rel="noreferrer" target="_blank">https://www.TrustPDS.com</a><br>
>>><br>
>>><br>
>>><br>
>>> On Tue, Mar 14, 2017 at 3:13 PM, Dilger, Andreas <<a href="mailto:andreas.dilger@intel.com">andreas.dilger@intel.com</a>> wrote:<br>
>>><br>
>>> To reply to this old thread, there are two different kinds of Lustre backup solutions:<br>
>>> - file level backups that traverse the client POSIX filesystem, for which any number of<br>
>>> commercial solutions exist. Making these solutions "capable of saving Lustre metadata"<br>
>>> boils down to two simple things - save the "lustre.lov" xattr during backup (at a minimum,<br>
>>> other xattrs also should be backed up), and then using mknod(2) + setxattr() to restore<br>
>>> the "lustre.lov" xattr before opening the file and restoring the data.<br>
>>><br>
>>> - device level backups (e.g. "dd" for ldiskfs, and "zfs send/recv" for ZFS).<br>
>>><br>
>>> Using the file level backups allows backup/restore of subsets of the filesystem, since many<br>
>>> HPC sites have Lustre filesystems that are too large to backup completely. I typically do<br>
>>> not recommend to use device-level backups for the OSTs, unless doing an OST hardware migration,<br>
>>> and even then it is probably less disruptive to do Lustre-level file migration off the OST<br>
>>> before swapping it out.<br>
>>><br>
>>> Whether file level backups are used or not, I would recommend sites always make periodic<br>
>>> device level backups of the MDT(s). The amount of space needed for an MDT backup is small<br>
>>> compared to the rest of the filesystem (e.g. a few TB at most), and can avoid the need for<br>
>>> a full filesystem restore (e.g. multi-PB of data, if a full backup exists at all) even<br>
>>> though all the data is still available on the OSTs.<br>
>>><br>
>>> The MDT device-level backup can use relatively slow SATA drives, since they will mostly be<br>
>>> used for linear writes (or occasionally linear reads for restore), so a few multi-TB SATA III<br>
>>> drives is sufficient for storing a rotating set of MDT device backups. At 150MB/s for even<br>
>>> a single SATA drive, this is about 2h/TB, which is reasonable to do once a week (or more often<br>
>>> for smaller MDTs).<br>
>>><br>
>>> While using an LVM snapshot of the ldiskfs MDT for the backup source is desirable for consistency<br>
>>> reasons, having even an MDT backup from a mounted and in-use MDT is better than nothing at<br>
>>> all when a problem is hit, since e2fsck can repair the in-use inconsistencies fairly easily,<br>
>>> and Lustre can deal with inconsistencies between the MDT and OST reasonably (at most returning<br>
>>> an -ENOENT error to the client for files that were deleted).<br>
>>><br>
>>> Cheers, Andreas<br>
>>><br>
>>> On Feb 7, 2017, at 12:32, Andrew Holway <<a href="mailto:andrew.holway@gmail.com">andrew.holway@gmail.com</a>> wrote:<br>
>>>><br>
>>>> Would it be difficult to suspend IO and snapshot all the nodes (assuming ZFS). Could you be sure that your MDS and OSS are synchronised?<br>
>>>><br>
>>>> On 7 February 2017 at 19:52, Mike Selway <<a href="mailto:mselway@cray.com">mselway@cray.com</a>> wrote:<br>
>>>>> Hello Brett,<br>
>>>>><br>
>>>>> Actually, looking for someone who uses a commercialized approach (that retains user metadata and Lustre extended metadata) and not specifically the manual approaches of Chapter 17.<br>
>>>>><br>
>>>>> Thanks!<br>
>>>>> Mike<br>
>>>>><br>
>>>>> Mike Selway | Sr. Tiered Storage Architect | Cray Inc.<br>
>>>>> Work <a href="tel:%2B1-301-332-4116" value="+13013324116">+1-301-332-4116</a> | <a href="mailto:mselway@cray.com">mselway@cray.com</a><br>
>>>>> 146 Castlemaine Ct, Castle Rock, CO 80104 | <a href="http://www.cray.com" rel="noreferrer" target="_blank">www.cray.com</a><br>
>>>>><br>
>>>>><br>
>>>>>> From: Brett Lee [mailto:<a href="mailto:brettlee.lustre@gmail.com">brettlee.lustre@gmail.<wbr>com</a>]<br>
>>>>>> Sent: Monday, February 06, 2017 11:45 AM<br>
>>>>>> To: Mike Selway <<a href="mailto:mselway@cray.com">mselway@cray.com</a>><br>
>>>>>> Cc: <a href="mailto:lustre-discuss@lists.lustre.org">lustre-discuss@lists.lustre.<wbr>org</a><br>
>>>>>> Subject: Re: [lustre-discuss] Backup software for Lustre<br>
>>>>>><br>
>>>>>> Hey Mike,<br>
>>>>>><br>
>>>>>> "Chapter 17" and<br>
>>>>>> <a href="http://www.intel.com/content/www/us/en/lustre/backup-and-restore-training.html" rel="noreferrer" target="_blank">http://www.intel.com/content/<wbr>www/us/en/lustre/backup-and-<wbr>restore-training.html</a><br>
>>>>>><br>
>>>>>> both contain methods to backup & restore the entire Lustre file system.<br>
>>>>>><br>
>>>>>> Are you looking for a solution that backs up only the (user) data files and their associated metadata (e.g. xattrs)?<br>
>>>>>><br>
>>>>>> Brett<br>
>>>>>> --<br>
>>>>>> Protect Yourself From Cybercrime<br>
>>>>>> PDS Software Solutions LLC<br>
>>>>>> <a href="https://www.TrustPDS.com" rel="noreferrer" target="_blank">https://www.TrustPDS.com</a><br>
>>>>>><br>
>>>>>>> On Mon, Feb 6, 2017 at 11:12 AM, Mike Selway <<a href="mailto:mselway@cray.com">mselway@cray.com</a>> wrote:<br>
>>>>>>><br>
>>>>>>> Hello,<br>
>>>>>>> Anyone aware of and/or using a Backup software package to protect their LFS environment (not referring to the tools/scripts suggested in Chapter 17).<br>
>>>>>>><br>
>>>>>>> Regards,<br>
>>>>>>> Mike<br>
<br>
Cheers, Andreas<br>
--<br>
Andreas Dilger<br>
Lustre Principal Architect<br>
Intel Corporation<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</div></div></blockquote></div><br></div></div>