uk There is also a ENGLISH VERSION of this site

Meer artikelen

Google

01 Aug - 31 Aug 2010
01 Jul - 31 Jul 2010
01 Jun - 30 Jun 2010
01 May - 31 May 2010
01 Apr - 30 Apr 2010
01 Mar - 31 Mar 2010
01 Feb - 28 Feb 2010
01 Jan - 31 Jan 2010
01 Dec - 31 Dec 2009
01 Oct - 31 Oct 2009
01 Sep - 30 Sep 2009
01 Aug - 31 Aug 2009
01 Jun - 30 Jun 2009
01 Apr - 30 Apr 2009
01 Mar - 31 Mar 2009
01 Feb - 28 Feb 2009
01 Jan - 31 Jan 2009
01 Dec - 31 Dec 2008
01 Nov - 30 Nov 2008
01 Oct - 31 Oct 2008
01 Sep - 30 Sep 2008
01 Aug - 31 Aug 2008
01 Jul - 31 Jul 2008
01 Jun - 30 Jun 2008
01 May - 31 May 2008
01 Apr - 30 Apr 2008
01 Mar - 31 Mar 2008
01 Feb - 28 Feb 2008
01 Jan - 31 Jan 2008
01 Dec - 31 Dec 2007
01 Nov - 30 Nov 2007
01 Oct - 31 Oct 2007
01 Sep - 30 Sep 2007
01 Aug - 31 Aug 2007
01 Jul - 31 Jul 2007
01 Jun - 30 Jun 2007
01 May - 31 May 2007
01 Apr - 30 Apr 2007
01 Mar - 31 Mar 2007
01 Feb - 28 Feb 2007
01 Jan - 31 Jan 2007
01 Dec - 31 Dec 2006
01 Nov - 30 Nov 2006
01 Oct - 31 Oct 2006
01 Sep - 30 Sep 2006
01 Aug - 31 Aug 2006


Links

Deze site wordt gehost bij
ATN-Networks

Aanbevolen
Genootschap voor Informatie Architecten
Rene Hamberg
Eric Meijer
Bas Varkevisser
Ruth Malan
l-rs.org
Informatiekundig bekeken
Bredemeyer Consulting
Gaudi site
Hans Bot ArchITectuur Bedrijven
Security.nl
Byelex
XR Magazine



Diversen

Powered by Pivot - 1.40.1: 'Dreadwind' 
XML: RSS Feed 
XML: Atom Feed 


« De 10 security domein… | Home | Non-functional requir… »

Redenen om te backuppen

Elk bedrijf doet aan back-ups. Ik heb echter meerdere ervaringen met backups die niet deden wat ervan verwacht werd.

Er zijn drie redenen om data te back-uppen:

  • In geval van een technische storing of een gebruikersfout worden files gewist. Deze files dienen te worden teruggezet;
  • Na een disaster dient een recovery te kunnen worden uitgevoerd;
  • Sommige data dient lang bewaard te blijven: ook wel archivering genoemd.

Elk van de drie redenen zal ik hieronder toelichten.

Gewiste- of beschadigde files

In geval van een gebruikersfout (iemand gooit een mailtje of een belangrijk Word bestand weg), kan het nodig zijn om een file te restoren. Ook na een virusuitbraak kan het nodig zijn data te restoren.

Backups van dit soort files dienen dan ook regelmatig gemaakt te worden (meestal dagelijks). Het verdient ook aanbeveling de back-ups bij de hand te hebben gedurende de dag, dus niet in een uitwijkcentrum op twee uur rijden afstand.

Let op: alle data op gesynchroniseerde disks op een andere plaats opslaan werkt hier niet! Als men een filetje weggooit, of een filetje krijgt een virus, dan is op de gesynchroniseerde disk het filetje ook niet meer bruikbaar.

Uiteraard is er altijd een periode waar dataverlies kan optreden: als iemand 's morgens een brief heeft geschreven, en per ongeluk geeft gewist voordat 's nachts een back-up wordt gemaakt, dan is de file verdwenen. Er zijn overigens technische oplossingen om dit soort situaties te voorkomen (zoals altijd een on-line kopie bewaren van elke file), maar voor normale toepassingen zijn deze oplossingen vaak te duur en te ingewikkeld.

Disaster recovery

In geval van een catastrofe, zoals een brand, overstroming, instorting of ontploffing zijn de fysieke gegevensdragers niet langer beschikbaar. Er dienen back-ups te zijn om de oorspronkelijke situatie (op een andere plek) te herstellen.

Het is daarom belangrijk backups te hebben van niet alleen de data, maar ook van de Operating Systems, en van de (papieren) procedures om de machines weer op te bouwen. Ook is het goed om een uitwijkcentrum te hebben, en een mogelijkheid om snel aan vervangende hardware te komen.

Back-ups voor disaster recovery dienen op een veilige plaats te zijn opgeslagen, zodat ze niet vernietigd of beschadigd raken bij de calamiteit. De vuurwerkramp heeft ons geleerd dat een afstand van tenminste 5 km dient te worden aangehouden (dus niet bij de buren opslaan!).

Het is cruciaal dat de restore procedure in zijn geheel tenminste jaarlijks wordt getest, inclusief het opbouwen van hardware!

Archivering

In de archiefwet staat dat bedrijven en instellingen dienen vast te stellen hoe lang historische data bewaard moet worden. Zo houdt de belastingdienst een periode van 7 jaar aan.

Er moeten back-upvoorzieningen zijn die de data opslaat voor de vastgestelde bewaartermijn. Uiteraard dienen de back-ups op een veilige plaats te worden opgeborgen, onder klimatologisch verantwoorde omstandigheden.

In dit artikel ga ik in de specifieke eisen die aan archivering moeten worden gesteld.

Backup en de business eisen

Het heeft geen zin om data te back-uppen die niet restored kan worden. Ik heb hiervan meerdere voorbeelden in de praktijk gezien.

Eén voorbeeld ging om een server met een dermate ingewikkelde filestructuur, dat het back-uppen wel ging, maar waarbij het restoren van de machine enkele weken zou gaan duren. Dit was onacceptabel voor de business.

Een tweede voorbeeld was bij een bedrijf dat slechts een deel van een hele keten was. Het bedrijf kon wel data restoren, maar dit kon alleen als de ketenpartners ook allemaal een paar dagen terug in de tijd zouden gaan. Uiteraard is dit niet mogelijk.

Een zeer lezenswaardig artikel is "The TAO of Back-up". Klik op de pijltjes voor het hele verhaal.



En... Wat vindt u ervan? Klik hier om uw mening te geven:



  
Remember personal info?

Emoticons / Textile


 

  ( Register your username / Log in )

Notify:
Hide email:

Small print: All html tags except <b> and <i> will be removed from your comment. You can make links by just typing the url or mail-address.

Over Sjaak Laan

Sjaak Laan

Ik ben 45 jaar oud, getrouwd met Angelina, en we hebben 3 kinderen van 12, 7 en 5 jaar oud. Ik woon in Friesland (Drachten).

Ik werk voor Logica als Principal IT Architect. Ik heb 20 jaar IT ervaring.

Ik bezit de volgende certificaten:

ITAC Master Certified IT Architect


CISSP_logo CISSP (Certified Information Systems Security Professional)


TOGAF8_Certified_web TOGAF Certified Architect



Ik ben lid van:


Mijn zakelijke contacten onderhoud ik via Linkedin.

U kunt mij ook volgen op Twitter: twitter.com/sjaaklaan

U kunt mij bereiken via sjaak.laan [ a t ] gmail [puntje] com.

Deze site bevat mijn eigen mening, en niet noodzakelijkerwijs die van mijn werkgever of van de klanten waar ik voor werk.