Som afslutning en række anbefalinger til hvad man skal – og navnlig ikke skal – investere i mht. redundans.
Det ikke en fejl, at "alle" problemer nu er blevet til "nogle" problemer i overskriften. Hvis du har læst de 6 forrige artikler, ved du forhåbentlig hvorfor.

Dette er en del af en serie artikler om redundans, som bør læses i rækkefølge. Hvis du ikke har læst indledningen ” Redundans til at løse alle problemer”, så er den her.

1. Køb kun det reserveudstyr som I kan overkomme at bruge i det daglige
En af de største syndere mht. at give falsk tryghed, er backup-udstyr som man har til brug i tilfælde af fejl på noget andet udstyr, men som ikke bruges normalt. Når uheldet endelig er ude, så vil det meget ofte vise sig at backup-udstyret heller ikke virker på grund at et eller andet andet problem, som ingen har opdaget fordi ingen har brugt det.
Det gælder både hvis det er et komplet studie eller bare en afviklingsmaskine i et studie. Det er altså vigtigt at alt udstyr der er indkøbt som reserver af forskellig art, bliver brugt til i det daglige. Så hvis der er tale om et reserve-studie, så sørg for at det bliver brugt til at producere nogle programmer, og hvis der er tale om en afviklingsmaskine i et studie hvorfra der sendes live, så brug den fx. til at afvikle jingler eller speak-beds.
At et backupsystem bruges i det daglige er også den eneste reelle mulighed for at sikre sig, at personalet ved hvordan de skal bruge det, og ved hvordan man kobler om, den dag der er et rigtigt problem.

2. Sørg for at have en løst koblet backup
En fejl der ofte begås er at bruge en del penge på redundant storage, som sikrer imod hardwarefejl på selve storagen, men som ikke sikrer imod at det system man har eller de mennesker man har, kan komme til at slette det hele.
Det er fint med forskellige former for RAID og spejlede disksystemer, da de ofte vil kunne skifte diske uden at det medfører afbrydelser for det system der bruger storagen. Problemet med dem er, at et spejlet backupsystems fornemmeste opgave er at gøre alt som på mainsystemet - så hvis der kommer en instruktion om at slette noget, så vil det også ske med det samme på backupsystemet.
Derfor skal der suppleres med en backup hvor der tages backup af nye ting, men hvor ting der slettes, ikke bliver slettet fra backup'en med det samme. Sådan en backup vil som regel også have den fordel, at det er naturligt at anbringe den et andet sted end hovedsystemet, så fx. en mindre brand i et serverrum ikke vil gå ud over den.
Hvis der ikke er penge til både det ene og det andet, så bør der satses på den løst koblede backup, da den kan bruges mod flere slags fejl, selv om failover i tilfælde af hardwarefejl så normalt vil medføre en afbrydelse af driften.

3. Pas på mængden af omskiftere
Hver eneste gang der findes en omskifter mellem et main og et backupsystem, findes der en potentiel kilde til fejl. Det gælder uanset om det er en KVM switch, en omskifter mellem studier eller playout maskiner, en silence detector, ...
Ønsker man at lave en driftsikker radio eller TV station, så bør det faktisk være et mål i sig selv, at få nedbragt mængden af omskiftere, som skal bruges i tilfælde af fejl. Det giver et enklere system, og i tilfælde af fejl, findes der næsten ikke noget vigtigere.
Dog skal man passe på med så at lade den samme omskifter koble flere ting på én gang. Det skaber uklare forventninger om hvad der egentlig bliver koblet og total forvirring, hvis en omskifter en dag ikke kan koble det hele om, således at nogle ting er koblet om, og andre ikke er.


Måske kan dette synes at være de rene banaliteter, hvad det egentlig også er ... så kan man bare undre sig over at så mange alligevel begår de her fejl og ender med at få problemer på grund af det.
Muligvis fordi der er mere imponator-effekt over at kunne slå ud med armene og sige at vi har to af alting, så her går intet galt. Det er bare forkert, og svarer til at påstå at Titanic ikke kan synke.
Og måske også fordi folk egentlig gerne vil have den tryghed en rød knap giver – selv om den ofte er falsk.