Re: Backup Command

Re: Backup Command

[CACook]

Well thanks to some help from you guys I seem to have my backup server almost fully running and functional with rsync.  Amazing functions, this snapshotting and rsync.

I still don't know why I cannot remove snapshots though. (Debian Testing with 2.6.32-28)

And I don't know how to reach out from the backup server to the HTPC and stop MythTV there, so I can export the Mysql database safely, from a cron job on the backup server.  Suggestions?

Re: Backup Command

[Goffredo Baroncelli]

On 01/21/2011 08:07 PM, CACook@quantum-sci.com wrote:
> 
> Well thanks to some help from you guys I seem to have my backup server almost fully running and functional with rsync.  Amazing functions, this snapshotting and rsync.
> 
> I still don't know why I cannot remove snapshots though. (Debian Testing with 2.6.32-28)
I am not sure if the kernel 2.32 supports snapshot removal...


> 
> And I don't know how to reach out from the backup server to the HTPC and stop MythTV there, so I can export the Mysql database safely, from a cron job on the backup server.  Suggestions?
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> .
> 

Re: Backup Command

[Niklas Schnelle]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

Kernel 2.6.32.x is to old for snapshot deletion, you will have to use
something more recent
On Fri, 2011-01-21 at 11:07 -0800, CACook@quantum-sci.com wrote:
> Well thanks to some help from you guys I seem to have my backup server almost fully running and functional with rsync.  Amazing functions, this snapshotting and rsync.
> 
> I still don't know why I cannot remove snapshots though. (Debian Testing with 2.6.32-28)
> 
> And I don't know how to reach out from the backup server to the HTPC and stop MythTV there, so I can export the Mysql database safely, from a cron job on the backup server.  Suggestions?
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Backup Command

[Freddie Cash]

On Fri, Jan 21, 2011 at 11:07 AM,  <CACook@quantum-sci.com> wrote:
>
> Well thanks to some help from you guys I seem to have my backup serve=
r almost fully running and functional with rsync. =C2=A0Amazing functio=
ns, this snapshotting and rsync.
>
> I still don't know why I cannot remove snapshots though. (Debian Test=
ing with 2.6.32-28)
>
> And I don't know how to reach out from the backup server to the HTPC =
and stop MythTV there, so I can export the Mysql database safely, from =
a cron job on the backup server. =C2=A0Suggestions?

Simplified, but workable:

#!/bin/sh

ssh someuser@mythtv.pc "/path/to/some/script stop"

/path/to/your/rsync/script

ssh someuser@mythtv.pc "/path/to/some/script start"

The above script would be your backup wrapper script, that gets called =
by cron.

On the HTPC, "/path/to/some/script" would be a script that takes 2
arguments (stop|start).

The stop argument would stop mythtv using the init script for it.
Then would do whatever you need to do to the database (stop it, dump
it, whatever).

The start argument would do the reverse, starting the database and Myth=
TV.

And, "/path/to/your/rsync/script" would call your actual backups
script that runs rsync.

--=20
=46reddie Cash
fjwcash@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Backup Command

[CACook]

On Fri 21 January 2011 11:44:24 Freddie Cash wrote:
> #!/bin/sh
>=20
> ssh someuser@mythtv.pc "/path/to/some/script stop"
>=20
> /path/to/your/rsync/script
>=20
> ssh someuser@mythtv.pc "/path/to/some/script start"

Ho-lee crap, this is fantastic.  Everything seems to work.  I find thou=
gh that if I stop myth -and- mysql, I cannot export the database, so I =
only stop Myth.  It's the only thing using the database anyway, in my c=
ase.

Well it's been 12 hours and I'm still doing my first HTPC data transfer=
, so not all commands are tested (untested=3D=3D#), but I am confident =
they will work.  I'm donating my (weekly) cron script here in case it h=
elps someone. (below)

I have four systems:
hex - work laptop
droog - HTPC with a 4TB btrfs raid0 array on /home and 500GB raptor on =
/
slepnir - backup server in a cube case out in the garage (in case of th=
eft or fire) with a SuperMicro 5 disk hot-swap cage, 6TB so far. (WD Gr=
een 2TB now $80 with rebate!)
phone - Android Nexus One with 16GB SD

The backup server has SSH credentials on the other systems, but only th=
e work laptop can ssh to it (limited by Shorewall).  The backup server =
will also handle security cameras and will presumably dnat a port to th=
e HTPC, which will serve it to the WAN on SSH (reverse tunnel) so I can=
 get motion notifications and video on my phone. (ZoneMinder)  The HTPC=
 is the only system allowed to present anything to the WAN as it has no=
thing sensitive, and -that- will be on a subnet.  Maybe I can limit it =
to my phone's IP.

I do have a (disused) WindowsXP partition, but unsure how to back that =
up.  Maybe ssh with a dd command.

Thanks for the help all.

backups
-----------------------------------------------------------------------=
----------------------------------------------------------
#!/bin/sh
#
# cron.weekly/backups -- schedules periodic backups of darkmatter syste=
ms
#
# Copyleft =C2=A9 Carl Cook
#
#--archive is  equivalent  to  'recursive links perms times group owner=
 DevicesSpecials'

/bin/mount /media/backups

#------------------------------------------------------
# Hex

#/sbin/btrfs subvolume snapshot /media/backups/hex-home/ /media/backups=
/hex-home-snap-$(date +"%Y-%m-%d")
/usr/bin/rsync --archive --checksum --compress --hard-links --delete-du=
ring --delete-excluded --inplace --numeric-ids --log-file=3D/media/back=
ups/hex-home-$(date +"%Y-%m-%d").log -e ssh root@hex:///home/ /media/ba=
ckups/hex-home/

#/sbin/btrfs subvolume snapshot /media/backups/hex-root/ /media/backups=
/hex-root-snap-$(date +"%Y-%m-%d")
#/usr/bin/rsync --archive --checksum --compress --hard-links --delete-d=
uring --delete-excluded --inplace --numeric-ids --exclude-from=3D/media=
/backups/exclude-root --log-file=3D/media/backups/hex-root-$(date +"%Y-=
%m-%d").log -e ssh root@hex:/// /media/backups/hex-root/

#------------------------------------------------------
# Droog

#/sbin/btrfs subvolume snapshot /media/backups/droog-home/ /media/backu=
ps/droog-home-snap-$(date +"%Y-%m-%d")
/usr/bin/rsync --archive --checksum --compress --hard-links --delete-du=
ring --delete-excluded --inplace --numeric-ids --log-file=3D/media/back=
ups/droog-home-$(date +"%Y-%m-%d").log -e ssh root@droog:///home/ /medi=
a/backups/droog-home/

/usr/bin/ssh root@droog "/etc/init.d/mythtv-backend stop"
/usr/bin/ssh root@droog "/usr/bin/mysqldump -u mythtv -pmythtv mythconv=
erg -c > /home/bill/.mythtv/mysql_backup-$(date +"%Y-%m-%d").sql"
/usr/bin/ssh root@droog "/etc/init.d/mythtv-backend start"
/sbin/btrfs subvolume snapshot /media/backups/droog-root/ /media/backup=
s/droog-root-snap-$(date +"%Y-%m-%d")
/usr/bin/rsync --archive --checksum --compress --hard-links --delete-du=
ring --delete-excluded --inplace --numeric-ids --exclude-from=3D/media/=
backups/exclude-root --log-file=3D/media/backups/droog-root-$(date +"%Y=
-%m-%d").log -e ssh root@droog:/// /media/backups/droog-root/

#------------------------------------------------------
# Phone

#/sbin/btrfs subvolume snapshot /media/backups/phone-sd/ /media/backups=
/phone-sd-snap-$(date +"%Y-%m-%d")
#/usr/bin/rsync --archive --checksum --compress --hard-links --delete-d=
uring --delete-excluded --inplace --numeric-ids --log-file=3D/media/bac=
kups/phone-sd-$(date +"%Y-%m-%d").log -e ssh root@hex:///media/disk-1/ =
/media/backups/phone-sd/

#------------------------------------------------------

/bin/umount /media/backups

-----------------------------------------------------------------------=
----------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Backup Command

[Carl Cook]

Here is my proposed cron:

btrfs subvolume snapshot hex:///home /media/backups/snapshots/hex-{DATE}

rsync --archive --hard-links --delete-during --delete-excluded --inplace --numeric-ids -e ssh --exclude-from=/media/backups/exclude-hex hex:///home /media/backups/hex

btrfs subvolume snapshot droog:///home /media/backups/snapshots/droog-{DATE}

rsync --archive --hard-links --delete-during --delete-excluded --inplace --numeric-ids -e ssh --exclude-from=/media/backups/exclude-droog droog:///home /media/backups/droog

Comments?  Criticisms?

Re: Backup Command

[Hubert Kario]

On Monday 10 of January 2011 14:25:32 Carl Cook wrote:
> Here is my proposed cron:
>=20
> btrfs subvolume snapshot hex:///home /media/backups/snapshots/hex-{DA=
TE}
>=20
> rsync --archive --hard-links --delete-during --delete-excluded --inpl=
ace
> --numeric-ids -e ssh --exclude-from=3D/media/backups/exclude-hex hex:=
///home
> /media/backups/hex
>=20
> btrfs subvolume snapshot droog:///home
> /media/backups/snapshots/droog-{DATE}
>=20
> rsync --archive --hard-links --delete-during --delete-excluded --inpl=
ace
> --numeric-ids -e ssh --exclude-from=3D/media/backups/exclude-droog
> droog:///home /media/backups/droog
>=20
> Comments?  Criticisms?

This will make the dates associated with snapshots offset by how often =
cron is=20
run.

In other words, if you run above script daily you will have data from=20
2011.01.01 in the hex-2011.01.02 directory.

I do save the current date, do a LVM snapshot on the source, rsync --in=
place=20
data over and do a local snapshot naming the folder using the saved dat=
e. This=20
way the date in the name of backup directory is exact to about a second=
=2E
--=20
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawer=F3w 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Backup Command

[Ivan Labáth]

On 01/10/11 14:36, Hubert Kario wrote:
> On Monday 10 of January 2011 14:25:32 Carl Cook wrote:
>> Here is my proposed cron:
>>
>> btrfs subvolume snapshot hex:///home /media/backups/snapshots/hex-{DATE}
>>
>> rsync --archive --hard-links --delete-during --delete-excluded --inplace
>> --numeric-ids -e ssh --exclude-from=/media/backups/exclude-hex hex:///home
>> /media/backups/hex
>>
>> btrfs subvolume snapshot droog:///home
>> /media/backups/snapshots/droog-{DATE}
>>
>> rsync --archive --hard-links --delete-during --delete-excluded --inplace
>> --numeric-ids -e ssh --exclude-from=/media/backups/exclude-droog
>> droog:///home /media/backups/droog
>>
>> Comments?  Criticisms?
> 
> This will make the dates associated with snapshots offset by how often cron is 
> run.
> 
> In other words, if you run above script daily you will have data from 
> 2011.01.01 in the hex-2011.01.02 directory.
> 
> I do save the current date, do a LVM snapshot on the source, rsync --inplace 
> data over and do a local snapshot naming the folder using the saved date. This 
> way the date in the name of backup directory is exact to about a second.

If you are mounting a LVM snapshot of an already mounted filesystem,
would you be willing verify that it is really a snapshot that is mounted?

e.g. touch /mnt/live/its_alive && ls /mnt/snapshot/

I am nearly willing to bet it is not a snapshot.

--
ivan

Re: Backup Command

[Hubert Kario]

On Tuesday, January 11, 2011 14:54:38 Ivan Lab=C3=A1th wrote:
> On 01/10/11 14:36, Hubert Kario wrote:
> > On Monday 10 of January 2011 14:25:32 Carl Cook wrote:
> >> Here is my proposed cron:
> >>=20
> >> btrfs subvolume snapshot hex:///home /media/backups/snapshots/hex-=
{DATE}
> >>=20
> >> rsync --archive --hard-links --delete-during --delete-excluded --i=
nplace
> >> --numeric-ids -e ssh --exclude-from=3D/media/backups/exclude-hex
> >> hex:///home /media/backups/hex
> >>=20
> >> btrfs subvolume snapshot droog:///home
> >> /media/backups/snapshots/droog-{DATE}
> >>=20
> >> rsync --archive --hard-links --delete-during --delete-excluded --i=
nplace
> >> --numeric-ids -e ssh --exclude-from=3D/media/backups/exclude-droog
> >> droog:///home /media/backups/droog
> >>=20
> >> Comments?  Criticisms?
> >=20
> > This will make the dates associated with snapshots offset by how of=
ten
> > cron is run.
> >=20
> > In other words, if you run above script daily you will have data fr=
om
> > 2011.01.01 in the hex-2011.01.02 directory.
> >=20
> > I do save the current date, do a LVM snapshot on the source, rsync
> > --inplace data over and do a local snapshot naming the folder using=
 the
> > saved date. This way the date in the name of backup directory is ex=
act
> > to about a second.
>=20
> If you are mounting a LVM snapshot of an already mounted filesystem,
> would you be willing verify that it is really a snapshot that is moun=
ted?
>=20
> e.g. touch /mnt/live/its_alive && ls /mnt/snapshot/
>=20
> I am nearly willing to bet it is not a snapshot.

well, by "LVM snapshot on the source" I meant:
1. do lvcreate --snapshot
2. mount newly created volume=20
3. use the new directory as the base for rsync
4. arrange umount and destruction of the snapshot after rsync completes=
 (no=20
matter if it was successful)

and this will in fact not make the "its_alive" visible in /mnt/snapshot

You have to use this procedure if you use LVM snapshots for backup no m=
atter=20
to where do you copy data. That's why I shortened it to a single point =
-- it's=20
not the part that is important from btrfs perspective.

Regards.
--=20
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawer=C3=B3w 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Backup Command

[Ivan Labáth]

On 01/11/11 15:19, Hubert Kario wrote:
> On Tuesday, January 11, 2011 14:54:38 Ivan Lab=C3=A1th wrote:
>> On 01/10/11 14:36, Hubert Kario wrote:
>>> On Monday 10 of January 2011 14:25:32 Carl Cook wrote:
>>>> Here is my proposed cron:
>>>>
>>>> btrfs subvolume snapshot hex:///home /media/backups/snapshots/hex-=
{DATE}
>>>>
>>>> rsync --archive --hard-links --delete-during --delete-excluded --i=
nplace
>>>> --numeric-ids -e ssh --exclude-from=3D/media/backups/exclude-hex
>>>> hex:///home /media/backups/hex
>>>>
>>>> btrfs subvolume snapshot droog:///home
>>>> /media/backups/snapshots/droog-{DATE}
>>>>
>>>> rsync --archive --hard-links --delete-during --delete-excluded --i=
nplace
>>>> --numeric-ids -e ssh --exclude-from=3D/media/backups/exclude-droog
>>>> droog:///home /media/backups/droog
>>>>
>>>> Comments?  Criticisms?
>>>
>>> This will make the dates associated with snapshots offset by how of=
ten
>>> cron is run.
>>>
>>> In other words, if you run above script daily you will have data fr=
om
>>> 2011.01.01 in the hex-2011.01.02 directory.
>>>
>>> I do save the current date, do a LVM snapshot on the source, rsync
>>> --inplace data over and do a local snapshot naming the folder using=
 the
>>> saved date. This way the date in the name of backup directory is ex=
act
>>> to about a second.
>>
>> If you are mounting a LVM snapshot of an already mounted filesystem,
>> would you be willing verify that it is really a snapshot that is mou=
nted?
>>
>> e.g. touch /mnt/live/its_alive && ls /mnt/snapshot/
>>
>> I am nearly willing to bet it is not a snapshot.
>=20
> well, by "LVM snapshot on the source" I meant:
> 1. do lvcreate --snapshot
> 2. mount newly created volume=20
> 3. use the new directory as the base for rsync
> 4. arrange umount and destruction of the snapshot after rsync complet=
es (no=20
> matter if it was successful)
>=20
> and this will in fact not make the "its_alive" visible in /mnt/snapsh=
ot
>=20
> You have to use this procedure if you use LVM snapshots for backup no=
 matter=20
> to where do you copy data. That's why I shortened it to a single poin=
t -- it's=20
> not the part that is important from btrfs perspective.
>=20
> Regards.

The point I was trying to make is: it does not work with btrfs.
Try the above with a btrfs and you will be surprised.
If the source volume uses another filesystem, it should work properly.

regards,
ivan
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Backup Command

[Hubert Kario]

On Tuesday, January 11, 2011 15:33:38 Ivan Lab=C3=A1th wrote:
> On 01/11/11 15:19, Hubert Kario wrote:
> > On Tuesday, January 11, 2011 14:54:38 Ivan Lab=C3=A1th wrote:
> >> On 01/10/11 14:36, Hubert Kario wrote:
> >>> On Monday 10 of January 2011 14:25:32 Carl Cook wrote:
> >>>> Here is my proposed cron:
> >>>>=20
> >>>> btrfs subvolume snapshot hex:///home
> >>>> /media/backups/snapshots/hex-{DATE}
> >>>>=20
> >>>> rsync --archive --hard-links --delete-during --delete-excluded
> >>>> --inplace --numeric-ids -e ssh
> >>>> --exclude-from=3D/media/backups/exclude-hex hex:///home
> >>>> /media/backups/hex
> >>>>=20
> >>>> btrfs subvolume snapshot droog:///home
> >>>> /media/backups/snapshots/droog-{DATE}
> >>>>=20
> >>>> rsync --archive --hard-links --delete-during --delete-excluded
> >>>> --inplace --numeric-ids -e ssh
> >>>> --exclude-from=3D/media/backups/exclude-droog droog:///home
> >>>> /media/backups/droog
> >>>>=20
> >>>> Comments?  Criticisms?
> >>>=20
> >>> This will make the dates associated with snapshots offset by how =
often
> >>> cron is run.
> >>>=20
> >>> In other words, if you run above script daily you will have data =
from
> >>> 2011.01.01 in the hex-2011.01.02 directory.
> >>>=20
> >>> I do save the current date, do a LVM snapshot on the source, rsyn=
c
> >>> --inplace data over and do a local snapshot naming the folder usi=
ng the
> >>> saved date. This way the date in the name of backup directory is =
exact
> >>> to about a second.
> >>=20
> >> If you are mounting a LVM snapshot of an already mounted filesyste=
m,
> >> would you be willing verify that it is really a snapshot that is
> >> mounted?
> >>=20
> >> e.g. touch /mnt/live/its_alive && ls /mnt/snapshot/
> >>=20
> >> I am nearly willing to bet it is not a snapshot.
> >=20
> > well, by "LVM snapshot on the source" I meant:
> > 1. do lvcreate --snapshot
> > 2. mount newly created volume
> > 3. use the new directory as the base for rsync
> > 4. arrange umount and destruction of the snapshot after rsync compl=
etes
> > (no matter if it was successful)
> >=20
> > and this will in fact not make the "its_alive" visible in /mnt/snap=
shot
> >=20
> > You have to use this procedure if you use LVM snapshots for backup =
no
> > matter to where do you copy data. That's why I shortened it to a si=
ngle
> > point -- it's not the part that is important from btrfs perspective=
=2E
> >=20
> > Regards.
>=20
> The point I was trying to make is: it does not work with btrfs.
> Try the above with a btrfs and you will be surprised.
> If the source volume uses another filesystem, it should work properly=
=2E
>=20
> regards,
> ivan

Yes, you are right, but I don't see a point in using LVM snapshots with=
 btrfs,=20
after all the ability to snapshot it on fs level is one of its defining=
=20
features...

--=20
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawer=C3=B3w 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Backup Command

[Ivan Labáth]

On 01/11/11 15:40, Hubert Kario wrote:
> On Tuesday, January 11, 2011 15:33:38 Ivan Lab=C3=A1th wrote:
>> On 01/11/11 15:19, Hubert Kario wrote:
>>> On Tuesday, January 11, 2011 14:54:38 Ivan Lab=C3=A1th wrote:
>>>> On 01/10/11 14:36, Hubert Kario wrote:
>>>>> On Monday 10 of January 2011 14:25:32 Carl Cook wrote:
>>>>>> Here is my proposed cron:
>>>>>>
>>>>>> btrfs subvolume snapshot hex:///home
>>>>>> /media/backups/snapshots/hex-{DATE}
>>>>>>
>>>>>> rsync --archive --hard-links --delete-during --delete-excluded
>>>>>> --inplace --numeric-ids -e ssh
>>>>>> --exclude-from=3D/media/backups/exclude-hex hex:///home
>>>>>> /media/backups/hex
>>>>>>
>>>>>> btrfs subvolume snapshot droog:///home
>>>>>> /media/backups/snapshots/droog-{DATE}
>>>>>>
>>>>>> rsync --archive --hard-links --delete-during --delete-excluded
>>>>>> --inplace --numeric-ids -e ssh
>>>>>> --exclude-from=3D/media/backups/exclude-droog droog:///home
>>>>>> /media/backups/droog
>>>>>>
>>>>>> Comments?  Criticisms?
>>>>>
>>>>> This will make the dates associated with snapshots offset by how =
often
>>>>> cron is run.
>>>>>
>>>>> In other words, if you run above script daily you will have data =
from
>>>>> 2011.01.01 in the hex-2011.01.02 directory.
>>>>>
>>>>> I do save the current date, do a LVM snapshot on the source, rsyn=
c
>>>>> --inplace data over and do a local snapshot naming the folder usi=
ng the
>>>>> saved date. This way the date in the name of backup directory is =
exact
>>>>> to about a second.
>>>>
>>>> If you are mounting a LVM snapshot of an already mounted filesyste=
m,
>>>> would you be willing verify that it is really a snapshot that is
>>>> mounted?
>>>>
>>>> e.g. touch /mnt/live/its_alive && ls /mnt/snapshot/
>>>>
>>>> I am nearly willing to bet it is not a snapshot.
>>>
>>> well, by "LVM snapshot on the source" I meant:
>>> 1. do lvcreate --snapshot
>>> 2. mount newly created volume
>>> 3. use the new directory as the base for rsync
>>> 4. arrange umount and destruction of the snapshot after rsync compl=
etes
>>> (no matter if it was successful)
>>>
>>> and this will in fact not make the "its_alive" visible in /mnt/snap=
shot
>>>
>>> You have to use this procedure if you use LVM snapshots for backup =
no
>>> matter to where do you copy data. That's why I shortened it to a si=
ngle
>>> point -- it's not the part that is important from btrfs perspective=
=2E
>>>
>>> Regards.
>>
>> The point I was trying to make is: it does not work with btrfs.
>> Try the above with a btrfs and you will be surprised.
>> If the source volume uses another filesystem, it should work properl=
y.
>>
>> regards,
>> ivan
>=20
> Yes, you are right, but I don't see a point in using LVM snapshots wi=
th btrfs,=20
> after all the ability to snapshot it on fs level is one of its defini=
ng=20
> features...
>=20

Yes, silently mounting another filesystem is the right thing to do.
When there already is a mounted filesystem probably containing nearly
identical data, the kernel should not bother allocating separate struct=
ures
for yet another copy of it. The user probably won't notice anyway.

--
ivan
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Backup Command

[Carl Cook]

Apparently my command is no good.  No one ever responded to my question below, so maybe I'm not smart enough to ask the right way.

I can ssh from the backup server to the HTPC, but it crashes with a 'dirty' error:
# rsync --progress --archive --hard-links --links --delete-during --delete-excluded --inplace --numeric-ids -e "ssh -l root" root@hex:///home /media/backups/hex-home
root@hex's password: 
protocol version mismatch -- is your shell clean?
(see the rsync man page for an explanation)
rsync error: protocol incompatibility (code 2) at compat.c(173) [Receiver=3.0.7]

"see the rsync man page for an explanation"?  No idea where, but it's sure not in the first third.  I have the same rsync and ssh on each.


On Mon 10 January 2011 05:25:32 Carl Cook wrote:
> 
> Here is my proposed cron:
> 
> btrfs subvolume snapshot hex:///home /media/backups/snapshots/hex-{DATE}
> 
> rsync --archive --hard-links --delete-during --delete-excluded --inplace --numeric-ids -e ssh --exclude-from=/media/backups/exclude-hex hex:///home /media/backups/hex
> 
> btrfs subvolume snapshot droog:///home /media/backups/snapshots/droog-{DATE}
> 
> rsync --archive --hard-links --delete-during --delete-excluded --inplace --numeric-ids -e ssh --exclude-from=/media/backups/exclude-droog droog:///home /media/backups/droog
> 
> Comments?  Criticisms?
> 
> 

Re: Backup Command

[cwillu]

On Fri, Jan 14, 2011 at 7:17 PM, Carl Cook <CACook@quantum-sci.com> wro=
te:
>
> Apparently my command is no good. =A0No one ever responded to my ques=
tion below, so maybe I'm not smart enough to ask the right way.
>
> I can ssh from the backup server to the HTPC, but it crashes with a '=
dirty' error:
> # rsync --progress --archive --hard-links --links --delete-during --d=
elete-excluded --inplace --numeric-ids -e "ssh -l root" root@hex:///hom=
e /media/backups/hex-home
> root@hex's password:
> protocol version mismatch -- is your shell clean?
> (see the rsync man page for an explanation)
> rsync error: protocol incompatibility (code 2) at compat.c(173) [Rece=
iver=3D3.0.7]
>
> "see the rsync man page for an explanation"? =A0No idea where, but it=
's sure not in the first third. =A0I have the same rsync and ssh on eac=
h.

rsync can speak ssh already, you shouldn't need to provide '-e "ssh -l
root"' unless you're doing something odd.  That said, try:  '-e "ssh
-l root -e none"' to disable ssh's escape character.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html