---

Jeg har anvendt rdiff-backup i lang tid til lokal backup og det har fungeret
perfekt.

Nu får jeg alle mulige dumme fejl [1] og der er ikke ret meget hjælp at
hente på nettet.

I og for sig virker det bare lidt buggy og u-supported.

Findes der ikke andre der kan klare inkremental let og enkelt?





[1]

Previous backup seems to have failed, regressing destination now.
Warning, could not find mirror_metadata file.
Metadata will be read from filesystem instead.
Fatal Error: No metadata for time Sun Jun 7 08:52:22 2009 (1244357542)
found,
cannot regress

---

Morten P wrote:
> Jeg har anvendt rdiff-backup i lang tid til lokal backup og det har fungeret
> perfekt.
>
> Nu får jeg alle mulige dumme fejl [1] og der er ikke ret meget hjælp at
> hente på nettet.
>
> I og for sig virker det bare lidt buggy og u-supported.
>
> Findes der ikke andre der kan klare inkremental let og enkelt?

Jeg undersøgte mulighederne for et års tid siden. Jeg tror jeg
konkluderede at rdiff-backup godtnok var smart, men for langtsomt og
inkompatibelt mellem forskellige versioner, så det var svært at få
forskellige distro/årgange til at snakke sammen.

Det endte med at jeg blot brugte rsync med --link-dest.
Det giver noget, der ligner inkrementale backups. De fylder godtnok lidt
mere, men til gengæld kan de alle bruges som om de var fulde backups.
Og så er det hurtigere end rdiff-backup.

/Peter

---

Morten P wrote:

> Findes der ikke andre der kan klare inkremental let og enkelt?

Jeg bruger duplicity med stor fornøjelse.

--
Jesper Lund

---

On Tue, 22 Sep 2009 22:01:09 +0200, Morten P wrote:


> Findes der ikke andre der kan klare inkremental let og enkelt?

http://www.rsnapshot.org/

---

Morten P skrev:
> Jeg har anvendt rdiff-backup i lang tid til lokal backup og det har fungeret
> perfekt.
>
> Nu får jeg alle mulige dumme fejl [1] og der er ikke ret meget hjælp at
> hente på nettet.
>
> I og for sig virker det bare lidt buggy og u-supported.
>
> Findes der ikke andre der kan klare inkremental let og enkelt?
>
>
Faubackup

http://faubackup.sourceforge.net

faubackup uses a filesystem on a hard drive for incremental and full
backups. This enables the backup to be accessable through standard
filesystem tools.

Later Backups to the same filesystem will automatically be incremental,
as unchanged files are only hard−linked with the existing version of the
file.

Leif

---

Leif Neland skrev den 23-09-2009 20:13:
> Morten P skrev:
>> Jeg har anvendt rdiff-backup i lang tid til lokal backup og det har
>> fungeret perfekt.
>>
> Faubackup
>
> http://faubackup.sourceforge.net
>
> Later Backups to the same filesystem will automatically be incremental,
> as unchanged files are only hard−linked with the existing version of the
> file.

Jeg har tidligere arbejdet med backup via rsync og hardlinks. Dengang
prøvede vi en overgang at bruge ext3 til filsystem hvor backup'en blev
lagret, men pladsforbruget blev uventet stort, fordi hardlink'enes
ionoder brugte plads. Istedet måtte vi bruge reiserfs, hvor ionodernes
pladsforbrug ikke var et problem.

Siden dengang er reiserfs vist gået af mode (Hans Reiser har fået andet
at tænke på). Hvilke erfaringer er der nutildags med pladsforbruget til
ionoder og hardlinks i backup-versioner.


--
Morten Christensen

---

Den Sun, 27 Sep 2009 00:31:57 +0200 skrev Morten Christensen:
> Leif Neland skrev den 23-09-2009 20:13:
>> Morten P skrev:
>>> Jeg har anvendt rdiff-backup i lang tid til lokal backup og det har
>>> fungeret perfekt.
>>>
>> Faubackup
>>
>> http://faubackup.sourceforge.net
>>
>> Later Backups to the same filesystem will automatically be incremental,
>> as unchanged files are only hard?linked with the existing version of the
>> file.
>
> Jeg har tidligere arbejdet med backup via rsync og hardlinks. Dengang
> prøvede vi en overgang at bruge ext3 til filsystem hvor backup'en blev
> lagret, men pladsforbruget blev uventet stort, fordi hardlink'enes
> ionoder brugte plads. Istedet måtte vi bruge reiserfs, hvor ionodernes
> pladsforbrug ikke var et problem.

Ext3:

kfr:tmp$ echo test >fil1
kfr:tmp$ ln fil1 fil2
kfr:tmp$ ls -li fil*
11523087 -rw-r--r-- 2 kfr users 5 Sep 27 08:14 fil1
11523087 -rw-r--r-- 2 kfr users 5 Sep 27 08:14 fil2

^^^^^^^^ Samme inode.

Hvilket stemmer meget godt med at definitionen af en hardlink er at
det er samme inode.

Det er ikke symlinks du tænker på? De bruger netop en ekstra inode. Det
burde de nu også gøre i reiser, for det er i inode'n at ting som
user/group og permissions ligger. Men derudover bruger de plads til
stien linket peger på, og den mener jeg at reiser kan få plads til
i inode'n, i stedet for at skulle bruge en ekstra blok.

Et hurtigt check med "du", viser at ext3 også kan få plads til korte[1]
symlinks i inoden:

kfr:tmp$ ln -s fil1 fil3
kfr:tmp$ ln -s "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaa" fil4
kfr:tmp$ du -sh fil3 fil4
0 fil3
4.0K fil4

Mvh
Kent

[1] Uanset filsystem, vil der være tale om korte symlinks. Pladsen i
inoden er begrænset. Definitionen af "korte" vil naturligvis variere.
--
"The Brothers are History"

---

Kent Friis skrev den 27-09-2009 08:25:
> Den Sun, 27 Sep 2009 00:31:57 +0200 skrev Morten Christensen:

>>> http://faubackup.sourceforge.net
>>>
>>> Later Backups to the same filesystem will automatically be incremental,
>>> as unchanged files are only hard?linked with the existing version of the
>>> file.

>> Jeg har tidligere arbejdet med backup via rsync og hardlinks. Dengang
>> prøvede vi en overgang at bruge ext3 til filsystem hvor backup'en blev
>> lagret, men pladsforbruget blev uventet stort, fordi hardlink'enes
>> ionoder brugte plads. Istedet måtte vi bruge reiserfs, hvor ionodernes
>> pladsforbrug ikke var et problem.

> Ext3:
>
> kfr:tmp$ echo test >fil1
> kfr:tmp$ ln fil1 fil2
> kfr:tmp$ ls -li fil*
> 11523087 -rw-r--r-- 2 kfr users 5 Sep 27 08:14 fil1
> 11523087 -rw-r--r-- 2 kfr users 5 Sep 27 08:14 fil2
>
> ^^^^^^^^ Samme inode.
>
> Hvilket stemmer meget godt med at definitionen af en hardlink er at
> det er samme inode.
>
> Det er ikke symlinks du tænker på? De bruger netop en ekstra inode.

Nej. Det er hardlinks. Symlinks er vist ikke det rigtige værktøj når en
slettet fil skal findes på backup'en.

Problemet er formodentlig berørt i dette afsnit i Faubackup's manpage:

NOTES

Additionaly, you should be careful when creating your backup filesystem.
As directories cannot be shared across several backups, they consume an
considerable amount of inodes. On filesystems with a limited number of
inodes (like ext2), one may need to increase the inode limit on
filesystem creation


> [1] Uanset filsystem, vil der være tale om korte symlinks. Pladsen i
> inoden er begrænset. Definitionen af "korte" vil naturligvis variere.


--
Morten Christensen

---

Den Sun, 27 Sep 2009 11:10:38 +0200 skrev Morten Christensen:
> Kent Friis skrev den 27-09-2009 08:25:
>> Den Sun, 27 Sep 2009 00:31:57 +0200 skrev Morten Christensen:
>
>>>> http://faubackup.sourceforge.net
>>>>
>>>> Later Backups to the same filesystem will automatically be incremental,
>>>> as unchanged files are only hard?linked with the existing version of the
>>>> file.
>
>>> Jeg har tidligere arbejdet med backup via rsync og hardlinks. Dengang
>>> prøvede vi en overgang at bruge ext3 til filsystem hvor backup'en blev
>>> lagret, men pladsforbruget blev uventet stort, fordi hardlink'enes
>>> ionoder brugte plads. Istedet måtte vi bruge reiserfs, hvor ionodernes
>>> pladsforbrug ikke var et problem.
>
>> Ext3:
>>
>> kfr:tmp$ echo test >fil1
>> kfr:tmp$ ln fil1 fil2
>> kfr:tmp$ ls -li fil*
>> 11523087 -rw-r--r-- 2 kfr users 5 Sep 27 08:14 fil1
>> 11523087 -rw-r--r-- 2 kfr users 5 Sep 27 08:14 fil2
>>
>> ^^^^^^^^ Samme inode.
>>
>> Hvilket stemmer meget godt med at definitionen af en hardlink er at
>> det er samme inode.
>>
>> Det er ikke symlinks du tænker på? De bruger netop en ekstra inode.
>
> Nej. Det er hardlinks. Symlinks er vist ikke det rigtige værktøj når en
> slettet fil skal findes på backup'en.

Hvis formålet med at bruge links er at lave incremental backups der
stadig virker, kan symlinks godt være brugbart.

Snakker vi om en backup bestående af links til de data der tages backup
af, er ingen af delene egnet. Man kan lige så nemt komme til at
overskrive en fil som at slette den.

> Problemet er formodentlig berørt i dette afsnit i Faubackup's manpage:
>
> NOTES
>
> Additionaly, you should be careful when creating your backup filesystem.
> As directories cannot be shared across several backups, they consume an
> considerable amount of inodes. On filesystems with a limited number of
> inodes (like ext2), one may need to increase the inode limit on
> filesystem creation

Directories kan per definition ikke linkes, uanset filsystem. De vil
også tage plads på reiserfs.

Begrænsningen i antallet af inodes kan som der står i afsnittet sættes
op, så det bør ikke være en forhindring for at bruge ext3.

Mvh
Kent
--
"The Brothers are History"

---

Morten P skrev:
> Jeg har anvendt rdiff-backup i lang tid til lokal backup og det har fungeret
> perfekt.
>
For lige at hægte mig på tråden, er der et incrementalbackup-program,
der kan backup'e windows-servere til en linux-filserver?

Leif

---

Leif Neland wrote, On 2009-09-23 20:15:
> Morten P skrev:
>> Jeg har anvendt rdiff-backup i lang tid til lokal backup og det har
>> fungeret perfekt.
>>
> For lige at hægte mig på tråden, er der et incrementalbackup-program,
> der kan backup'e windows-servere til en linux-filserver?

Bacula

--
Vh. Georg

---

Leif Neland wrote:

> For lige at hægte mig på tråden, er der et incrementalbackup-program,
> der kan backup'e windows-servere til en linux-filserver?

Alle Windows incremental backup programmer, hvis de skriver til et Samba
share. Duplicity under Cygwin kan også bruges.

--
Jesper Lund