Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #83339 > unrolled thread

Suche Script/Tool für Mehrgenerationen-Backup bzw. Archiv

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  Suche Script/Tool für Mehrgenerationen-Backup bzw. Archiv Sebastian Suchanek <sebastian.suchanek@gmx.de> - 2016-04-19 19:03 +0200
    Re: Suche Script/Tool für Mehrgenerationen-Backup bzw. Archiv Sven Hartge <sh-164@svenhartge.de> - 2016-04-19 19:20 +0200
      Re: Suche Script/Tool für Mehrgenerationen-Backup bzw. Archiv Sebastian Suchanek <sebastian.suchanek@gmx.de> - 2016-04-19 19:37 +0200
    Re: Suche Script/Tool für Mehrgenerationen-Backup bzw. Archiv Marcel Mueller <news.5.maazl@spamgourmet.org> - 2016-04-20 00:27 +0200
    Re: Suche Script/Tool für Mehrgenerationen-Backup bzw. Archiv "Juergen P. Meier" <nospam-1984@jors.net> - 2016-04-20 04:00 +0000
      Re: Suche Script/Tool für Mehrgenerationen-Backup bzw. Archiv Jan Novak <repcom@gmail.com> - 2016-04-20 08:05 +0200
        Backuppc (was: Suche Script/Tool für Mehrgenerationen-Backup bzw. Archiv) Christoph 'Mehdorn' Weber <spam-fuer@das-mehdorn.de> - 2016-04-29 12:05 +0200
          Re: Backuppc Jan Novak <repcom@gmail.com> - 2016-04-29 13:48 +0200
            Re: Backuppc Christoph 'Mehdorn' Weber <spam-fuer@das-mehdorn.de> - 2016-04-29 16:51 +0200
              Re: Backuppc Daniel Seuthe <usenet+dcoulm@seuthe.org> - 2016-05-03 05:53 +0000
                Re: Backuppc Holger Schieferdecker <spamless@gmx.de> - 2016-05-03 08:55 +0200
                  Re: Backuppc Christoph 'Mehdorn' Weber <spam-fuer@das-mehdorn.de> - 2016-05-11 15:58 +0200
                    Re: Backuppc Ulf Volmer <u.volmer@u-v.de> - 2016-05-11 22:59 +0200
                Re: Backuppc Marcus Jodorf <trap@killfile.de> - 2016-05-03 18:22 +0200
              Re: Backuppc "Helmut Hullen" <Helmut@Hullen.de> - 2016-05-03 10:35 +0200
                Re: Backuppc Marcus Jodorf <trap@killfile.de> - 2016-05-03 18:28 +0200

#83339 — Suche Script/Tool für Mehrgenerationen-Backup bzw. Archiv

Hallo NG!

Von einer MySQL-Datenbank erstelle ich jede Nacht einen Dump und
speichere den als Backup auf einem externen Rechner. Soweit als
Basis-Backup OK und als Cronjob trivial umsetzbar.

Allerdings hilft das nicht, wenn man Änderungen rückgängig machen
will/muss, die schon ein paar Tage (oder Wochen, Monate...)
zurückliegen. Daher hätte ich gerne eine Art degressive Staffelung der
Datenbank-Dumps, zum Beispiel in folgender Form:
- Jeder Dump der letzten sieben Tage soll aufgehoben werden.
- Von den davorliegenden Wochen (z.B. fünf) soll ein Dump je Woche
  aufgehoben werden.
- Von den davorliegenden zwölf Monaten soll ein Dump je Woche
  aufgehoben werden.
- Von den noch älteren Dumps soll einer pro Jahr "ewig" aufgehoben
  werden.
(Bei den absoluten Zahlen bin ich nicht festgelegt, die sollen nur als
Beispiel dienen.) Die Sicherungsdateien sollen dabei im ersten Schritt
nur im lokalen Dateisystem liegen bleiben, die weitere Sicherung kann
dann das breits vorhandene o.g. Sicherungsskript übernehmen.

Bevor ich jetzt selbst anfange, mit Shellskripten herumzudilettieren:
Kennt jemand von Euch zufällig ein Skript oder Tool, dass das o.g.
leistet? Zielsystem ist BTW Debian Wheezy mit ext3, d.h., irgendwelche
Dateisystem-Snapshot-Mechanismen stehen nicht zur Verfügung.


TIA,

Sebastian

[toc] | [next] | [standalone]

#83341

Sebastian Suchanek <sebastian.suchanek@gmx.de> wrote:

> Allerdings hilft das nicht, wenn man Änderungen rückgängig machen
> will/muss, die schon ein paar Tage (oder Wochen, Monate...)
> zurückliegen. Daher hätte ich gerne eine Art degressive Staffelung der
> Datenbank-Dumps, zum Beispiel in folgender Form:
> - Jeder Dump der letzten sieben Tage soll aufgehoben werden.
> - Von den davorliegenden Wochen (z.B. fünf) soll ein Dump je Woche
>   aufgehoben werden.
> - Von den davorliegenden zwölf Monaten soll ein Dump je Woche
>   aufgehoben werden.
> - Von den noch älteren Dumps soll einer pro Jahr "ewig" aufgehoben
>   werden.
> (Bei den absoluten Zahlen bin ich nicht festgelegt, die sollen nur als
> Beispiel dienen.) Die Sicherungsdateien sollen dabei im ersten Schritt
> nur im lokalen Dateisystem liegen bleiben, die weitere Sicherung kann
> dann das breits vorhandene o.g. Sicherungsskript übernehmen.

rsnapshot
backup2l

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#83343

Am 19.04.2016 um 19:20 schrieb Sven Hartge:

> [...]
> rsnapshot
> [...]

Danke, das sieht gut aus.


Tschüs,

Sebastian

[toc] | [prev] | [next] | [standalone]

#83357

On 19.04.16 19.03, Sebastian Suchanek wrote:
> - Jeder Dump der letzten sieben Tage soll aufgehoben werden.
> - Von den davorliegenden Wochen (z.B. fünf) soll ein Dump je Woche
>    aufgehoben werden.
> - Von den davorliegenden zwölf Monaten soll ein Dump je Woche
>    aufgehoben werden.
> - Von den noch älteren Dumps soll einer pro Jahr "ewig" aufgehoben
>    werden.

Ein weiterer cronjob, der Hardlinks der Backups in weitere Verzeichnisse 
macht, sollte es tun.

> Bevor ich jetzt selbst anfange, mit Shellskripten herumzudilettieren:

Das hört sich bisher nicht nach Raketenwissenschaft an. Wenn Du es schon 
geschafft hast, den Dump auf das Remote-System per Skript einzurichten, 
ist ein weiteres ln auch nicht mehr weit.


Marcel

[toc] | [prev] | [next] | [standalone]

#83359

Suchanek <sebastian.suchanek@gmx.de>:
> Bevor ich jetzt selbst anfange, mit Shellskripten herumzudilettieren:
> Kennt jemand von Euch zufällig ein Skript oder Tool, dass das o.g.
> leistet? Zielsystem ist BTW Debian Wheezy mit ext3, d.h., irgendwelche
> Dateisystem-Snapshot-Mechanismen stehen nicht zur Verfügung.

Du koenntest u.v.A. auch logrorate dazu misbrauchen deine Backupfiles
zu rotieren.

[toc] | [prev] | [next] | [standalone]

#83364

Am 20.04.2016 um 06:00 schrieb Juergen P. Meier:
> Suchanek <sebastian.suchanek@gmx.de>:
>> Bevor ich jetzt selbst anfange, mit Shellskripten herumzudilettieren:
>> Kennt jemand von Euch zufällig ein Skript oder Tool, dass das o.g.
>> leistet? Zielsystem ist BTW Debian Wheezy mit ext3, d.h., irgendwelche
>> Dateisystem-Snapshot-Mechanismen stehen nicht zur Verfügung.
>
> Du koenntest u.v.A. auch logrorate dazu misbrauchen deine Backupfiles
> zu rotieren.
>

Oder einfach eine Backupsoftware nutzen, welche alle Möglichkeiten 
bietet. Ich bin mit BackupPC super zufrieden.
-> http://backuppc.sourceforge.net/

Jan

[toc] | [prev] | [next] | [standalone]

#83528 — Backuppc (was: Suche Script/Tool für Mehrgenerationen-Backup bzw. Archiv)

Hallo!

* Jan Novak <repcom@gmail.com>:

> Ich bin mit BackupPC super zufrieden.
> -> http://backuppc.sourceforge.net/

  Dazu ein paar Fragen, denn ich möchte damit Systeme über eine
dünne Leitung per rsync sichern. Und leider beantwortet das
Handbuch das nicht optimal.

- Basieren die Full-Backups im rsync-Modus aufeinander oder wird
  es mir tatsächlich jede Woche GB-weise Daten durch die Leitung
  schaufeln?

  (Das inkrementelle Backups Full-Backups als Grundlage nutzen und
partielle Full-Backups für kommende Full-Backups genutzt werden
können, beantwortet das Handbuch. Aber bei rsync wäre es sinnvoll,
das letzte (Full-)Backup als Grundlage fürs aktuelle Backup zu
nutzen, und dazu finde ich nichts.)

- Falls ja, sind inkrementelle Backups überhaupt sinnvoll bzw.
  haben sie einen qualitativen/quantitativen Unterschied zum
  Full-Backup?

- Wie handhabt man Per-Host-Ausnahmen sinnvoll? Mit Override beim
  Host hat man, wenn man viele Hosts mit Ausnahmen hat, viele
  Overrides nachzubearbeiten, wenn man global eine Ausnahme
  hinzufügen will.

  (Ich habe ein Bespiel gesehen, wo die RsyncExtraArgs dazu
mißbraucht wurden, aber damit wird die Ausnahme auch automatisch
rsync-spezifisch, was ich nicht als optimale Lösung ansehe. Ich
habe vorerst "--filter=dir-merge,- .nobackup" in den globalen
rsync-Optionen verankert, damit ich auf den Clients Dateien mit
weiteren Excludes anlegen kann, aber das ist genauso
rsync-spezifisch.)

Christoph

-- 
Eher waere es sinnvoll, eine Art Killfile fuer's Web zu haben. Falls die
zu ladende Seite mit Frontpage oder Dreamweaver erstellt wurde, soll
der Browser warnen und rueckfragen, ob man sie WIRKLICH laden moechte.
(Hans-Joachim Zierke)

[toc] | [prev] | [next] | [standalone]

#83529 — Re: Backuppc

Am 29.04.2016 um 12:05 schrieb Christoph 'Mehdorn' Weber:
> Hallo!
>
> * Jan Novak <repcom@gmail.com>:
>
>> Ich bin mit BackupPC super zufrieden.
>> -> http://backuppc.sourceforge.net/
>
>   Dazu ein paar Fragen, denn ich möchte damit Systeme über eine
> dünne Leitung per rsync sichern. Und leider beantwortet das
> Handbuch das nicht optimal.
>
> - Basieren die Full-Backups im rsync-Modus aufeinander oder wird
>   es mir tatsächlich jede Woche GB-weise Daten durch die Leitung
>   schaufeln?

Also Full ist Full ...jedenfalls nach meinem Verständnis. Jedoch kannst 
du in den Einstellungen auch nur noch rsyncincrementell Backups machen, 
was letztendlich ja "immer" so aussieht wie Full backups

> - Falls ja, sind inkrementelle Backups überhaupt sinnvoll bzw.
>   haben sie einen qualitativen/quantitativen Unterschied zum
>   Full-Backup?

Absolut, siehe oben!


> - Wie handhabt man Per-Host-Ausnahmen sinnvoll? Mit Override beim
>   Host hat man, wenn man viele Hosts mit Ausnahmen hat, viele
>   Overrides nachzubearbeiten, wenn man global eine Ausnahme
>   hinzufügen will.

Tja, aber da wirst du wohl nicht drumherum kommen.

>
>   (Ich habe ein Bespiel gesehen, wo die RsyncExtraArgs dazu
> mißbraucht wurden, aber damit wird die Ausnahme auch automatisch
> rsync-spezifisch, was ich nicht als optimale Lösung ansehe. Ich
> habe vorerst "--filter=dir-merge,- .nobackup" in den globalen
> rsync-Optionen verankert, damit ich auf den Clients Dateien mit
> weiteren Excludes anlegen kann, aber das ist genauso
> rsync-spezifisch.)
An sich gute Idee. Allerdings habe ich das nie gebraucht, da ich nur 
einige Rechner sichere und da tuts der "Standard" wunderbar.

Jan

[toc] | [prev] | [next] | [standalone]

#83530 — Re: Backuppc

Hallo!

* Jan Novak <repcom@gmail.com>:

> Jedoch kannst du in den Einstellungen auch nur noch
> rsyncincrementell Backups machen, was letztendlich
> ja "immer" so aussieht wie Full backups

  Hm, aber wenn ich das richtig verstehe, braucht man mindestens
ein Full-Backup, auf denen die inkrementellen Updates dann direkt
basieren. Das dürfte mit der Zeit ziemlich auseinanderlaufen und
somit unnötig Platz verbraten. Aber vielleicht leiste ich mir ein
jährliches Full-Backup und mehrstufige inkrementelle Backups.

  Aber erst mal schauen und überlegen, ob ich den Traffic sinnvoll
messen kann. Da die Hosts sonst nicht viel miteinander reden,
könnte eine entsprechende iptables-Regel mit ihrem Zähler genügen.
Oder wo war da der Wraparound?

> An sich gute Idee. Allerdings habe ich das nie gebraucht, da ich
> nur einige Rechner sichere und da tuts der "Standard" wunderbar.

  Nun ja, bei mir sind es hauptsächlich Geschichten wie NFS. Am
Fileserver will man das /home mitsichern, auf den Clients nochmal
mitsichern wäre unnötig. Aber global /home ausschließen will ich
auch nicht. Ich könnte es natürlich anderswo mounten und
versymlinken, aber extra deswegen die Systeme umbauen?

  Ansonsten hab ich durchaus schon ein paar globale Ausnahmen
getroffen, die auf den wenigsten Rechnern relevant sein dürften.
Momentan sieht meine Liste so aus:

    '/media/*',
    '/proc/*',
    '/run/*',
    '/sys/*',
    '/tmp/*',
    '/var/cache/apt-cacher-ng/*',
    '/var/cache/apt/*',
    '/var/cache/pbuilder/build/*',
    '/var/lib/amavis/tmp/*',
    '/var/lib/apt/lists/*',
    '/var/lib/backuppc/*',
    '/var/lib/munin/*.tmp',
    '/var/lib/php5/sess_*',
    '/var/lock/*',
    '/var/log/*',
    '/var/run/*',
    '/var/spool/exim4/*',
    '/var/spool/postfix/*',
    '/var/tmp/*',

  Klar, einige Einträge könnte ich vermeiden, wenn ich "-x"
aktiviere, aber die Gefahr, etwas wichtiges im Backup zu
vergessen, wiegt meiner Meinung nach schwerer als ein unnötig
großes Backup.

Christoph

-- 
"Der Durchschnittsamerikaner besitzt laut FBI ein Hemd und eine Hose."
(Nico Hoffmann)

[toc] | [prev] | [next] | [standalone]

#83548 — Re: Backuppc

Christoph 'Mehdorn' Weber schrieb:
> Hallo!
>
> * Jan Novak <repcom@gmail.com>:
>
>> Jedoch kannst du in den Einstellungen auch nur noch
>> rsyncincrementell Backups machen, was letztendlich
>> ja "immer" so aussieht wie Full backups
>
>   Hm, aber wenn ich das richtig verstehe, braucht man mindestens
> ein Full-Backup, auf denen die inkrementellen Updates dann direkt
> basieren. Das dürfte mit der Zeit ziemlich auseinanderlaufen und

Deshalb muß man ja auch regelmäßig ein Full-Backup durchführen.

> somit unnötig Platz verbraten. Aber vielleicht leiste ich mir ein
> jährliches Full-Backup und mehrstufige inkrementelle Backups.

Ein jährliches Full-Backup ist zu selten. Täglich, wöchentlich oder
monatlich sind sinnvollere Intervalle. Das Ganze hängt natürlich von
der Backup-Strategie bzw. den zu sichernden Daten ab. Du darfst nicht
vergessen, daß bei einer kompletten Rücksicherung mit dem letzten
Full-Backup angefangen werden muß. Du willst sicherlich nicht im
Extremfall die inkrementellen Backups eines ganzen Jahres zurück-
spielen müssen.

Daniel
-- 
http://seuthe.org

[toc] | [prev] | [next] | [standalone]

#83549 — Re: Backuppc

Am 03.05.2016 um 07:53 schrieb Daniel Seuthe:
> Christoph 'Mehdorn' Weber schrieb:
>> Hallo!
>>
>> * Jan Novak <repcom@gmail.com>:
>>
>>> Jedoch kannst du in den Einstellungen auch nur noch
>>> rsyncincrementell Backups machen, was letztendlich
>>> ja "immer" so aussieht wie Full backups
>>
>>    Hm, aber wenn ich das richtig verstehe, braucht man mindestens
>> ein Full-Backup, auf denen die inkrementellen Updates dann direkt
>> basieren. Das dürfte mit der Zeit ziemlich auseinanderlaufen und

Man braucht am Anfang immer ein Full-Backup, zum Thema auseinanderlaufen 
siehe unten.

> Deshalb muß man ja auch regelmäßig ein Full-Backup durchführen.
>
>> somit unnötig Platz verbraten. Aber vielleicht leiste ich mir ein
>> jährliches Full-Backup und mehrstufige inkrementelle Backups.
>
> Ein jährliches Full-Backup ist zu selten. Täglich, wöchentlich oder
> monatlich sind sinnvollere Intervalle. Das Ganze hängt natürlich von
> der Backup-Strategie bzw. den zu sichernden Daten ab. Du darfst nicht
> vergessen, daß bei einer kompletten Rücksicherung mit dem letzten
> Full-Backup angefangen werden muß. Du willst sicherlich nicht im
> Extremfall die inkrementellen Backups eines ganzen Jahres zurück-
> spielen müssen.

Ich kenne jetzt das Programm BackupPC nicht, aber rsync an sich bietet 
ja die Option --link-dest="...". Wenn hier der Pfad zum vorherigen 
Backup angegeben wird, werden nur geänderte Dateien übertragen und für 
die gleichen dann Hardlinks auf das vorherige Backup erzeugt. Damit ist 
ein inkrementelles von einem Full-Backup nicht mehr zu unterscheiden, 
und die Rücksicherung geht einfach. Das schrieb weiter oben ja Jan Novak 
bereits.

Wenn allerdings eine Datei so eines Backups unlesbar wird 
(Plattenfehler, etc.), dann schlägt das durch die Hardlinks auf alle 
Backupversionen durch. Somit empfiehlt sich zweifellos von Zeit zu Zeit 
ein neues Full-Backup ohne Hardlinks. Der Zeitraum kann natürlich 
diskutiert werden.

Da in der Beschreibung von BackupPC steht, daß es identische Dateien nur 
einmal speichert, dürfte es wohl mit dieser Strategie fahren.

Gruß
Holger

[toc] | [prev] | [next] | [standalone]

#83794 — Re: Backuppc

Hallo!

* Holger Schieferdecker <spamless@gmx.de>:

> Ich kenne jetzt das Programm BackupPC nicht, aber rsync an sich bietet 
> ja die Option --link-dest="...". Wenn hier der Pfad zum vorherigen 
> Backup angegeben wird, werden nur geänderte Dateien übertragen und für 
> die gleichen dann Hardlinks auf das vorherige Backup erzeugt.

  Offenbar macht backuppc das implizit. Die Woche ist rum, das
zweite reguläre Full-Backup gelaufen und die zufällig
herausgepickte /etc/login.defs hat einen erhöhten Link-Count.

  Zudem ging das Backup von 4.8GiB mit Ratenlimit von 50kB/s in
ca. 30 Minuten durch, was rechnerisch nicht möglich sein sollte.
(Mein Accounting habe ich kurzfristig optimieren wollen und dabei
kaputtgemacht.)

  Damit basieren bei backuppc im rsync-Modus offenbar auch die
Full-Backups auf vorherigen Backups.

> Damit ist ein inkrementelles von einem Full-Backup nicht mehr zu
> unterscheiden, und die Rücksicherung geht einfach.

  Unterscheiden tut backuppc das schon intern, und die
Inkrementellen Backups gehen jeweils auch in 10 Minuten durch.
Irgendwas wird da schon anders laufen.

  Ums Rücksichern kümmert sich übrigens auch backuppc, insofern
muß man sich nicht darum kümmern, ob das Backup voll oder
inkrementell ist.

> Wenn allerdings eine Datei so eines Backups unlesbar wird
> (Plattenfehler, etc.), dann schlägt das durch die Hardlinks auf
> alle Backupversionen durch. Somit empfiehlt sich zweifellos von
> Zeit zu Zeit ein neues Full-Backup ohne Hardlinks.

  Wobei man anmerken muß, daß backuppc zur Beschleunigung der
Backups die Prüfsummen zwischenspeichert und gelegentlich prüft.
Das hilft zwar nicht gegen Bitkipper, aber sie werden zumindest
entdeckt und im nächsten Backup die Daten erneuert.

> Da in der Beschreibung von BackupPC steht, daß es identische
> Dateien nur einmal speichert, dürfte es wohl mit dieser
> Strategie fahren.

  Da man es nicht zwingend im rsync-Modus betreiben muß, war ich
mir nicht sicher, wo die Identität festgestellt wird. Aber
offenbar gehen (zumindest im rsync-Modus) die Dateien nicht erst
noch einmal über die Leitung.

Christoph

-- 
[Mobiltelefon] Hat ausserdem noch richtige Tasten und
ist nicht fuer Mikroben mit Miniwinzwuergfingern gebaut.
(Helmut Fromberger)

[toc] | [prev] | [next] | [standalone]

#83797 — Re: Backuppc

Christoph 'Mehdorn' Weber <spam-fuer@das-mehdorn.de> schrieb:
> * Holger Schieferdecker <spamless@gmx.de>:

>> Da in der Beschreibung von BackupPC steht, daß es identische
>> Dateien nur einmal speichert, dürfte es wohl mit dieser
>> Strategie fahren.
>
>   Da man es nicht zwingend im rsync-Modus betreiben muß, war ich
> mir nicht sicher, wo die Identität festgestellt wird. 

M.W. macht BackupPC regelmäßig Dedup- Läufe über den Backup- Bestand.
Sowohl Backup- als auch Client übergreifend.

Viele Grüße
Ulf

[toc] | [prev] | [next] | [standalone]

#83555 — Re: Backuppc

Daniel Seuthe <usenet+dcoulm@seuthe.org> schrieb:

> Das Ganze hängt natürlich von der Backup-Strategie bzw. den zu sichernden
> Daten ab. Du darfst nicht vergessen, daß bei einer kompletten Rücksicherung
> mit dem letzten Full-Backup angefangen werden muß. Du willst sicherlich
> nicht im Extremfall die inkrementellen Backups eines ganzen Jahres zurück-
> spielen müssen.

Bessere Mechanismen machen ein reverse incremental backup. Also das
Ganze umgedreht.
D.h. das letzte Backup ist immer das full backup und Vorversionen sind
incremental. Beispiel unter Linux: rdiff-backup



Gruß,

Marcus
⚂⚃

[toc] | [prev] | [next] | [standalone]

#83550 — Re: Backuppc

Hallo, Christoph,

Du meintest am 29.04.16:

>> Jedoch kannst du in den Einstellungen auch nur noch
>> rsyncincrementell Backups machen, was letztendlich
>> ja "immer" so aussieht wie Full backups

>   Hm, aber wenn ich das richtig verstehe, braucht man mindestens
> ein Full-Backup, auf denen die inkrementellen Updates dann direkt
> basieren.

Es sei denn, Du nimmst "rsnapshot" (bei Apple heisst das "TimeMachine");  
das arbeitet mit "rsync" sowie mit Hardlinks. Nix mit inkrementellen  
Backups.

Siehe auch
        http://arktur.de/Wiki/Rsnapshot

Viele Gruesse
Helmut

"Ubuntu" - an African word, meaning "Slackware is too hard for me".

[toc] | [prev] | [next] | [standalone]

#83556 — Re: Backuppc

Helmut Hullen <Helmut@hullen.de> schrieb:

> Es sei denn, Du nimmst "rsnapshot" (bei Apple heisst das "TimeMachine");
> das arbeitet mit "rsync" sowie mit Hardlinks. Nix mit inkrementellen
> Backups.

Wobei man noch anmerken sollte, daß TimeMachine nicht rsnapshot ist,
sondern ein sehr spezielles Apple-Eigengewächs.
Beispielsweise arbeitet das auch mit Hardlinks auf Verzeichnissen, was
sonst nat. nirgendswo geht, verriegelt das Backup gegen Löschzugriffe (auch
von root), speichert über Netz in viele kleine Diskimages, Restore ist
in viele Anwendungen integriert, usw.
Mit rsnapshot kann man da nur eine sehr primitive Version davon
nachbauen.



Gruß,

Marcus
⚂⚃

[toc] | [prev] | [standalone]

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web