On Friday, August 19, 2011 10:35:10 AM Grant wrote:
I'm setting up an automated rdiff-backup system and I'm stuck
between
pushing the backups to the backup server, and pulling the
backups to
the backup server. If I push, I have to allow read/write access
of my backups via SSH
On Fri 19 August 2011 12:58:10 Grant did opine thusly:
Is the purpose of the Host block in .ssh/config to store the
hostname of the backup server so it doesn't need to be used
directly in the rdiff-backup command?
It forces key-based authentication when connecting to the backup
On Thursday, August 18, 2011 06:01:08 PM Grant wrote:
You can seperate the backups by giving each system a
different
account
where to store the backups.
I'm not sure what you mean. The backups are all stored on the
backup
server.
Each machine to be backed up
On Thursday, August 18, 2011 06:51:32 PM Grant wrote:
I'm setting up an automated rdiff-backup system and I'm stuck between
pushing the backups to the backup server, and pulling the backups to
the backup server. If I push, I have to allow read/write access of my
backups via SSH keys. If
I created the backup users and everything works as long as the backup
users have shells on the backup server and are listed in AllowUsers in
/etc/ssh/sshd_config on the backup server. Did I do something wrong
or should the backup users need shells and to be listed in AllowUsers?
I'm not too
On 08/17/11 13:35, Grant wrote:
Is there a way to
restrict SSH keys to the rsync command?
Yes, via the authorized_keys file. you can add a command directive. this
will always force that command to be executed whenever a connection is made
using this key.
I'm using the command directive
I'm setting up an automated rdiff-backup system and I'm stuck between
pushing the backups to the backup server, and pulling the backups to
the backup server. If I push, I have to allow read/write access of my
backups via SSH keys. If I pull, I have to enable root logins on each
system
We're doing the same thing for our backups. Here's that chunk of our
documentation, if it's helpful.
Thanks Michael. You've found that a shell account is required on the
backup server in order to push backups to it?
Is the purpose of the Host block in .ssh/config to store the hostname
of the
On 08/19/11 14:00, Grant wrote:
We're doing the same thing for our backups. Here's that chunk of our
documentation, if it's helpful.
Thanks Michael. You've found that a shell account is required on the
backup server in order to push backups to it?
Yes, you have to be able to run a command
Is the purpose of the Host block in .ssh/config to store the hostname
of the backup server so it doesn't need to be used directly in the
rdiff-backup command?
It forces key-based authentication when connecting to the backup server.
The default is password-based, which obviously won't work in
On Wednesday, August 17, 2011 10:18:25 AM Grant wrote:
You can seperate the backups by giving each system a different
account
where to store the backups.
I'm not sure what you mean. The backups are all stored on the backup
server.
Each machine to be backed up has a different
On Wednesday, August 17, 2011 11:49:16 PM Alex Schuster wrote:
Grant writes:
Can I reserve 0% for root on my USB hard drive which is only
used for backups and does not contain an OS?
Yes:
mke2fs -m 0 /dev/usb-drive
Although a value 0 helps against fragmentation. And
You can seperate the backups by giving each system a different
account
where to store the backups.
I'm not sure what you mean. The backups are all stored on the backup
server.
Each machine to be backed up has a different account on the backup
server. This will prevent machine
I'm setting up an automated rdiff-backup system and I'm stuck between
pushing the backups to the backup server, and pulling the backups to
the backup server. If I push, I have to allow read/write access of my
backups via SSH keys. If I pull, I have to enable root logins on each
system to be
On Tuesday, August 16, 2011 04:50:40 PM Grant wrote:
You can seperate the backups by giving each system a different account
where to store the backups.
I'm not sure what you mean. The backups are all stored on the backup
server.
Each machine to be backed up has a different account on the
On Tuesday, August 16, 2011 04:50:40 PM Grant wrote:
Is there a way to
restrict SSH keys to the rsync command?
Yes, via the authorized_keys file. you can add a command directive. this
will always force that command to be executed whenever a connection is made
using this key.
See the sshd
On Tuesday, August 16, 2011 04:50:40 PM Grant wrote:
Can I reserve 0% for root on my USB hard drive which is only used for
backups and does not contain an OS?
Yes:
mke2fs -m 0 /dev/usb-drive
--
Joost
Is there a way to
restrict SSH keys to the rsync command?
Yes, via the authorized_keys file. you can add a command directive. this
will always force that command to be executed whenever a connection is made
using this key.
I'm using the command directive with rdiff-backup like
Can I reserve 0% for root on my USB hard drive which is only used for
backups and does not contain an OS?
Yes:
mke2fs -m 0 /dev/usb-drive
Thank you, is it safe to do so on a disk like that? If I run out of
space on the USB hard drive, I'll only need space on the OS disk to
fix it, correct?
You can seperate the backups by giving each system a different account
where to store the backups.
I'm not sure what you mean. The backups are all stored on the backup
server.
Each machine to be backed up has a different account on the backup server.
This will prevent machine A from
Joost Roeleveld writes:
On Tuesday, August 16, 2011 04:50:40 PM Grant wrote:
Can I reserve 0% for root on my USB hard drive which is only used for
backups and does not contain an OS?
Yes:
mke2fs -m 0 /dev/usb-drive
Although a value 0 helps against fragmentation. And when rdiff-backup
Can I reserve 0% for root on my USB hard drive which is only used for
backups and does not contain an OS?
Yes:
mke2fs -m 0 /dev/usb-drive
Although a value 0 helps against fragmentation. And when rdiff-backup has
failed because it ran out of space, regressing to the previous sane state
Grant writes:
Can I reserve 0% for root on my USB hard drive which is only
used for backups and does not contain an OS?
Yes:
mke2fs -m 0 /dev/usb-drive
Although a value 0 helps against fragmentation. And when
rdiff-backup has failed because it ran out of space, regressing
On Wed 17 August 2011 23:49:16 Alex Schuster did opine thusly:
Grant writes:
Can I reserve 0% for root on my USB hard drive which
is only
used for backups and does not contain an OS?
Yes:
mke2fs -m 0 /dev/usb-drive
Although a value 0 helps against fragmentation.
On Wednesday 17 August 2011 23:03:32 Alan McKinnon wrote:
Why that amount? Is it really 5% or is it the number of blocks and 5%
just happens to round that out nicely?
No, it's just somebody licking his finger, sticking it up into the wind to
see which way it's blowing. Think-of-a-number, in
On Monday, August 15, 2011 09:58:00 PM Grant wrote:
I'm setting up an automated rdiff-backup system and I'm stuck between
pushing the backups to the backup server, and pulling the backups to
the backup server. If I push, I have to allow read/write access of my
backups via SSH keys. If I
On 08/15/2011 09:58 PM, Grant wrote:
the backup server. If I push, I have to allow read/write access of my
backups via SSH keys. If I pull, I have to enable root logins on each
system to be backed-up, allow root read access of each system via SSH
+1 push.
But my question is, Why do you
On Tue 16 August 2011 06:39:39 Bill Longman did opine thusly:
On 08/15/2011 09:58 PM, Grant wrote:
the backup server. If I push, I have to allow read/write access
of my backups via SSH keys. If I pull, I have to enable root
logins on each system to be backed-up, allow root read access
I'm setting up an automated rdiff-backup system and I'm stuck between
pushing the backups to the backup server, and pulling the backups to
the backup server. If I push, I have to allow read/write access of my
backups via SSH keys. If I pull, I have to enable root logins on each
system to be
29 matches
Mail list logo