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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
