Das perfekte Backup

Das ist na­tür­lich sub­jek­tiv. Es hängt ab von Ihren per­sön­li­chen Be­dürf­nis­sen. Ich ha­be fol­gen­de Vo­r­aus­set­zun­gen:

1. Ich ha­be ei­nen Rasp­berry Pi 5 als Home­ser­ver
2. Mei­ne Cli­ents sind aus­schließ­lich Win­dows PCs

Für mich ha­be ich das fol­gen­de Ver­fah­ren ent­wi­ckelt:

1. Ich si­che­re mei­ne Da­ten auf Stan­dard-Fest­plat­ten im USB-Dock (kei­ne Strea­mer, Tape-Li­braries etc.) Das ist schlicht die bil­ligs­te Me­tho­de.
2. Da mei­ne Cli­ents aus­schließ­lich Win­dows PCs sind, si­che­re ich sie auf Sha­res-Ebene, d.h. je­des Root-Ver­zeich­nis, das mei­ne Win­dows-Cli­ents auf dem NAS se­hen, se­pa­rat (aber durch­aus auch meh­re­re oder al­le auf ei­ner Disk)
3. Aber auch die Li­nux-Um­ge­bung muss ge­si­chert wer­den um sie bei ei­nem ka­ta­stro­pha­len Ver­sa­gen nicht von Grund auf neu ein­rich­ten zu müs­sen.
   Ich si­che­re die­se aus­schließ­lich in ei­nem vo­r­aus­ge­hen­den Schritt di­rekt auf das NAS.
4. Ich be­nut­ze die Hard­ware-Vor­raus­set­zungen wie in mei­nem Ar­ti­kel Rasp­berry Pi Green­Nas be­schrie­ben. Die Skrip­te un­ter Down­loads ver­wen­den die hard­ware­mä­ßi­gen Er­wei­te­run­gen.

Auf mei­ner Ser­ver­plat­te ha­be ich ei­ne ver­schlüs­sel­te Par­ti­tion (die re­la­tiv groß ist). Um sie nicht je­des­mal per dd ko­pie­ren zu müs­sen, wird sie auf der Back­up-Plat­te ge­moun­ted und nur auf Da­tei-Ebene syn­chro­ni­siert. Dazu ist beim Back­up die Ein­ga­be des Pass­worts nö­tig, so das die­ses nicht au­to­ma­ti­siert (z.B. über Nacht) durch­ge­führt wer­den kann.

Al­le an­de­ren Da­ten lie­gen, so­wohl auf dem Ser­ver als auch auf den Back­up-Plat­ten, un­ver­schlüs­selt vor. Sie ent­hal­ten nichts kom­pro­mit­tie­ren­des oder pein­li­ches und das Ri­si­ko ei­nes (Total-) Ver­lus­tes we­gen Schlüs­sel­pro­ble­men schät­ze ich hö­her ein, als dass sie in frem­de Hän­de kom­men könn­ten.

Wenn Sie Ih­re Back­up-Plat­ten ge­ne­rell ver­schlüs­seln möch­ten, müs­sen Sie das selbst re­a­li­sie­ren. Auf dem Ser­ver sind die Da­ten so­wie­so per­ma­nent les­bar ge­moun­ted, da wür­de es kei­nen Vor­teil brin­gen, beim Booten ein Pass­wort ein­ge­ben zu müs­sen.

Die Back­up-Plat­te kann klei­ner sein als das NAS plus der Ser­ver. Dazu muss sie je­des zu si­chern­de Sha­re be­reits ent­hal­ten (zu­min­dest als lee­res Ver­zeich­nis). So kann man üb­rig ge­blie­be­ne Fest­plat­ten als Back­up-Medium für Sha­res, die eben drauf­pas­sen, nut­zen.

Des­halb ist es rat­sam, je­des Back­up zu pro­to­kol­lie­ren. Ich ma­che das au­to­ma­ti­siert im Back­up-Skript in ei­ner Da­ten­bank. So kann ich je­der­zeit se­hen, auf wel­cher Plat­te die ak­tu­ells­te Si­che­rung ei­nes Sha­res zu fin­den ist bzw. auch, wel­che Sha­res schon län­ger nicht mehr ge­si­chert wur­den, was ich dann dem­nächst nach­ho­len müss­te.

Die Back­up-Plat­te wird da­bei über ih­re UUID iden­ti­fi­ziert, hat in der Da­ten­bank ei­nen ein­deu­ti­gen Na­men (das File­sys­tem-La­bel) und ist mit die­sem (so­wie zur Si­cher­heit auch mit der UUID) be­schrif­tet.

Das Skript backup.pl si­chert die SSD auf der NAS-Plat­te. Dieses wird meist häu­fi­ger auf­ge­ru­fen und si­chert ge­gen ei­nen Defekt oder ver­se­hent­li­chem Lö­schen der SSD. Wenn am Ser­ver et­was ka­putt geht, sind die Da­ten auf der NAS-Plat­te voll­stän­dig vor­han­den.

Die NAS-Plat­te ist um ein mehr­fa­ches grö­ßer als die SSD und kann de­ren In­halt pro­blem­los auf­neh­men.

Das Skript rsyncNas2Backup schließ­lich si­chert den In­halt der NAS-Plat­te, oder Teile da­von, je­des Ver­zeich­nis, das ge­si­chert wer­den soll, muss be­reits auf der Back­up-Plat­te exis­tie­ren, sonst wird es über­sprun­gen, auf ei­ne ex­ter­ne Back­up-Plat­te. Die­se wird re­gel­mä­ßig ge­wech­selt, so dass meh­re­re Plat­ten ver­schie­de­nen Al­ters exis­tie­ren, die nicht online sind und für ein Re­store zur Ver­fü­gung ste­hen.

Un­wich­tig so­lan­ge, bis man sie braucht!

Na­tür­lich wis­sen Sie, wo das neu­es­te Back­up ist. Aber was ist mit der Fest­plat­te, die im Kü­chen­schrank liegt? Von wann ist die im Kel­ler­re­gal? Was ge­nau ist da drauf?

Es ist sinn­voll, meh­re­re Back­up-Plat­ten an ver­schie­de­nen Stel­len im Haus zu ver­ste­cken (bes­ser noch, in ei­nem an­de­ren Haus, bei ei­nem Freund oder am Ar­beits­platz), da­mit ein Ein­bre­cher nicht al­le zu­sam­men zum Ki­lo­preis ver­kau­fen kann und Sie vor dem Nichts ste­hen.

Ich ver­wen­de teil­wei­se klei­ne­re (üb­rig ge­blie­be­ne) Fest­plat­ten, auf die je­weils nur ein Teil des Back­ups passt. Mit­hil­fe der Da­ten­bank kann ich schnell se­hen, wel­che Sha­res ich mal wie­der si­chern müss­te und wel­che Plat­te da­für ge­eig­net sein könn­te.

In mei­ner Da­ten­bank gibt es da­zu zwei Ta­bel­len:

• Ei­ne Ta­bel­le tMedia, die je­des be­kann­te Medium ent­hält (lo­ka­le Fest­plat­ten ge­nau­so wie Back­up-Plat­ten). Jede Par­ti­tion auf dem Medium muss ein La­bel be­sit­zen.
  Neue, bis­her nicht ver­wen­de­te Back­up-Plat­ten wer­den au­to­ma­tisch er­kannt und müs­sen nicht ma­nu­ell hin­zu­ge­fügt wer­den.
  Lokale Än­de­run­gen an den Disks kön­nen Sie mit backupUpdateMedia ein­tra­gen (sie­he Down­loads).
  Das Skript updateMediaDB er­mit­telt auch Her­stel­ler, Mo­dell, Grö­ße und Se­ri­en­num­mer der Plat­te, so­fern die­se Da­ten ver­füg­bar sind, und trägt die­se ent­spre­chend ein.
• Ei­ne Ta­bel­le tBackup, in der je­des Back­up pro­to­kol­liert wird, d.h. von wel­chem Medium wann, wel­ches Sha­re auf wel­ches an­de­re Medium ge­si­chert wur­de, zu­sam­men mit ei­nem Feh­ler­code, der zeigt, ob es ge­klappt hat bzw. wa­r­um evtl. auch nicht.

Die Ein­deu­tig­­keit der UUIDs ist da­bei es­sen­tiell! Clonen von Fest­plat­ten durch ei­ne simp­le (dd-) Ko­pie ver­bie­tet sich. Das kann auch an an­de­rer Stel­le zu Pro­ble­men füh­ren und soll­te nie­mals durch­ge­führt wer­den!

• UUID ist die UUID des Da­tei­sys­tems ei­ner Par­ti­tion.
• PARTUUID kenn­zeich­net ein­deu­tig ei­ne Par­ti­tion der Fest­plat­te.
• PTUUID ist die UUID der Par­ti­ti­ons­ta­bel­le, al­so prak­tisch die UUID der Fest­plat­te. Sie ist für al­le Par­ti­tio­nen ei­ner Fest­plat­te gleich.

Set­zen Sie noch mit z.B. e2label /dev/sda1 DiskName ei­nen aus­sa­ge­fä­hi­gen Na­men, un­ter dem sie spä­ter in der Da­ten­bank auf­tau­chen wird. Dies ist not­wen­dig. Ein lee­rer Na­me (Null) ist in mei­ner Da­ten­bank nicht zu­läs­sig und wür­de ei­nen Feh­ler beim Ein­fü­gen er­zeu­gen!

Moun­ten Sie die Par­ti­tion in /backupdisk und er­zeu­gen Sie ein lee­res Ver­zeich­nis für je­des Root-Ver­zeich­nis des NAS, das spä­ter auf die­ser Plat­te ge­si­chert wer­den soll.

Ab jetzt steht sie für ein rsyncNas2Backup zur Ver­fü­gung.

Die Da­ten der Plat­te wer­den beim ers­ten Back­up au­to­ma­tisch in tMedia ein­ge­tra­gen und auch die Pro­to­kol­lie­rung der Back­ups in tBackup er­folgt oh­ne wei­te­res Zutun.

Ein we­sent­li­cher Punkt da­bei lau­tet: wa­r­um brau­che ich ein Re­store?

Dabei gibt es min­des­tens drei Sze­na­ri­en:

Versehentliches Löschen

Sie ha­ben al­so ver­se­hent­lich ir­gend­wel­che Da­tei­en ge­löscht oder un­be­ab­sich­tigt ver­än­dert.

Die­ser Fall ist noch ziem­lich ent­spannt. Ein­fach das NAS ak­ti­vie­ren und die ent­spre­chen­den Da­tei­en zu­rück ko­pie­ren. Falls die­se auch da schon nicht mehr drauf sind, gibt es hof­fent­lich ei­ne ge­eig­ne­te äl­te­re Back­up-Disk.

Auch das ist noch kein un­lös­ba­res Pro­blem, ob­wohl schon ein biss­chen stres­sig. Tau­schen Sie die SSD und/oder den Ser­ver und in­stal­lie­ren Sie schlimms­ten­falls den Ser­ver neu. In­stal­lie­ren Sie all die Pa­ke­te, die Sie da­mals auch noch hin­zu­ge­fügt ha­ben (si­cher­lich ha­ben Sie das da­mals ir­gend­wo auf­ge­schrie­ben 😉). Ko­pie­ren Sie die Da­tei­en in /etc und die sons­ti­gen Da­tei­en vom letz­ten Back­up und al­les soll­te wie­der weit­ge­hend funk­tio­nie­ren.

Virus

Sie ha­ben sich ei­nen Vi­rus ein­ge­fan­gen, der Ih­re Da­ten ver­schlüs­selt hat.

Jetzt ha­ben Sie ein Pro­blem!

Der glück­lichs­te Fall wä­re tat­säch­­lich, er steckt in Ihrem Ser­ver. Dann kön­nen Sie die­sen aus ei­ner si­che­ren Quel­le neu in­stal­lie­ren, Die Da­tei­en in /etc so­wie al­le Sha­res zu­rück ko­pie­ren und al­les ist wie­der OK.

Aber er kann auch in ei­nem Ihrer Cli­ents sit­zen, sich viel­leicht schon auf an­de­re wei­ter­ver­brei­tet ha­ben...

Jetzt müs­sen Sie ihr ge­sam­tes Netz über­prü­fen, ggf. Neu­in­stal­lat­ionen durch­füh­ren und auf­pas­sen, dass die­se nicht wie­der in­fi­ziert wer­den, ich möch­te jetzt nicht in Ihrer Haut ste­cken!

Heben Sie ab jetzt al­le ih­re Back­ups auf! Er kann auch schon Wo­chen- oder Mo­na­te­lang ge­lau­ert ha­ben, oh­ne sich be­merk­bar zu ma­chen, und Wo­chen nach ei­nem ver­meint­lich er­folg­rei­chem Re­store wie­der zu­schla­gen. Viel­leicht ist ein äl­te­res Back­up die Ret­tung!

Ver­wen­den Sie kei­ne Back­up-Disks di­rekt! Machen Sie ei­ne Ko­pie auf ei­nem si­che­ren Sys­tem, sonst könn­te er viel­leicht auch äl­te­re Back­ups in­fi­zie­ren!

Proben Sie den Ernstfall

– – – – – – – — Ge­ne­ral­alarm, Ge­ne­ral­alarm, Ge­ne­ral­alarm, zur Übung

Es kann nicht scha­den, den Ernst­fall, al­so das Re­store z.B. von ei­ner Back­up-Plat­te auf ei­ne neue NAS-Plat­te oder vom Back­up-Ver­zeich­nis des NAS auf ei­nen neu­en PI5 zu tes­ten.

Das ist nicht wirk­lich teu­er (Sie brau­chen le­dig­lich ei­ne neue Fest­plat­te bzw. ei­nen neu­en Pi5), aber es ver­rin­gert spä­te­ren Stress, wenn es wirk­lich mal ernst wird!

Und dank die­ser Übung ha­ben Sie die Er­satz­tei­le dann schon pa­rat. Den­ken Sie da­r­an, der Ernst­fall wird im­mer am Frei­tag Nach­mit­tag ein­tre­ten, wenn Sie bis Mon­tag nichts mehr be­stel­len kön­nen...