Backup Central

On 5 Aug 2004, steveo < at > 365solutions.co.uk wrote:
Quoting Daniel Pittman
On 4 Aug 2004, Steve wrote:

I must be blind (I am partially sighted ) not to have seen that
right at the top. Note to self, must change the default 'commented
out' text colour from light grey to something a bit more prominent.

Also, it is worth noting that files named
'/etc/backuppc/<host>.pl' work
for this, and they are what I prefer to use.


Okay, I'm the blind one. I never saw that nice little tidbit anywhere. Is
this officially supported? Also, I don't have /etc/backuppc. Is it
__TOPDIR__/<host>.pl, __TOPDIR__/conf/<host>.pl, or something?

Mike



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/

Daniel Pittman writes:

On 5 Aug 2004, Michael Pellegrino wrote:
On 5 Aug 2004, steveo < at > 365solutions.co.uk wrote:
Quoting Daniel Pittman
On 4 Aug 2004, Steve wrote:

I must be blind (I am partially sighted ) not to have seen that
right at the top. Note to self, must change the default 'commented
out' text colour from light grey to something a bit more prominent.

Also, it is worth noting that files named
'/etc/backuppc/<host>.pl' work
for this, and they are what I prefer to use.

Okay, I'm the blind one. I never saw that nice little tidbit anywhere. Is
this officially supported? Also, I don't have /etc/backuppc. Is it
__TOPDIR__/<host>.pl, __TOPDIR__/conf/<host>.pl, or something?

...hmm. This could be a Debian-specific patch, then, though I thought I
saw a reference to it in the documentation somewhere.

A quick check fails to turn up the location, though - sorry.

It's an undocumented feature. BackupPC merges the following three
config files in order:

__TOPDIR__/conf/config.pl
__TOPDIR__/conf/HOST.pl
__TOPDIR__/pc/HOST/config.pl

Settings in later files override the earlier files. So the per-PC
host file can go either in __TOPDIR__/conf/HOST.pl (undocumented)
or __TOPDIR__/pc/HOST/config.pl (offical documented location).

Daniel, I assume you have a symlink from __TOPDIR__/conf to /etc/backuppc.

That said, now that I am implementing a CGI config editor, it is
difficult to have the per-PC config file in two places. Where do
you write the config file? So the config editor might not support
the undocumented __TOPDIR__/conf/HOST.pl location.

Craig


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/

On 5 Aug 2004, Craig Barratt wrote:
Daniel Pittman writes:
On 5 Aug 2004, Michael Pellegrino wrote:
On 5 Aug 2004, steveo < at > 365solutions.co.uk wrote:
Quoting Daniel Pittman
On 4 Aug 2004, Steve wrote:

[...]

Also, it is worth noting that files named
'/etc/backuppc/<host>.pl' work
for this, and they are what I prefer to use.

[...]

It's an undocumented feature. BackupPC merges the following three
config files in order:

__TOPDIR__/conf/config.pl
__TOPDIR__/conf/HOST.pl
__TOPDIR__/pc/HOST/config.pl

Settings in later files override the earlier files. So the per-PC
host file can go either in __TOPDIR__/conf/HOST.pl (undocumented)
or __TOPDIR__/pc/HOST/config.pl (offical documented location).

Daniel, I assume you have a symlink from __TOPDIR__/conf to
/etc/backuppc.

Checking says no, I don't. Presumable the Debian packager either
configures or patches BackupPC to conform to Debian policy about
configuration files...

That said, now that I am implementing a CGI config editor, it is
difficult to have the per-PC config file in two places. Where do
you write the config file? So the config editor might not support
the undocumented __TOPDIR__/conf/HOST.pl location.

...which is that all configuration must live under /etc somewhere.

I suspect I found the undocumented feature, initially, by just putting
the config file there and having it work.

Personally, I agree with the Debian decision to house all configuration
under /etc, and would encourage you to use that as the default location
for all configuration -- including the config.pl file -- by default.

Regards,
Daniel
--
What is art but a way of seeing?
-- Thomas Berger

On 08/05 05:29 , Daniel Pittman wrote:
Personally, I agree with the Debian decision to house all configuration
under /etc, and would encourage you to use that as the default location
for all configuration -- including the config.pl file -- by default.

it's not so much a Debian-specific thing; but a Linux Filesystem Heirarchy
Standard thing. It makes a world of sense to me, as an admin; because this
way I can grab a tarball of just /etc, and know that I've got the config
files for everything on the system.

as for a CGI configuration editor; how about making it edit/generate
per-host configuration files by default? this way you can more easily
delegate administrative authority over those machines to other users, while
leaving the main config file untouched.

This also makes upgrades easier; because very little will change in the main
config file, so you won't have to change as much in the new config file. i

In fact; it might be nice to have the config.pl file; but also a
local-config.pl file, which you can use to override the system-wide settings
in config.pl. By doing that, the distribution's package tool can just
clobber the old config.pl with a new one; but your local customizations will
be untouched. painless and unattended upgrades are always a bonus.

--
Carl Soderstrom
Systems Administrator
Real-Time Enterprises
www.real-time.com


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/

Carl Wilhelm Soderstrom wrote:
On 08/05 05:29 , Daniel Pittman wrote:
this way you can more easily
delegate administrative authority over those machines to other users, while
leaving the main config file untouched.
... a simple 5 minute hack could be to have the backup precommand
rsync a user maintained list of directories to backup (say 1 dir per line)
off their PC and then simply have a script do some search and replaces (being
sure to sanity check for nasty users trying to escape out commands , format
properly and then mod the host specific config file...


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Currie | | | |
| .|||. .|||. | Email:
Cisco Systems | ..||||||:...||||||:.. | kcurrie
Austin, Texas |---------------------------| (at) cisco.com
~~~~~~~~GPG/PGP public key: https://undertow.2y.net/kcurrie.pub ~~~~~~~~~




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/

Carl Wilhelm Soderstrom writes:

On 08/05 05:29 , Daniel Pittman wrote:
Personally, I agree with the Debian decision to house all configuration
under /etc, and would encourage you to use that as the default location
for all configuration -- including the config.pl file -- by default.

it's not so much a Debian-specific thing; but a Linux Filesystem Heirarchy
Standard thing. It makes a world of sense to me, as an admin; because this
way I can grab a tarball of just /etc, and know that I've got the config
files for everything on the system.

as for a CGI configuration editor; how about making it edit/generate
per-host configuration files by default? this way you can more easily
delegate administrative authority over those machines to other users, while
leaving the main config file untouched.

Sure, the CGI editor will allow both the main config file and
the per-PC config settings to be edited. Regular users will
only be able to edit a (configurable) subset of their PC's
settings. I was just making an observation about which
destination location to use for writing the per-PC config
file.

In fact; it might be nice to have the config.pl file; but also a
local-config.pl file, which you can use to override the system-wide settings
in config.pl. By doing that, the distribution's package tool can just
clobber the old config.pl with a new one; but your local customizations will
be untouched. painless and unattended upgrades are always a bonus.

I've thought about having several hierarchies of config files,
eg: per-PC, PC category (eg: linux or PC), and main. Currently
there are just two: per-PC and main. But this seems a little
complex and potentially confusing.

I'm not sure a local config file makes sense. Currently the upgrade
scripts are smart about merging new config settings into the existing
main config file without touching the existing settings.

Craig


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/

On Thu, 2004-08-05 at 09:46, Carl Wilhelm Soderstrom wrote:
On 08/05 05:29 , Daniel Pittman wrote:
Personally, I agree with the Debian decision to house all configuration
under /etc, and would encourage you to use that as the default location
for all configuration -- including the config.pl file -- by default.

it's not so much a Debian-specific thing; but a Linux Filesystem Heirarchy
Standard thing. It makes a world of sense to me, as an admin; because this
way I can grab a tarball of just /etc, and know that I've got the config
files for everything on the system.

This really should be a package-maintainer thing... That is, anyone
building distribution specific installation packages should move
the locations to follow the distribution standards and in general
it is best if that is *not* the default location where it would
land if you do a local install from the author's version.

Personally, I want to put the entire installation under /opt/backuppc
which is a mount point so I can move the drive to another machine and
keep the data consistent with the configuration. I am testing a scheme
to raid-mirror to firewire drives for offsite storage and wouldn't want
to have to worry about separately keeping configs to access the copy.

By the way - the mirroring looks promising - a 250 gig partition
completed a sync in about 7 hours while the box was running normally
where I previously couldn't complete a normal copy of a full 120 gig
partition in a couple of days with everything else stopped.

----
Les Mikesell
les < at > futuresource.com




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/

I would be very interested in how to setup the mirror and then break it so
you can move the drive offsite. Do you think this could be done with USB2.0
drives as well?

Do you think it would be possible to mirror RAID5 or RAID0 volumes in this
way as well? What I mean by that is setup a RAID51 (I think that is what
mirrored RAID5 volumes are called) to create a copy of a RAID5 and then
break it and move the second RAID5 offsite?

I could be out to lunch but it "sounds" doable

Leon



-----Original Message-----
From: Les Mikesell [mailto:les < at > futuresource.com]
Sent: Friday, August 06, 2004 9:58 AM
To: Carl Wilhelm Soderstrom
Cc: backuppc-users < at > lists.sourceforge.net
Subject: Re: [BackupPC-users] Re: Different backup modules on each client

On Thu, 2004-08-05 at 09:46, Carl Wilhelm Soderstrom wrote:
On 08/05 05:29 , Daniel Pittman wrote:
Personally, I agree with the Debian decision to house all
configuration under /etc, and would encourage you to use that as the
default location for all configuration -- including the config.pl file
-- by default.

it's not so much a Debian-specific thing; but a Linux Filesystem
Heirarchy Standard thing. It makes a world of sense to me, as an
admin; because this way I can grab a tarball of just /etc, and know
that I've got the config files for everything on the system.

This really should be a package-maintainer thing... That is, anyone
building distribution specific installation packages should move the
locations to follow the distribution standards and in general it is best if
that is *not* the default location where it would land if you do a local
install from the author's version.

Personally, I want to put the entire installation under /opt/backuppc which
is a mount point so I can move the drive to another machine and keep the
data consistent with the configuration. I am testing a scheme to
raid-mirror to firewire drives for offsite storage and wouldn't want to have
to worry about separately keeping configs to access the copy.

By the way - the mirroring looks promising - a 250 gig partition completed a
sync in about 7 hours while the box was running normally where I previously
couldn't complete a normal copy of a full 120 gig partition in a couple of
days with everything else stopped.

----
Les Mikesell
les < at > futuresource.com




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one
more big change to announce. We are now OSTG- Open Source Technology Group.
Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/

On 08/06 08:58 , Les Mikesell wrote:
it's not so much a Debian-specific thing; but a Linux Filesystem Heirarchy
Standard thing. It makes a world of sense to me, as an admin; because this
way I can grab a tarball of just /etc, and know that I've got the config
files for everything on the system.

This really should be a package-maintainer thing... That is, anyone
building distribution specific installation packages should move
the locations to follow the distribution standards and in general
it is best if that is *not* the default location where it would
land if you do a local install from the author's version.

I think that's part of the FHS as well (or at least it's part of good
practices). Applications compiled locally should install to
/usr/local/<appname> by default, where they won't interfere with a
package-managed version, and they're easily moveable/manageable without a
package manager.

If your own heirarchy prefers something other than /usr/local; then that
should be configurable at install time as well (as backuppc does with the
interactive installer).

--
Carl Soderstrom
Systems Administrator
Real-Time Enterprises
www.real-time.com


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/

On 08/05 11:06 , Craig Barratt wrote:
Carl Wilhelm Soderstrom writes:
In fact; it might be nice to have the config.pl file; but also a
local-config.pl file, which you can use to override the system-wide settings
in config.pl. By doing that, the distribution's package tool can just
clobber the old config.pl with a new one; but your local customizations will
be untouched. painless and unattended upgrades are always a bonus.

I've thought about having several hierarchies of config files,
eg: per-PC, PC category (eg: linux or PC), and main. Currently
there are just two: per-PC and main. But this seems a little
complex and potentially confusing.

'main' I presume means editing config.pl directly?

I'm not sure a local config file makes sense. Currently the upgrade
scripts are smart about merging new config settings into the existing
main config file without touching the existing settings.

there's an upgrade script?
I just let the Debian package manager deal with upgrading files; and it
doesn't run any upgrade script, so I never knew there was one. I just copied
the settings over to the new file by hand. (pretty common way to do things
for a lot of applications.)

I'm proposing a method whereby you don't need an upgrade script (except for
things like the blackout format change between 2.0.2 and 2.1.0).
For instance, Spamassassin is set up such that you should put your own
system-wide configuration changes in a 'local' config file
(/etc/mail/spamassassin/local.cf, in our setup), which overrides
the settings of the base config file
(/etc/mail/spamassassin/sa-mimedefang.cf). this local config file doesn't get
clobbered by the package manager; so when a new base config file gets
dropped into place, all your own settings still override them.

this means you don't need as complicated an upgrade script; and it makes the
local changes much more comprehensible and easier to transfer to other
systems. (just copy the few lines of your local configuration file to the
same file on another system; no need to search through a big file, finding
the appropriate places to edit, and then making your changes one at a time).

works the same way as the per-host config files do; but on the whole
config.pl file, and takes effect before the per-hosts config files (so that
they can override its settings just like they do for config.pl).

--
Carl Soderstrom
Systems Administrator
Real-Time Enterprises
www.real-time.com


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/

On Fri, 2004-08-06 at 09:50, Leon Letto wrote:
I would be very interested in how to setup the mirror and then break it so
you can move the drive offsite. Do you think this could be done with USB2.0
drives as well?

The external cases I'm using have both USB and firewire. USB seems to
autodetect hotplugging on Fedora where firewire takes manual
intervention on core1 and is broken on core2. I'll experiment a bit
to see if there is much difference in speed or CPU efficiency. Software
wise they look the same once detected.

Do you think it would be possible to mirror RAID5 or RAID0 volumes in this
way as well? What I mean by that is setup a RAID51 (I think that is what
mirrored RAID5 volumes are called) to create a copy of a RAID5 and then
break it and move the second RAID5 offsite?

I don't think the linux md driver cares what kind of lower level
partition it is mirroring. It can even work across a network if
you use the nbd or enbd devices but USB/firewire/SATA seems
easier and cheaper since you can get 250/300 gigs in a single
drive now and put them in external cases.

The only part that might be a problem is that you have to start from
scratch or dig up some information I couldn't find about mirroring
an existing filesystem. Creating the raid makes a new superblock
and changes the size of the previous partition. You can
mdadm --create /dev/md0 --level=mirror \
--raid-devices=2 /dev/hdc1 missing
(assuming no existing md devices and an internal IDE on hdc1 as one
part). This builds a 'broken' mirror which starts working anyway.
Then make the filesystem on /dev/md0, mount it, and start using. When
you want to sync the mirror:
mdmadm --add /dev/md0 /dev/sda1
(assuming the matching drive has been detected and has the matching
partition already added via fdisk).
Then 'cat /proc/mdstat' will show the sync status and 7 or 8 hours
later it should be complete. You don't have to stop anything to
add a drive but if you want it to be 'clean' for use, the partition
should be unmounted before breaking the raid. Then:
mdadm /dev/md0 --fail /dev/sda1
mdadm /dev/md0 --remove /dev/sda1
and you can unplug it and remount the broken partition. So far I'm
just trying to catch back up with the first external mirror, but if
it works out I'll have 2 or 3 in an offsite rotation and swap the
external half of the mirror at least once a week. It should be
possible to wrap the commands to swap in a couple of scripts. The
only thing that might be an issue is that hotplug drives are added
as the next-available scsi device name. If you happen to add internal
scsi drives or plug in multiple external drives the partition name
might change the next time it is connected.

---
Les Mikesell
les < at > futuresource.com




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/

This is a very nice idea!

If anyone is going to use dirty software raid1 arrays for mirroring, check
out the values in /proc/sys/dev/raid. You can increase the speed_limit_max
value (defaults to 10MB/s) so that the mirror drive syncs to the real
backuppc drive faster.

-Ross

On Fri, 6 Aug 2004, Les Mikesell wrote:

On Fri, 2004-08-06 at 09:50, Leon Letto wrote:
I would be very interested in how to setup the mirror and then break it so
you can move the drive offsite. Do you think this could be done with USB2.0
drives as well?

The external cases I'm using have both USB and firewire. USB seems to
autodetect hotplugging on Fedora where firewire takes manual
intervention on core1 and is broken on core2. I'll experiment a bit
to see if there is much difference in speed or CPU efficiency. Software
wise they look the same once detected.

Do you think it would be possible to mirror RAID5 or RAID0 volumes in this
way as well? What I mean by that is setup a RAID51 (I think that is what
mirrored RAID5 volumes are called) to create a copy of a RAID5 and then
break it and move the second RAID5 offsite?

I don't think the linux md driver cares what kind of lower level
partition it is mirroring. It can even work across a network if
you use the nbd or enbd devices but USB/firewire/SATA seems
easier and cheaper since you can get 250/300 gigs in a single
drive now and put them in external cases.

The only part that might be a problem is that you have to start from
scratch or dig up some information I couldn't find about mirroring
an existing filesystem. Creating the raid makes a new superblock
and changes the size of the previous partition. You can
mdadm --create /dev/md0 --level=mirror \
--raid-devices=2 /dev/hdc1 missing
(assuming no existing md devices and an internal IDE on hdc1 as one
part). This builds a 'broken' mirror which starts working anyway.
Then make the filesystem on /dev/md0, mount it, and start using. When
you want to sync the mirror:
mdmadm --add /dev/md0 /dev/sda1
(assuming the matching drive has been detected and has the matching
partition already added via fdisk).
Then 'cat /proc/mdstat' will show the sync status and 7 or 8 hours
later it should be complete. You don't have to stop anything to
add a drive but if you want it to be 'clean' for use, the partition
should be unmounted before breaking the raid. Then:
mdadm /dev/md0 --fail /dev/sda1
mdadm /dev/md0 --remove /dev/sda1
and you can unplug it and remount the broken partition. So far I'm
just trying to catch back up with the first external mirror, but if
it works out I'll have 2 or 3 in an offsite rotation and swap the
external half of the mirror at least once a week. It should be
possible to wrap the commands to swap in a couple of scripts. The
only thing that might be an issue is that hotplug drives are added
as the next-available scsi device name. If you happen to add internal
scsi drives or plug in multiple external drives the partition name
might change the next time it is connected.

---
Les Mikesell
les < at > futuresource.com




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/

On Fri, 2004-08-06 at 13:15, Ross Skaliotis wrote:
This is a very nice idea!

If anyone is going to use dirty software raid1 arrays for mirroring, check
out the values in /proc/sys/dev/raid. You can increase the speed_limit_max
value (defaults to 10MB/s) so that the mirror drive syncs to the real
backuppc drive faster.

Unless you need to swap mirrors more than once or twice a day the
sync speed really doesn't matter. The nice thing about them is
that everything keeps working regardless of the state of the
mirror. If you don't mind letting the filesystem journal or
an fsck fix things up in the unlikely event that you have to
use the offsite copy you could even fail/remove it without
stopping anything or unmounting the partition and running
applications wouldn't know the difference.

---
Les Mikesell
les < at > futuresource.com



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/