Sparse image készítése

dd if=/dev/zero of=/path/to/1.img bs=1 count=0 seek=100G
losetup /dev/loop0 /path/to/1.img
mkfs.jfs /dev/loop0
mount /dev/loop0 /tmp/uu
df -h | grep /tmp/uu

Mikor jöhet ez jól? Pl. akkor, ha csillió file-t akarsz létrehozni, de a filerendszered már kész van, és kevés rajta az inode. Az ext4 pl. a formázás (azaz az mkfs.ext4 futtatása) után már nem teszi lehetővé az inode-ok számának módosítását.

3-2-1 Backup: The Rule For Recovery

Doug Hazelman ugyanezzel a címmel írt egy cikket a fenti szabályról: http://www.networkcomputing.com/storage/3-2-1-backup-rule-recovery/108368175

A 3-2-1 szabály talán a legfontosabb az adatok biztonsága szempontjából. Röviden azt mondja, hogy egy cégnek 3 példányban kell az adatait tárolnia, 2 különböző adathordozón, amiből az egyik egy másik helyszínen van.

A cikk megemlíti a Pixar esetét, amelyik majdnem elveszítette a Toy Story 2-t egy ügyetlen parancs és a nem működő mentés miatt. A Pixar csak azért menekült meg, mert valakinek megvolt a film az otthoni pc-jén.

Aztán Ohio államban valaki hazavitte a szalagot, amivel ugyan teljesült az ‘1’, csakhogy betörttek a lakásába, és elvitték a mentést is, amin rajta volt 64000 állami alkalmazott személyes adata, pl. igazolvány számok, stb.

Az NTP Software cikke megemlíti Peter Krogh nevét, akitől származik a 3-2-1 szabály. Szerinte 2 féle ember van: akinél már tönkrement a storage, és akinél még csak fog tönkre menni.

Az email archiválás kapcsán említette valaki, hogy “üzletileg nem elfogadható a levelek összevissza tárolása, elkülönítése, local archive meg stb bohóckodás.“, meg hogy jól vannak a levelek a mail szerveren.

Ez nyilvánvalóan nem felel meg a 3-2-1 szabálynak, és bizonyára nem véletlen, hogy tőlünk nyugatabbra konkrétan jogszabály írja elő (FRCP, SOX, …), hogy mely ipari szereplőknek meddig kell archiválni a leveleiket, hogy meglegyen a compliance.

Arról nem is beszélve,hogy ha pedig majd egyszer megborul a mail szerver alatt a storage (Krogh szerint ez csak idő kérdése), akkor lesz majd ‘fun’. De nem is kell hardware hiba, annyi is elég a bajhoz, ha valaki véletlenül (vagy éppen szándékosan) töröl a levelekből.

Az email archiválás – főleg ha egy 3. fél végzi – akkor védelmet nyújthat ez ellen is.

 

roundcube login failure after php upgrade to 5.6.x

I’ve just upgraded php to 5.6.x, and I couldn’t login to roundcube any more.

Since I use a self signed certificate I’ve added the following fix to config/config.inc.php:


$config['imap_conn_options'] = array(
'ssl' => array(
'verify_peer' => false,
'verify_peer_name' => false
),
);

Credits: https://bbs.archlinux.org/viewtopic.php?id=187063