40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log  Not logged in ELOG logo
Entry  Mon Aug 14 19:41:46 2017, Jamie, Update, CDS, front-end/DAQ network down for kernel upgrade, and timing errors 
    Reply  Wed Aug 16 17:05:53 2017, Jamie, Update, CDS, front-end/DAQ network down for kernel upgrade, and timing errors 2017-08-16-163725_1366x495_scrot.png
       Reply  Wed Aug 16 17:14:02 2017, Koji, Update, CDS, front-end/DAQ network down for kernel upgrade, and timing errors 
          Reply  Wed Aug 16 18:01:28 2017, Jamie, Update, CDS, front-end/DAQ network down for kernel upgrade, and timing errors 
             Reply  Wed Aug 16 18:06:01 2017, Koji, Update, CDS, front-end/DAQ network down for kernel upgrade, and timing errors 
       Reply  Wed Aug 16 18:50:58 2017, Jamie, Update, CDS, front-end/DAQ network down for kernel upgrade, and timing errors 2017-08-16-184910_1394x488_scrot.png
          Reply  Mon Aug 28 16:20:00 2017, gautam, Update, CDS, 40m files backup situation 
             Reply  Mon Aug 28 17:13:57 2017, ericq, Update, CDS, 40m files backup situation 
             Reply  Fri Sep 15 15:54:28 2017, gautam, Update, CDS, FB wiper script 
                Reply  Mon Sep 18 17:17:49 2017, gautam, Update, CDS, FB wiper script 
                   Reply  Mon Sep 18 17:30:54 2017, Chris, Update, CDS, FB wiper script wiper.pl
                      Reply  Mon Sep 18 17:51:26 2017, gautam, Update, CDS, FB wiper script perlDiff.png
                         Reply  Mon Sep 18 18:40:34 2017, gautam, Update, CDS, FB wiper script 
             Reply  Tue Sep 26 15:55:20 2017, gautam, Update, CDS, 40m files backup situation 
                Reply  Thu Sep 28 10:33:46 2017, gautam, Update, CDS, 40m files backup situation 
                   Reply  Thu Sep 28 11:13:32 2017, jamie, Update, CDS, 40m files backup situation 
                      Reply  Thu Sep 28 23:47:38 2017, gautam, Update, CDS, 40m files backup situation 
                         Reply  Fri Sep 29 11:07:16 2017, gautam, Update, CDS, 40m files backup situation 
                            Reply  Thu Oct 5 13:58:26 2017, gautam, Update, CDS, 40m files backup situation 
                               Reply  Fri Oct 6 12:46:17 2017, gautam, Update, CDS, 40m files backup situation 
                                  Reply  Sat Oct 28 00:36:26 2017, gautam, Update, CDS, 40m files backup situation - ddrescue 415E2F09-3962-432C-B901-DBCB5CE1F6B6.jpegBFF8F8B5-1836-4188-BDF1-DDC0F5B45B41.jpeg
Message ID: 13340     Entry time: Thu Sep 28 11:13:32 2017     In reply to: 13339     Reply to this: 13342
Author: jamie 
Type: Update 
Category: CDS 
Subject: 40m files backup situation 

 

Quote:

After consulting with Jamie, we reached the conclusion that the reason why the root of FB1 is so huge is because of the way the RAID for /frames is setup. Based on my googling, I couldn't find a way to exclude the nfs stuff while doing a backup using dd, which isn't all that surprising because dd is supposed to make an exact replica of the disk being cloned, including any empty space. So we don't have that flexibility with dd. The advantage of using dd is that if it works, we have a plug-and-play clone of the boot disk and root filesystem which we can use in the event of a hard-disk failure.

  1. One option would be to stop all the daqd processes, unmount /frames, and then do a dd backup of the true boot disk and root filesystem.
  2. Another option would be to use rsync to do the backup - this way we can selectively copy the files we want and ignore the nfs stuff. I suspect this is what we will have to do for the second layer of backup we have planned, which will be run as a daily cron job. But I don't think this approach will give us a plug-and-play replacement disk in the event of a disk failure.
  3. Third option is to use one of the 2TB HGST drives, and just do a dd backup - some of this will be /frames, but that's okay I guess.

This is not quite right.  First of all, /frames is not NFS.  It's a mount of a local filesystem that happens to be on a RAID.  Second, the frames RAID is mounted at /frames.  If you do a dd of the underlying block device (in this case /dev/sda*, you're not going to copy anything that's mounted on top of it.

What i was saying about /frames is that I believe there is data in the underlying directory /frames that the frames RAID is mounted on top of.  In order to not get that in the copy of /dev/sda4 you would need to unmount the frames RAID from /frames, and delete everything from the /frames directory.  This would not harm the frames RAID at all.

But it doesn't really matter because the backup disk has space to cover the whole thing so just don't worry about it.  Just dd /dev/sda to the backup disk and you'll just be copying the root filesystem, which is what we want.

ELOG V3.1.3-