40m
QIL
Cryo_Lab
CTN
SUS_Lab
TCS_Lab
OMC_Lab
CRIME_Lab
FEA
ENG_Labs
OptContFac
Mariner
WBEEShop
|
40m Log |
Not logged in |
 |
|
Mon Aug 14 19:41:46 2017, Jamie, Update, CDS, front-end/DAQ network down for kernel upgrade, and timing errors
|
Wed Aug 16 17:05:53 2017, Jamie, Update, CDS, front-end/DAQ network down for kernel upgrade, and timing errors
|
Wed Aug 16 17:14:02 2017, Koji, Update, CDS, front-end/DAQ network down for kernel upgrade, and timing errors
|
Wed Aug 16 18:01:28 2017, Jamie, Update, CDS, front-end/DAQ network down for kernel upgrade, and timing errors
|
Wed Aug 16 18:06:01 2017, Koji, Update, CDS, front-end/DAQ network down for kernel upgrade, and timing errors
|
Wed Aug 16 18:50:58 2017, Jamie, Update, CDS, front-end/DAQ network down for kernel upgrade, and timing errors
|
Mon Aug 28 16:20:00 2017, gautam, Update, CDS, 40m files backup situation
|
Mon Aug 28 17:13:57 2017, ericq, Update, CDS, 40m files backup situation
|
Fri Sep 15 15:54:28 2017, gautam, Update, CDS, FB wiper script
|
Mon Sep 18 17:17:49 2017, gautam, Update, CDS, FB wiper script
|
Mon Sep 18 17:30:54 2017, Chris, Update, CDS, FB wiper script
|
Mon Sep 18 17:51:26 2017, gautam, Update, CDS, FB wiper script
|
Mon Sep 18 18:40:34 2017, gautam, Update, CDS, FB wiper script
|
Tue Sep 26 15:55:20 2017, gautam, Update, CDS, 40m files backup situation
|
Thu Sep 28 10:33:46 2017, gautam, Update, CDS, 40m files backup situation
|
Thu Sep 28 11:13:32 2017, jamie, Update, CDS, 40m files backup situation
|
Thu Sep 28 23:47:38 2017, gautam, Update, CDS, 40m files backup situation
|
Fri Sep 29 11:07:16 2017, gautam, Update, CDS, 40m files backup situation
|
Thu Oct 5 13:58:26 2017, gautam, Update, CDS, 40m files backup situation
|
Fri Oct 6 12:46:17 2017, gautam, Update, CDS, 40m files backup situation
|
Sat Oct 28 00:36:26 2017, gautam, Update, CDS, 40m files backup situation - ddrescue 
|
|
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.
- 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.
- 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.
- 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. |