sslug-teknik team mailing list archive
-
sslug-teknik team
-
Mailing list archive
-
Message #98742
Re: backup af filer der ændres løbende
On Tue, 28 Jul 2009 18:35:04 +0200
Egon Andersen <ean@xxxxxxxxx> wrote:
> Jeg har et spørgsmål om hvordan man sikrer sig, at en fil der
> ændrer sig under backup, faktisk er en 'gyldig' fil, altså at
> data ikke er blevet korrupt pga. ændring under selve backup'en.
Enten ved at stoppe alle programmer (eller boote et specielt
backup-system) og hvis det ikke er muligt (det er sjældent muligt)
så prøv at komme så tæt som muligt på samme situation.
For databaser kan det IKKE lade sig gøre, dér *skal* man bruge
hot-dump teknikken: (pg_dump, pg_dumpall eller mysqldump).
> Lad mig bruge det eksempel der faktisk triggede spørgsmålet.
> Jeg lavede backup af /var vha. en ret simpel tar-kommando.
> Da tar afslutter, kom der en meddelelse om at /var/mail/<xxx>
> blev ændret under backup'en.
>
> Okay, der ankom altså en email midt under at tar læste filen,
> hvilket naturligvis kan ske, specielt da filen er ganske stor.
> Betyder det at filen /var/mail/<xxx> gemt i tar-filen er den
> 'gamle' fil (uden den nyankomne email), den 'nye' fil (med den
> nyankomne email) eller noget der måske er hverken det ene eller
> det andet, altså en korrupt fil?
For en mbox-format mailfil kan der i værste fald ske det at den
bliver korrumperet. Man kan enten stoppe mailserver/klienter mens
backuppen kører eller lave nogle numre med at kopiere filen med en
låse option flock(1) - men det forudsætter at andre programmer
respekterer låsen og det behøver de ikke at gøre!
Hvis du vil være grov kan du remounte filsystemet read-only eller
på anden måde forhindre andre i at bruge systemet, mens der tages
backup. Hvis systemet er et heftigt drifts-system, så går den
naturligvis ikke. Den principielle løsning er et *nyt* filsystem ext4:
> Og hvordan forholder man sig generelt til problemstillingen, at
> en fil på systemet ændres netop i det tidsinterval der tages
> backup af den specifikke fil?
I nyeste version af ext4 skulle der komme en snap-shot facilitet,
hvor man ligesom i en database kan sige hvad tilstanden er på
tidspunkt XXX. Skriv/læs transaktioner noteres i en logfil.
On 19:59 Fri 25 Jan , Takashi Sato wrote:
http://www.mail-archive.com/linux-ext4@xxxxxxxxxxxxxxx/msg04601.html
> Currently, ext3 doesn't have the freeze feature which suspends write
> requests. So, we cannot get a backup which keeps the filesystem's
> consistency with the storage device's features (snapshot, replication)
> while it is mounted.
> In many case, a commercial filesystems (e.g. VxFS) has the freeze
> feature and it would be used to get the consistent backup.
First of all Linux already have at least one open-source(dm-snap),
and several commercial snapshot solutions. In fact dm-snaps it
not perfect:
a) bit map loading is not supported (this is useful for freezing
only used blocks) which causing significant slowdown even for new writes
b) non patched dm-snap code has significant performance slowdown for all
rewrite requests.
c) IMHO memory footprint is too big.
BUT, it works well for most file-systems.
--
Donald Axel <donax@xxxxxx>
Follow ups
References