On 08/02/17 18:38, Libor Klepáč wrote: > I'm interested in using: ... > - send/receive for offisite backup I don't particularly recommend that. I do use send/receive for onsite backups (I actually use btrbk). But for offsite I use a traditional backup tool (I use dar). For three main reasons: 1) Paranoia: I want a backup that does not use btrfs just in case there turned out to be some problem with btrfs which could corrupt the backup. I can't think of anything but I did say it was paranoia! 2) send/receive in incremental mode (the obvious way to use it for offsite backups) relies on the target being up to date and properly synchronised with the source. If, for any reason, it gets out of sync, you have to start again with sending a full backup - a lot of data. Traditional backup formats are more forgiving and having a corrupted incremental does not normally prevent you getting access to data stored in the other incrementals. This would particularly be a risk if you thought about storing the actual send streams instead of doing the receive: a single bit error in one could make all the subsequent streams useless. 3) send/receive doesn't work particularly well with encryption. I store my offsite backups in a cloud service and I want them encrypted both in transit and when stored. To get the same with send/receive requires putting together your own encrypted communication channel (e.g. using ssh) and requires that you have a remote server, with an encrypted filesystem receiving the data (and it has to be accessible in the clear on that server). Traditional backups can just be stored offsite as encrypted files without ever having to be in the clear anywhere except onsite. Just my reasons. -- 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
