---

Hvis man laver en fil-backup af en kørende maskine, så kan man vel godt
forvente at kunne restore alle programmer og konfig-filer til en konsistent
maskine.

Jeg forventer ikke at f.ex. mails, der var på vej igennem maskinen
nødvendigvis er i orden, men det er også af mindre betydning.

F.ex. databaser vil jeg, hvis ikke det er muligt at tage snapshots, lukke
ned og (enten eller) / (både og) tage en fil-backup og export.

Fil-backuppen kunne være en tar eller en mkisofs til en anden maskine.

--
---
http://members.ud.com/services/teams/team.htm?id=C47FB770-0A0A-452B-8851-874
646C2B375

---

In article <3b72ee0c$0$282$edfadb0f@dspool01.news.tele.dk>, "Leif Neland"
<leifn@neland.dk> wrote:
> Hvis man laver en fil-backup af en kørende maskine, så kan man vel godt
> forvente at kunne restore alle programmer og konfig-filer til en
> konsistent maskine.

Ja, givet at du ved hvad der skal holdes konsistent.

<snip>
>
> F.ex. databaser vil jeg, hvis ikke det er muligt at tage snapshots,
> lukke ned og (enten eller) / (både og) tage en fil-backup og export.
>
Specielt for databaser gælder det om at skelne mellem data og program!

De fleste "rigtige" databaseprogrammer kan eksportere en slags
"hot" backup under fuld drift.
Denne backup kan indlæses igen, hvis programmet er konsistent med det
program, der i sin tid lavede backuppen.
Hot backups er typisk (dem jeg har arbejdet med) ikke porterbare
mellem forskellige versioner af programmet.

Forholdene ved et database dump er stort set de samme som ved en hot backup.

Så mit råd er at lade databasen lave en backup af dine data, og lav så selv en
backup af selve databaseprogrammet + tilhørende konfigs/scripts etc.

Jeg vil ikke anbefale dig bare at lave en løsning med tar/cpio/dd, hvor du bare
dumper alle filer (data+program) ud på et bånd/brænder dem ud på en cd.,
med mindrer du lukker databasen ned,
ellers har du ingen garanti for at der er konsistens i dine data.

../Preben