Is your current directory writable?
The geli backup syntax is "geli backup <provider> <filename>". If you did not change the FreeNAS default the provider is the second partition on the disk (the first partition is swap). So, to backup ada1 metadata to a geli_ada1 file you would run "geli backup /dev/ada1p2 geli_ada1". My script tries to use the serial numbers of the drives as the file names. I did consider using the GPTIDs but I want to be able to match the backups to physical drives even in case the partition tables get corrupted too. The partition table is easy to recreate, but you will get new GPTIDs.
I just also noticed that my script will fail if the serial number contains space(s) (my WD REDs' serial numbers don't). This should work better:
Code:#!/bin/sh for disk in /dev/ada*p2 do geli backup $disk "`camcontrol identify ${disk%p2} | grep serial | tr -s \ | cut -d \ -f 3-`".eli done
for i in 2 3 4 5 6 7; do geli backup da${i}p2 "`camcontrol identify da${i} | grep serial | tr -s \ | cut -d \ -f 3-`".eli done
#!/bin/sh for disk in /dev/ada*p2 do geli backup $disk "`camcontrol identify ${disk%p2} | grep serial | tr -s \ | cut -d \ -f 3-`".eli done
What I meant was is there some place on the server itself? I am not familiar enough with it to know how various data persists (other than the storage volumes). What places, if any, may I stuff a little bit of data? Or is the recommended practice to get it off the server completely?Someplace safe. Whatever you want to call "safe".
Thank you for the advice.No. In particular you don't want it on the server since you'd be wanting it in the event of *serious* server problems.
I do incremental replications. I have an automated snapshot task that snapshots the main pool and the snapshot is then replicated to the backup drive (incremental = only changed blocks are transferred).
Of course. I did not yet upgrade to 9.2.0, so the script does direct writes to the config DB. I plan to update it to use the FreeNAS API later. My removable backup pool is named backup, the disk is ada1… ...I run the script after I replace the backup drive and import the pool. It sets the idle timer, some smart options (-a is no longer needed in 9.2.0) and adjusts the scrub (it gets created automatically when you import the pool) schedule to my liking. It then regenerates config files / restarts services so that the changes take effect.
With my backup rotation schedule the system will perform at least one scrub before I swap the drives. This will detect any bitrot and I can redo a full backup if needed...
The one slightly annoying thing with this schema is that when you export/detach a pool (required before you remove it) FreeNAS will discard the related disk settings (SMART extra parameters, spin down timeout, ...) and its scrub schedule. When you connect the other drive you'll get default disk settings and a default scrub will be scheduled. So, you need to redo your changes (if any) every time you swap the drives (I have a script to do that).
#!/bin/sh for disk in /dev/da*p2 do geli backup $disk `camcontrol identify ${disk%p2} | grep serial | tr -s \ | cut -d \ -f 3-`.eli done for disk in /dev/da*p1 do filename=`camcontrol identify ${disk%p1} | grep serial | tr -s \ | cut -d \ -f 3-`.eli if [ ! -f $filename ]; then geli backup $disk $filename fi done
[root@freenas] /mnt/ # ll /dev/mfisyspd* crw-r----- 1 root operator 0x65 Sep 12 17:09 /dev/mfisyspd0 crw-r----- 1 root operator 0xc4 Sep 12 17:09 /dev/mfisyspd0p1 crw-r----- 1 root operator 0xc3 Sep 12 17:10 /dev/mfisyspd0p1.eli crw-r----- 1 root operator 0xc6 Sep 12 17:09 /dev/mfisyspd0p2 crw-r----- 1 root operator 0x66 Sep 12 17:04 /dev/mfisyspd1 crw-r----- 1 root operator 0x6b Sep 12 17:04 /dev/mfisyspd1p1 crw-r----- 1 root operator 0xc2 Sep 12 17:10 /dev/mfisyspd1p1.eli crw-r----- 1 root operator 0x6c Sep 12 17:04 /dev/mfisyspd1p2 crw-r----- 1 root operator 0x67 Sep 12 17:04 /dev/mfisyspd2 crw-r----- 1 root operator 0x6d Sep 12 17:04 /dev/mfisyspd2p1 crw-r----- 1 root operator 0xc9 Sep 12 17:10 /dev/mfisyspd2p1.eli crw-r----- 1 root operator 0x6e Sep 12 17:04 /dev/mfisyspd2p2 crw-r----- 1 root operator 0x68 Sep 12 17:04 /dev/mfisyspd3 crw-r----- 1 root operator 0x6f Sep 12 17:04 /dev/mfisyspd3p1 crw-r----- 1 root operator 0xbf Sep 12 17:10 /dev/mfisyspd3p1.eli crw-r----- 1 root operator 0x70 Sep 12 17:04 /dev/mfisyspd3p2 crw-r----- 1 root operator 0x69 Sep 12 17:04 /dev/mfisyspd4 crw-r----- 1 root operator 0x71 Sep 12 17:04 /dev/mfisyspd4p1 crw-r----- 1 root operator 0xc0 Sep 12 17:10 /dev/mfisyspd4p1.eli crw-r----- 1 root operator 0x72 Sep 12 17:04 /dev/mfisyspd4p2 crw-r----- 1 root operator 0x6a Sep 12 17:04 /dev/mfisyspd5 crw-r----- 1 root operator 0x73 Sep 12 17:04 /dev/mfisyspd5p1 crw-r----- 1 root operator 0xc1 Sep 12 17:10 /dev/mfisyspd5p1.eli crw-r----- 1 root operator 0x74 Sep 12 17:04 /dev/mfisyspd5p2
# sh bkup camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed cam_lookup_pass: No such file or directory cam_lookup_pass: either the pass driver isn't in your kernel cam_lookup_pass: or mfisyspd0 doesn't exist geli: MD5 hash mismatch: not a geli provider? camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed cam_lookup_pass: No such file or directory cam_lookup_pass: either the pass driver isn't in your kernel cam_lookup_pass: or mfisyspd0p1 doesn't exist geli: MD5 hash mismatch: not a geli provider?
# camcontrol devlist <ATA WDC WD60EFRX-68M 0A82> at scbus0 target 9 lun 0 (pass0) <ATA OWC Mercury EXTR BBF0> at scbus0 target 10 lun 0 (pass1) <ATA WDC WD40EFRX-68W 0A80> at scbus0 target 11 lun 0 (pass2) <ATA WDC WD40EFRX-68W 0A80> at scbus0 target 12 lun 0 (pass3) <ATA WDC WD40EFRX-68W 0A80> at scbus0 target 13 lun 0 (pass4) <ATA WDC WD40EFRX-68W 0A80> at scbus0 target 14 lun 0 (pass5) <Kingston DT 101 G2 PMAP> at scbus10 target 0 lun 0 (pass6,da0) # camcontrol identify pass0 | grep serial serial number WD-WX11D259VYUD
# geli backup pass0 WD-WX11D259VYUD.geli geli: Cannot open pass0: Operation not permitted.
What does that even mean? Please use proper terminology, or nobody will be able to help - and most people won't bother to spend their time going back and forth trying to figure out what you mean.I am using an LSI RAID controller flashed with the SATA expander firmware
What does that even mean? Please use proper terminology, or nobody will be able to help - and most people won't bother to spend their time going back and forth trying to figure out what you mean.