You're welcome. A pull system does rely on the server being secure, which
is why I don't use it for offsite backups to the cloud :-O
Wouldn't a push/pull combination be a good compromise?
The remote servers push their backups to their own location on a staging
server.
The backup-storage
I'd rather lose my backups than lose my backups and give up root
read/write to every system I back up. :)
If you want to leave your backup server open to exploitation attempts,
maybe you should be looking at a different solution :)
If open to exploitation attempts means accepting inbound
On Mon, 1 Jul 2013 23:24:55 -0700, Grant wrote:
I'd rather lose my backups than lose my backups and give up root
read/write to every system I back up. :)
If you want to leave your backup server open to exploitation attempts,
maybe you should be looking at a different solution :)
On Tue, July 2, 2013 10:08, Neil Bothwick wrote:
You're welcome. A pull system does rely on the server being secure, which
is why I don't use it for offsite backups to the cloud :-O
Wouldn't a push/pull combination be a good compromise?
The remote servers push their backups to their own
Isn't that a gaping security hole? I think this amounts to granting
the backup server root read access (and write access if you want to
restore) on each client?
How can you backup system files without root read access? You are
granting this to s specific user, one without a login
You did not tell us what are you trying to backup; entire system or just
particular files.
Right now I'm working on particular files and folders but it sounds
nice to eventually back up each system in its entirety. That does
sounds like a lot of data to move offsite though.
Are you afraid of
On Mon, 1 Jul 2013 01:39:56 -0700, Grant wrote:
Yes, but with push you have to secure each machine whereas with pull
backups it's only the server to secure. And you'd still need to grant
access to the server from the clients, which could be escalated. With
backuppc, the server does not
I'm planning to rsync --fake-super the important files from each
client to a particular folder on the backup server as an unprivileged
user and then have the backup server run rdiff-backup locally to
maintain a history of those files.
How does that work with files that aren't world-readable?
On Mon, 1 Jul 2013 05:29:58 -0700, Grant wrote:
It's a lot more work and doesn't cover everything. One of the
advantages of a pull system like BackupPC is that the only work
needed on the client is adding the backuppc user's key to authorized
keys. Everything else is done by the server.
It's a lot more work and doesn't cover everything. One of the
advantages of a pull system like BackupPC is that the only work
needed on the client is adding the backuppc user's key to authorized
keys. Everything else is done by the server. If the server cannot
contact the client, or the
On Mon, 1 Jul 2013 06:31:38 -0700, Grant wrote:
There is no sacrifice, you are running rsync as root on the client
either way. Alternatively, you could run rsyncd on the client, which
avoids the need for the server to be able to run an SSH session.
I think the sacrifice is that with
There is no sacrifice, you are running rsync as root on the client
either way. Alternatively, you could run rsyncd on the client, which
avoids the need for the server to be able to run an SSH session.
I think the sacrifice is that with the backuppc method, if someone
breaks into the
Am 01.07.2013 16:08, schrieb Grant:
There is no sacrifice, you are running rsync as root on the client
either way. Alternatively, you could run rsyncd on the client, which
avoids the need for the server to be able to run an SSH session.
I think the sacrifice is that with the backuppc method,
That' how we do it. The backuppc server is in our local lan, and only
accessible from local lan. It pulls backups from all our machines in
offsite data centers. To compromise our backuppc machine one would have
to physically break into our companies building.
But if somebody has physical
On Mon, 1 Jul 2013 16:14:02 -0700, Grant wrote:
I'd rather lose my backups than lose my backups and give up root
read/write to every system I back up. :)
If you want to leave your backup server open to exploitation attempts,
maybe you should be looking at a different solution :)
--
Neil
On Sat, 29 Jun 2013 16:42:33 -0700, Grant wrote:
Can anyone think of an automated method that remotely and securely
backs up data from one system to another, preserves permissions and
ownership, and keeps the backups safe even if the backed-up system is
compromised?
app-backup/backuppc
It
Can anyone think of an automated method that remotely and securely
backs up data from one system to another, preserves permissions and
ownership, and keeps the backups safe even if the backed-up system is
compromised?
app-backup/backuppc
It uses hard links, but to save space, so all
On Sun, 30 Jun 2013 01:11:35 -0700, Grant wrote:
app-backup/backuppc
It uses hard links, but to save space, so all versions of all files
are kept for your entire history, but unchanged files are kept only
once, even if present on multiple targets.
Thank you for the recommendation.
Am 30.06.2013 01:42, schrieb Grant:
Can anyone think of an automated method that remotely and securely
backs up data from one system to another, preserves permissions and
ownership, and keeps the backups safe even if the backed-up system is
compromised?
I did delve into bacula but decided
On 30/06/13 17:58, Stefan G. Weichinger wrote:
Am 30.06.2013 01:42, schrieb Grant:
Can anyone think of an automated method that remotely and securely
backs up data from one system to another, preserves permissions and
ownership, and keeps the backups safe even if the backed-up system is
On Sun, 30 Jun 2013 01:11:35 -0700
Grant wrote:
Can anyone think of an automated method that remotely and securely
backs up data from one system to another, preserves permissions and
ownership, and keeps the backups safe even if the backed-up system
is compromised?
app-backup/backuppc
On Sunday 30 Jun 2013 12:05:05 William Kenworthy wrote:
On 30/06/13 17:58, Stefan G. Weichinger wrote:
Am 30.06.2013 01:42, schrieb Grant:
Can anyone think of an automated method that remotely and securely
backs up data from one system to another, preserves permissions and
ownership, and
How far would I have to open my systems in order for backuppc to
function?
You have to grant root rsync access to the backuppc user on the server.
Isn't that a gaping security hole? I think this amounts to granting
the backup server root read access (and write access if you want to
restore)
On Sun, 30 Jun 2013 13:12:29 -0700, Grant wrote:
You have to grant root rsync access to the backuppc user on the
server.
Isn't that a gaping security hole? I think this amounts to granting
the backup server root read access (and write access if you want to
restore) on each client?
You have to grant root rsync access to the backuppc user on the
server.
Isn't that a gaping security hole? I think this amounts to granting
the backup server root read access (and write access if you want to
restore) on each client?
How can you backup system files without root read
I used reiserfs3 (very good) and now btrfs (so-so, but getting better) -
stay away from anything ext* - they fall apart under the load eventually
losing the lot ... the filesystem gets hammered when its creating tons
of hardlinks. From personal experiance I have a very poor view on ext2
and ext3
On Sun, 30 Jun 2013 14:36:14 -0700, Grant wrote:
Isn't that a gaping security hole? I think this amounts to granting
the backup server root read access (and write access if you want to
restore) on each client?
How can you backup system files without root read access? You are
On 06/29/13 16:42, Grant wrote:
Remote, automated, secure backups is the most difficult and
time-consuming Gentoo project I've undertaken.
Right now I'm pushing data from each of my systems to a backup server
via rdiff-backup. The main problem with this is if a system is
compromised its backup
Remote, automated, secure backups is the most difficult and
time-consuming Gentoo project I've undertaken.
Right now I'm pushing data from each of my systems to a backup server
via rdiff-backup. The main problem with this is if a system is
compromised its backup is also vulnerable. Also, you
29 matches
Mail list logo
