OVH Cloud OVH Cloud

Sauvegarde

43 réponses
Avatar
Jean-Jacques Gerbaud
Bonjour

(désolé si le sujet a déjà été abordé)

Je suis sous LinuxMint. J'ai plusieurs partitions de 150, 200, 280 Go.
Plusieurs sont bien remplies. J'ai également un disque dur externe de
500 Go sur lequel se trouvent 2 partitions en ext4 (251 et 95 Go) et 1
autre en ntfs (100 Go).

Lors de sauvegarde avec rsync, elle se se fait dans /media/user.

Il se trouve que /media *fait partie de la racine*. Dans ces conditions,
je ne peux pas utiliser mon disque dur externe car la sauvegarde est
supérieure à la capacité de la partition de /media/user/sauvegarde.

Comment faire pour pouvoir utiliser mon disque dur externe comme outil
de sauvegarde, ce pourquoi il est généralement destiné.


--
JJG

Entre Dauphiné et PACA!
découvrez la généalogie et l'histoire de votre famille :
http://memoire-des-hommes.fr/

3 réponses

1 2 3 4 5
Avatar
pehache
Le 15/02/2017 à 12:02, Nicolas George a écrit :
Lucas Levrel , dans le message
, a écrit :
Si chaque utilisateur a son propre groupe, ça n'a plus de sens pour eux
d'avoir trois niveaux de permissions u/g/o vu que u=g.

Si tous les utilisateurs sont dans le même groupe, ça n'a plus de sens
pour eux d'avoir trois niveaux de permissions u/g/o vu que g=o.
On peut concevoir aussi que l'admin veuille donner des droits d'accès
spécifiquement aux « humains » et pas aux démons, auquel cas il suffit
de
régler le groupe sur « users » plutôt que d'ajouter chaque compte aux
ACL
(et devoir le faire à chaque nouvelle création de compte).

On peut concevoir plein de choses. Tellement, en fait, qu'il est oiseux
de spéculer. Il faut que l'infrastructure soit là, évidemment, pour
pouvoir servir quand il y en a besoin. Mais en pratique la plupart des
gens n'en ont pas besoin dans un premier temps, et quand ça arrive c'est
tellement du cas-par-cas que ce qu'a fait la distribution par défaut est
souvent inadapté. Ce qui n'est pas un problème puisqu'il faut de toutes
façons faire le boulot.

Un groupe "user" pour les utilisateurs humains est quand même susceptible
d'avoir à un moment ou à un autre une utilité, alors que le schéma g=u
n'en a vraiment aucune.
Avatar
Lucas Levrel
Le 15 février 2017, à 11:34, pehache a écrit :
Un groupe "user" pour les utilisateurs humains est quand même susceptible
d'avoir à un moment ou à un autre une utilité, alors que le schéma g=u
n'en a vraiment aucune.

Ça pourrait en avoir si tu veux définir des droits à la Facebook : X peut
consulter les fichiers de Y et Z, et Y ceux de X mais pas Z, alors tu mets
chacun dans les groupes idoines.
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
Avatar
Erwan David
pehache écrivait :
Le 15/02/2017 à 12:02, Nicolas George a écrit :
Lucas Levrel , dans le message
, a écrit :
Si chaque utilisateur a son propre groupe, ça n'a plus de sens pour eux
d'avoir trois niveaux de permissions u/g/o vu que u=g.

Si tous les utilisateurs sont dans le même groupe, ça n'a plus de sens
pour eux d'avoir trois niveaux de permissions u/g/o vu que g=o.
On peut concevoir aussi que l'admin veuille donner des droits d'accès
spécifiquement aux « humains » et pas aux démons, auquel cas il suffit
de
régler le groupe sur « users » plutôt que d'ajouter chaque compte aux
ACL
(et devoir le faire à chaque nouvelle création de compte).

On peut concevoir plein de choses. Tellement, en fait, qu'il est oiseux
de spéculer. Il faut que l'infrastructure soit là, évidemment, pour
pouvoir servir quand il y en a besoin. Mais en pratique la plupart des
gens n'en ont pas besoin dans un premier temps, et quand ça arrive c'est
tellement du cas-par-cas que ce qu'a fait la distribution par défaut est
souvent inadapté. Ce qui n'est pas un problème puisqu'il faut de toutes
façons faire le boulot.

Un groupe "user" pour les utilisateurs humains est quand même susceptible
d'avoir à un moment ou à un autre une utilité, alors que le schéma g=u
n'en a vraiment aucune.

N'oublions pas qu'il s'agit là de défauts mis pour des machines a priori
isolées. Bien sûr que sur un site avec beaucoup d'utilisateurs on aura
des groupes mieux définis et une politique d'attribution. Mais on ne
créera pas les utilisateurs en ocal sur chaque machine, ça sera
centralisé (par exemple via ldap)
--
Les simplifications c'est trop compliqué
1 2 3 4 5