Martijn Lievaart wrote:
> Ik heb eens een slechte batch meegemaakt die geinstalleerd was op 400
> locaties wereldwijd. Met data op de schijven die beslist geheim moest
> blijven. Dat betekende mannetjes met diplomatieke onschendbaarheid en
> koffers vol harde schijven, vliegtuig in, vliegtuig uit.....

Tot hij bij de USofA douane komt en ze zijn data willen bekijken. Of de
schijven bekijken of niet binnen en de mogenlijkheid dat ze de schijven
in beslag nemen. Heeft die diplomatieke onschendbaarheid niet echt veel
te zeggen tegenwoordig.

houghi

Peter Peters wrote:
> Het voordeel van backup op USB is dat je de schijf 's avonds mee kunt
> nemen (en zelfs met geschikte procedures overdag als er brand uitbreekt).

Het nadeel van een backup op USB is dat je de schijf mee kunt nemen en
dus de data verliezen.

ervaring die ik gehad heb met beackups waar manuele handelingen voor
nodig waren. Gaat een hele tijd goed, tot de drie perdonen die elkaars
backup zijn iets anders gaan doen.

Niet tegelijk natuurlijk. Eerst eentje op vakantie en een andere een
andere baan. Dat gaat nog prima. Wordt er eentje onstlsagen zijn ze nog
met 2. Eentje met vakantie en eentje ziek. Gaat nog een tijd goed.
Op een bepaald moment wordt er minder aandacht aan besteed.

Het begint met 'we gaan met zijn allen wat drinken' en dan wil je
natuurlijk niet die disk bij je hebben. Dat gaat ook een tijd goed, tot
je in een situatie komt waar die USB eigenlijk gewoon op zijn plaats
blijft.

Neem nooit aan dat iedereen op de zelfde manier met data en backups
omgaat als jezelf.

houghi

"Martijn Lievaart" <m> schreef in bericht
news:4156
> On Thu, 03 Jul 2008 14:50:08 +0200, Peter Peters wrote:
>> Ik heb eens een slechte batch meegemaakt die geinstalleerd was op 400
> locaties wereldwijd. Met data op de schijven die beslist geheim moest
> blijven. Dat betekende mannetjes met diplomatieke onschendbaarheid en
> koffers vol harde schijven, vliegtuig in, vliegtuig uit.....
>
> M4

Gegevens die absoluut geheim moeten blijven neem je niet mee!
Dat is al lek nummer 1 in de beveiliging.

Frank

On Thu, 03 Jul 2008 16:31:29 +0200, FD wrote:

> Gegevens die absoluut geheim moeten blijven neem je niet mee! Dat is al
> lek nummer 1 in de beveiliging.

De schijf die je professioneel gedemagnetiseerd hebt, moet daarna nog
professioneel vernietigd. Dus die schijf moet wel mee. De gegevens
natuurlijk niet.

M4

On Thu, 03 Jul 2008 16:02:52 +0200, houghi wrote:

> Martijn Lievaart wrote:
>> Ik heb eens een slechte batch meegemaakt die geinstalleerd was op 400
>> locaties wereldwijd. Met data op de schijven die beslist geheim moest
>> blijven. Dat betekende mannetjes met diplomatieke onschendbaarheid en
>> koffers vol harde schijven, vliegtuig in, vliegtuig uit.....
>
> Tot hij bij de USofA douane komt en ze zijn data willen bekijken. Of de
> schijven bekijken of niet binnen en de mogenlijkheid dat ze de schijven
> in beslag nemen. Heeft die diplomatieke onschendbaarheid niet echt veel
> te zeggen tegenwoordig.

In dit specifieke geval, denk ik dat er dan eerst een telefoontje van (de
voorganger van) Verhagen naar het juiste department was gegaan, en als
dat niet geholpen had een telefoontje van (de voorganger van) Balkenende
naar (de voorganger van) Bush was gegaan.

Ik weet niet of en wat voor moeilijkheden ze tegengekomen zijn, maar ik
werwacht niet erg veel.

M4

quoting Guido van Brakel (Thu, 03 Jul 2008 14:53:27 +0200):
> Peter Peters schreef:
>> Het voordeel van backup op USB is dat je de schijf 's avonds mee kunt
>> nemen (en zelfs met geschikte procedures overdag als er brand
>> uitbreekt).
>
> Dat kan met een tape ook :D

Al eens naar het prijsverschil gekeken?

houghi wrote on 3-7-2008 16:09:
> Peter Peters wrote:
>> Het voordeel van backup op USB is dat je de schijf 's avonds mee kunt
>> nemen (en zelfs met geschikte procedures overdag als er brand uitbreekt).
>
> Het nadeel van een backup op USB is dat je de schijf mee kunt nemen en
> dus de data verliezen.

Versleutel de data op de schijf. Dat is (nog steeds) eenvoudiger dan op
tape. Die je trouwens ook kunt verliezen.

> ervaring die ik gehad heb met beackups waar manuele handelingen voor
> nodig waren. Gaat een hele tijd goed, tot de drie perdonen die elkaars
> backup zijn iets anders gaan doen.

Dat klopt natuurlijk. Maar hetzelfde geldt met scripts als niet
dagelijks naar de meldingen wordt gekeken. Hier ook zoiets gezien. De
resultaten werden gemaild naar een beheerder. Die vertrok, dus de mail
kwam niet aan. De NDR ging naar root en dat werd geforward naar dezelfde
beheerder.

> Het begint met 'we gaan met zijn allen wat drinken' en dan wil je
> natuurlijk niet die disk bij je hebben. Dat gaat ook een tijd goed, tot
> je in een situatie komt waar die USB eigenlijk gewoon op zijn plaats
> blijft.

Oplossing is dan oftewel een datakluis voor data (inclusief server) of
backuppen naar extern. Maar dus wel met goede controles (zie boven).

> Neem nooit aan dat iedereen op de zelfde manier met data en backups
> omgaat als jezelf.

Ik durf niet te beweren dat ik er geen fouten mee zou maken.

Peter

Martijn Lievaart wrote:
> Ik weet niet of en wat voor moeilijkheden ze tegengekomen zijn, maar ik
> werwacht niet erg veel.

Ok, als er nog nooit problemen zijn geweest zullen die ook wel nooit
komen. ;-)


houghi

Peter Peters wrote:
> Versleutel de data op de schijf. Dat is (nog steeds) eenvoudiger dan op
> tape. Die je trouwens ook kunt verliezen.

En het paswoord was ... damn vergeten. ;-) Zo vaak als ik zie dat mensen
paswoorden vergeten is dat iets wat zal gebeuren.
Uiteraard gebeurd de versleuteling door een machine, zodat je dat
paswoord niet kunt verliezen en laat het nu net die gegevens zijn die je
nodig hebt, maar je kunt er niet aan want je hebt die gegevens niet ...

:-D

> Dat klopt natuurlijk. Maar hetzelfde geldt met scripts als niet
> dagelijks naar de meldingen wordt gekeken. Hier ook zoiets gezien. De
> resultaten werden gemaild naar een beheerder. Die vertrok, dus de mail
> kwam niet aan. De NDR ging naar root en dat werd geforward naar dezelfde
> beheerder.

Oh er zijn nog wel meer backup horror stories. Tapes zonder metaal er
op. Backups die leeg zijn. Restores die niet gtoegankelijk zijn.
Directories de niet gebackupped worden tewijl iedereen denkt van wel.

> Oplossing is dan oftewel een datakluis voor data (inclusief server) of
> backuppen naar extern. Maar dus wel met goede controles (zie boven).

en buiten de controles regelmatig het proberen van een restore.

>> Neem nooit aan dat iedereen op de zelfde manier met data en backups
>> omgaat als jezelf.
>
> Ik durf niet te beweren dat ik er geen fouten mee zou maken.

Ik ook niet. De reden dat ik dit zo formuleerde is omdat er altijd wel
een slimme wil zijn dat HIJ dat nog nooit heeft voorgehad en dat het DUS
nooit kan gebeuren.

Heel veel zaken die ik geleerd heb in verband met backups is gewoon door
mijn eigen stomiteiten. ;-)

houghi

On Fri, 4 Jul 2008 11:58:17 +0200
houghi <houghi> wrote:

> Oh er zijn nog wel meer backup horror stories. Tapes zonder metaal er
> op. Backups die leeg zijn. Restores die niet gtoegankelijk zijn.
> Directories de niet gebackupped worden tewijl iedereen denkt van wel.

People need restore, not backup.

R.

richard lucassen wrote:
>> Oh er zijn nog wel meer backup horror stories. Tapes zonder metaal er
>> op. Backups die leeg zijn. Restores die niet gtoegankelijk zijn.
>> Directories de niet gebackupped worden tewijl iedereen denkt van wel.
>
> People need restore, not backup.

FULL ACK. Het is beter om eerst te kijken op welke manier je een restore
wil doen en dan kijken welke backup daar het beste bijpast.

houghi

On Fri, 04 Jul 2008 13:16:35 +0200, houghi wrote:

> richard lucassen wrote:
>>> Oh er zijn nog wel meer backup horror stories. Tapes zonder metaal er
>>> op. Backups die leeg zijn. Restores die niet gtoegankelijk zijn.
>>> Directories de niet gebackupped worden tewijl iedereen denkt van wel.
>>
>> People need restore, not backup.
>
> FULL ACK. Het is beter om eerst te kijken op welke manier je een restore
> wil doen en dan kijken welke backup daar het beste bijpast.

FULL ACK. En ook je restore procedures regelmatig te testen. Ik kan je
horrorstories vertellen over keurige backups, die plots toch niet zo 1 2
3 terug te zetten bleken te zijn, ook al lukt het uiteindelijk wel.

- Tivoli backup libraries naar andere tivoli instalaties verhuizen. Geen
rocketscience, maar ook niet zo triviaal dat je het wilt gaan uitvinden
als het nodig is.

- Bootmedia die plots niet meer booten door een upgrade ergens na de
laatste restore test en de crash.

- Restore software incompatible met de backup door een upgrade ergens.

- OBDR backups die plots op een niet OBDR drive teruggelezen moeten
worden, ook geen rocketscience, maar je moet even weten hoe.

Enz, enz...

Had een tijdje geleden zelf het geintje bij de hand dat de nieuwe rescue
media van fedora plots niet wilden booten op mijn oude firewall. Bugje in
de BIOS. Aangezien die bak altijd online was geupgrade, was er nooit een
boot van CD nodig geweest tot ik hem moest restoren. Dan maar met toms
booten. Maar dan moet je wel even weten dat je in busybox niet kunt
restoren met tar -z, je moet zcat | tar gebruiken. Allemaal geen ramp,
maar in plaats van een uurtje, ben je een halve dag bezig.

(En daarna bleek het filesystem niet corrupt te zijn, maar de ext3 driver
in de kernel een bug te hebben, na een verse mkfs+restore vond ie het fs
weer even corrupt als daarvoor. Duh!)

M4

Paul van der Vlis wrote:

> houghi schreef:
>> Paul van der Vlis wrote:
>>> Als de eerste disk kapot gaat en er een nieuwe in moet, kun je hem
>>> simpel omwisselen met de tweede, tenminste bij raid1.
>>> Met raid5 weet ik niet of dat kan.
>>
>> Kijk ook even bij raid6 of dat wat is.
>
> Raid6 kan niet met software raid, en wil je ook meestal niet. Het is
> vooral geschikt voor hele grote raids met veel disken. Er kunnen met
> raid6 2 disks kapot gaan in plaats van 1.

Ik wil wel RAID 6, al jaren. Om de een of andere reden willen mijn
klanten (en dus mijn back-up systemen) vaak stapeltjes terabytes
vullen.

>> Ik heb me laten vertellen dat als
>> je meerdere schijven koopt je meestal schijven van een zelfde batch
>> koopt, wat wil zeggen dat die eventueel de zelfde fout hebben en dus
>> eerder per twee uitvallen en dan heb je niets met je raid 5.
>> raid6 kan kapotte schijven aan.
>
> Nee dus.
>
> Meestal neem ik 2 disks en raid1, zoveel diskruimte heb je toch niet
> nodig? Het mooiste is om disks te nemen van een verschillend merk of
> type, maar het hoeft niet persee van mij.
>
> Als er een disk kapot gaat moet die gewoon snel vervangen worden, ik
> houd daarvoor een termijn van max. 1 week aan.

Ik zorg er altijd voor dat er al bij aanschaf reserve schijven van
hetzelfde type klaarliggen, alvast gemonteerd in reserve ramen, in of
naast het rack waar de server in hangt. Sommige mensen kunnen die
schroefjes niet fatsoenlijk bevestigen namelijk. ;-)

The entity, AKA Fred Mobach <fred> wrote :
(selectively-snipped-or-not-P)


> Ik zorg er altijd voor dat er al bij aanschaf reserve schijven van
> hetzelfde type klaarliggen, alvast gemonteerd in reserve ramen, in of
> naast het rack waar de server in hangt. Sommige mensen kunnen die
> schroefjes niet fatsoenlijk bevestigen namelijk. ;-)

Het hebben van backups is slechts 0.05% van je procedure, de ander 99.95% is
een werkend restored system. ;-)

Cor

Cor Gest wrote:

> The entity, AKA Fred Mobach <fred> wrote :
> (selectively-snipped-or-not-P)
>
>> Ik zorg er altijd voor dat er al bij aanschaf reserve schijven van
>> hetzelfde type klaarliggen, alvast gemonteerd in reserve ramen, in of
>> naast het rack waar de server in hangt. Sommige mensen kunnen die
>> schroefjes niet fatsoenlijk bevestigen namelijk. ;-)
>
> Het hebben van backups is slechts 0.05% van je procedure, de ander
> 99.95% is een werkend restored system. ;-)

Die restore procedure gebruiken we al jaren en heeft zich al vaak genoeg
kunnen bewijzen. ;-)

Geen GUI, gewoon rsync op de commandline na een fdisk aanroep.