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?
--
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
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. -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 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
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 -- 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
On Tuesday, January 11, 2011 14:54:38 Ivan Labáth 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=/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.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 completes (no 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 matter to where do you copy data. That''s why I shortened it to a single point -- it''s not the part that is important from btrfs perspective. Regards. -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 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
On 01/11/11 15:19, Hubert Kario wrote:> On Tuesday, January 11, 2011 14:54:38 Ivan Labáth 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=/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. > > 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 completes (no > 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 matter > to where do you copy data. That''s why I shortened it to a single point -- it''s > not the part that is important from btrfs perspective. > > 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
On Tuesday, January 11, 2011 15:33:38 Ivan Labáth wrote:> On 01/11/11 15:19, Hubert Kario wrote: > > On Tuesday, January 11, 2011 14:54:38 Ivan Labáth 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=/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. > > > > 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 completes > > (no 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 > > matter to where do you copy data. That''s why I shortened it to a single > > point -- it''s not the part that is important from btrfs perspective. > > > > 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, > ivanYes, you are right, but I don''t see a point in using LVM snapshots with btrfs, after all the ability to snapshot it on fs level is one of its defining features... -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 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
On 01/11/11 15:40, Hubert Kario wrote:> On Tuesday, January 11, 2011 15:33:38 Ivan Labáth wrote: >> On 01/11/11 15:19, Hubert Kario wrote: >>> On Tuesday, January 11, 2011 14:54:38 Ivan Labáth 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=/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. >>> >>> 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 completes >>> (no 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 >>> matter to where do you copy data. That''s why I shortened it to a single >>> point -- it''s not the part that is important from btrfs perspective. >>> >>> 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 > > Yes, you are right, but I don''t see a point in using LVM snapshots with btrfs, > after all the ability to snapshot it on fs level is one of its defining > features... >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 structures 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
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? > >-- 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
On Fri, Jan 14, 2011 at 7:17 PM, Carl Cook <CACook@quantum-sci.com> wrote:> > 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.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
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
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 > . >-- 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
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
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 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?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 MythTV. And, "/path/to/your/rsync/script" would call your actual backups script that runs rsync. -- Freddie 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
On Fri 21 January 2011 11:44:24 Freddie Cash wrote:> #!/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"Ho-lee crap, this is fantastic. Everything seems to work. I find though 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 case. Well it''s been 12 hours and I''m still doing my first HTPC data transfer, so not all commands are tested (untested==#), but I am confident they will work. I''m donating my (weekly) cron script here in case it helps 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 theft or fire) with a SuperMicro 5 disk hot-swap cage, 6TB so far. (WD Green 2TB now $80 with rebate!) phone - Android Nexus One with 16GB SD The backup server has SSH credentials on the other systems, but only the work laptop can ssh to it (limited by Shorewall). The backup server will also handle security cameras and will presumably dnat a port to the 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 nothing 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 systems # # Copyleft © 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-during --delete-excluded --inplace --numeric-ids --log-file=/media/backups/hex-home-$(date +"%Y-%m-%d").log -e ssh root@hex:///home/ /media/backups/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-during --delete-excluded --inplace --numeric-ids --exclude-from=/media/backups/exclude-root --log-file=/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/backups/droog-home-snap-$(date +"%Y-%m-%d") /usr/bin/rsync --archive --checksum --compress --hard-links --delete-during --delete-excluded --inplace --numeric-ids --log-file=/media/backups/droog-home-$(date +"%Y-%m-%d").log -e ssh root@droog:///home/ /media/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 mythconverg -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/backups/droog-root-snap-$(date +"%Y-%m-%d") /usr/bin/rsync --archive --checksum --compress --hard-links --delete-during --delete-excluded --inplace --numeric-ids --exclude-from=/media/backups/exclude-root --log-file=/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-during --delete-excluded --inplace --numeric-ids --log-file=/media/backups/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