WCM Forum

WCM Forum (http://www.wcm.at/forum/index.php)
-   Software (http://www.wcm.at/forum/forumdisplay.php?f=5)
-   -   Sicherung Win-7 von(!) Netzlaufwerk (http://www.wcm.at/forum/showthread.php?t=237622)

Quintus14 17.12.2009 20:14

Sicherung Win-7 von(!) Netzlaufwerk
 
Hi,

die Win-7-Ultimate-Version ermöglicht die Sicherung auf ein Netzlaufwerk. Ich bräuchte es umgekehrt - wie sichert man die Daten von einem Server, also von einem Netzlaufwerk?

Ich seh' weder eine Netzlaufwerkauswahl noch den Netzlaufwerksbuchstaben (N:\) bei den zu sichernden Daten.

Gibt's einen Trick, wie ich eine Sicherung der Serverdaten auf dem Win-7-Rechner realisieren könnte? Oder schreibt das Sicherungsprogramm die Aufträge irgendwo in eine config, die man manuell editieren könnte?

Thx

ZombyKillah 17.12.2009 21:06

robocopy
bzw. synctoy
Wobei ich mit einer Version 2.0 von SyncToy mal schlechte Erfahrung gemacht habe ...
Hat viele Daten zum NAS fehlerhaft übertragen und sinnlose Files angelegt.
Bei Version 2.1 steht dabei das ein solcher Bug bereits gefixt ist.

enjoy2 17.12.2009 21:41

http://personal-backup.rathlev-home.de/

einfach, gut und kostenlos

Quintus14 17.12.2009 21:54

Danke - ich dachte, dass man das neue Windows-Backup nun verwenden kann. Anscheinend doch wieder nur eine halbe Sache...

-----

Ich hab' ja noch ein BackupElements im Talon, wo ich zwei Lizenzen davon besitze - das funzt auch halbwegs. Ich hab's in der Zwischenzeit installiert und upgedatet - jetzt kann man endlich die blöden Popups ausschalten, die früher reihenweise über den BS gewandert sind.

Das, was nicht so funzt, ist das Archivieren nach Archivbit - der Server ist ein Lunixserver und da tut das mit dem Archivbit nicht. Auch 3 Dateien, die ich unter Linux weg kopiert hab', fallen jetzt als Fehler raus - vermutlich passt wieder der File-Owner nicht. Muss ich mir mal am Server ansehen, wenn Zeit ist.

Thx

enjoy2 17.12.2009 23:02

Zitat:

The archive bit is used to determine what files have been backuped up previously on a Windows filesystem. The bit is set if a file is modified. A backup program can then clear the bit when it does a full backup. This allows the backup program to do an incremental or differential backup that only backs up the changes to the filesystem since the last time the bit was cleared. Note that on programs like BrightStor ARCserve backup, you have a choice on full backups about whether or not to clear the archive bit. If you choose not to clear the archive bit, this is the same as a "copy" backup, where the backup does not affect the state of your scheduled backups. For instance, say you did a full backup over the weekend, and differential backups during the week. If you decide you want to upgrade a server and want to do a full backup, you could run a full backup on a separate set of tapes without changing the ever-growing nightly differential set of backups by choosing not to clear the archive bit. This would be particularly useful if you were not the one managing the regular backup process. If you don't do this, then the following day, when the differential runs (or incremental), you would need to have the second full backup you made to get a complete restore. The ext2 filesystem on GNU/Linux does not have an archive bit, but it does have three different time stamps (creation, modification, and access) that can be used to work around this. The problem, though, is you need an extra process to make decisions on this. Samba works around this by tweaking the owner bits on ext2. For an explanation on how this is done, and some further explanation of Windows filesystem bits, see this document. To determine what files have the archive bit set on a Windows (or DOS) filesystem, use:
http://www.netadmintools.com/art399.html

nachdem Ext kein Archivbit kennt, wird dies nicht so funktionieren

FranzK 18.12.2009 01:30

Zitat:

Zitat von ZombyKillah (Beitrag 2394575)
...
Wobei ich mit einer Version 2.0 von SyncToy mal schlechte Erfahrung gemacht habe ...
Hat viele Daten zum NAS fehlerhaft übertragen und sinnlose Files angelegt.
...

Ich habe dunkel in Erinnerung, dass bei der Beschreibung von Synctoy explizit darauf hingewiesen wird, dass es bei Verwendung von NAS zu Problemen kommen kann. Diese Geräte kommen oft mit der optimierten Datenübertragung von Synctoy nicht zurecht. Synctoy braucht echte Windows-Netzwerk-Clients.

:hallo:

FranzK 18.12.2009 01:40

Zitat:

Zitat von Quintus14 (Beitrag 2394592)
Danke - ich dachte, dass man das neue Windows-Backup nun verwenden kann. Anscheinend doch wieder nur eine halbe Sache...
...

Das ist eine unsinnige Aussage! Das Windows-Backup-Programm ist dazu da, die Daten des Windows, auf dem es läuft zu sichern. Diese Aufgabe erfüllt es ziemlich gut. Es ist aber NICHT dafür gedacht, die Daten eines anderen Servers zu sichern. Da gibt es nämlich innerhalb eines Netzwerks viele Hürden in Form von Berechtigungen. Nicht umsonst wird diese Aufgabe zumeist Backup-Programmen auf dem Server übertragen, da sie dort in der Regel automatisch nach der Installation über die entsprechenden Rechte verfügen. Daher solltest auch du das Backup-Programm deines Servers zu seiner Datensicherung verwenden.

:hallo:

Quintus14 18.12.2009 03:22

Zitat:

Zitat von FranzK (Beitrag 2394608)
Das ist eine unsinnige Aussage! Das Windows-Backup-Programm ist dazu da, die Daten des Windows, auf dem es läuft zu sichern. ....

Es ist aber nicht einzusehen, wieso dieses Tool so kastriert sein muss, dass man nicht Daten aus eingebundenen Netzlaufwerken in die Datensicherung mit einbeziehen kann.

Danke für den Tipp mit dem Server - vielleicht bau' ich da mal eine zusätzliche Datensicherung ein.

Quintus

LouCypher 18.12.2009 08:15

ich glaub diese beschränkungs gibts nur via gui, probiers mal übers cli

FranzK 18.12.2009 17:54

Zitat:

Zitat von Quintus14 (Beitrag 2394611)
Es ist aber nicht einzusehen, wieso dieses Tool so kastriert sein muss, dass man nicht Daten aus eingebundenen Netzlaufwerken in die Datensicherung mit einbeziehen kann.
...

Das hat nichts mit Kastration zu tun. Es ist nämlich gerade umgekehrt: wenn eine Sicherung von einem Netzwerk-Laufwerk wirklich gut funktionieren soll, müsste zusätzliche Funktionalität eingebaut werden (vor allem ein Rechte-Management). Und die Sicherung von Server-Daten von einer Arbeitsstation aus ist ohnehin eine höchst dubiose Angelegenheit, die bei richtiger Organisation eigentlich verboten ist. Ein Server darf eigentlich nur von einem anderen Rechner im Server-Rang gesichert werden (Backup-Server).

:hallo:

zigeina 19.12.2009 18:25

Zitat:

Zitat von FranzK (Beitrag 2394706)
Das hat nichts mit Kastration zu tun. Es ist nämlich gerade umgekehrt: wenn eine Sicherung von einem Netzwerk-Laufwerk wirklich gut funktionieren soll, müsste zusätzliche Funktionalität eingebaut werden (vor allem ein Rechte-Management). Und die Sicherung von Server-Daten von einer Arbeitsstation aus ist ohnehin eine höchst dubiose Angelegenheit, die bei richtiger Organisation eigentlich verboten ist. Ein Server darf eigentlich nur von einem anderen Rechner im Server-Rang gesichert werden (Backup-Server).

:hallo:

womöglich sieht der client nicht mal alle daten --> siehe rechteverwaltung :hammer:

Boot 26.12.2009 18:47

Zitat:

Zitat von zigeina (Beitrag 2394823)
womöglich sieht der client nicht mal alle daten --> siehe rechteverwaltung :hammer:

Es wird ihm eh nur um seine Daten gehen :rolleyes: Vielleicht will er sie am Server sichern :cool:


Ernsthaft fürn Quintus14: Wie ist eigentlich die Serversicherung vorgesehen? Rein prinzipiell Client -> Server -> Band oder sonstiges Somit ist die Datensicherung des Servers am Client nicht notwendig.

ZombyKillah 26.12.2009 19:53

Also ich sehe es auch als sinnlose Einschränkung, keine Netzwerklaufwerke lokal sichern zu können.
Argumente:
- Wenn der Server keine Einträge hat, wer die Daten einsehen darf, so gibt es keine Sicherheitseinstellungen ... die Standarteinstellungen werden übernommen.
Keine Änderung der Berechtigung
- Hat der Server solche Einträge, so können diese von der Backuproutine gelesen und übernommen werden.
Also auch kein Problem
Bis auf dass es sein, kann, dass die lokale Maschine mit manchen Einträgen nichts anfangen kann.

Dass es bei einen großen System so sein muss, dass sich der Administrator darum kümmert ist klar.
Aber im Homebereich wäre das eine vernünftige Funktion.

SyncToy war in der Vergangenheit auf robocopy basierend und hat somit Systemübergreifend (NAS egal ob MS oder etwas anderes) funktioniert.
Erst seit einiger Zeit wurde das ganze von MS optimiert ... was zu erhöhten Problemen führte ... wie jede Optimierung.

Quintus14 26.12.2009 21:09

Zitat:

Zitat von ZombyKillah (Beitrag 2395840)
Also ich sehe es auch als sinnlose Einschränkung,

Unter XP hat man auch mit der Windows-Sicherung ein Netzlaufwerke auswählen bzw. sichern können. Wenn es unter Windows-7 nicht mehr geht, ist das ein Rückschritt.

Zitat:

Zitat von LouCypher (Beitrag 2394621)
ich glaub diese beschränkungs gibts nur via gui, probiers mal übers cli

Meinst Du mit einem Line-Command? Da müsst' ich nachgraben, wie die Syntax geht.

----

Wie gesagt, ich hab' halt das alte BackupElements wieder installiert und die Jobs eingerichtet - es funzt bis auf die Tatsache, dass das Protokoll zugemüllt wird wegen unsinniger Meldungen wegen dem Archivbit. Und die Emailbenachrichtigung funzt unter Win-7 auch nicht (hab' ich seinerzeit unter XP nicht versucht).

Thx

ruffy_mike 27.12.2009 15:30

Zitat:

Zitat von ZombyKillah (Beitrag 2395840)
SyncToy war in der Vergangenheit auf robocopy basierend und hat somit Systemübergreifend (NAS egal ob MS oder etwas anderes) funktioniert.
Erst seit einiger Zeit wurde das ganze von MS optimiert ... was zu erhöhten Problemen führte ... wie jede Optimierung.

Nomen est omen ... anscheinend. Ich hatte das SyncToy auch probiert, und wollte ein paar GB (nicht dramatisch) auf ein gemapptes Samba-LW sichern. Nachdem die Analyse der Daten (ohne ein Byte kopiert zu haben) schon ewig lief hab ich das gleich wieder entfernt und synchronisiere jetzt mit rsync/DeltaCopy. Einmal eingelesen klappt das jetzt traumhaft!


Alle Zeitangaben in WEZ +2. Es ist jetzt 19:39 Uhr.

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag