There are many ways of handling data that size. A lot of it depends on your environment and how much money you're willing to spend. In general there are a few overall 'get the data off the server' strategies:
- Over the Ethernet Like it says on the box, data is streamed to Some Where Else for handling. 20TB will take a long time to copy over 1GbE, but it can be done. Hardware can help (such as 10GbE links, or in some cases NIC bonding).
- Over the Storage subsystem If you're on Fibre Channel, send it to another device on the FC network. If you've got SAS, send it to a SAS-attached device. Generally faster than Ethernet.
- Send it to another disk array Send it to another hunk of storage attached to the same server.
That's the 100Km view. Once you start zooming in things get a lot more fragmented. As already mentioned, LTO5 is a specific tape technology that designed for these kinds of high-density loads. Another identical storage array is a good target, especially if you can use something like GlusterFS or DRBD to get the data over there. Also, if you need a backup rotation or just the ability to keep running in case the array fails will affect what you put into place.
Once you've settled on a 100Km view method, getting into software will be the next big task. Factors influencing this are what you can install on your storage server in the first place (if its a NetApp, that's one thing, a Linux server with a bunch of storage is another thing entirely, as is a Windows server with a bunch of storage), what hardware you pick (not all FOSS backup packages handle tape-libraries well, for instance), and what kind of backup retention you require.
You really need to figure out what kind of Disaster Recovery you want. Simple live-replication is easier, but doesn't allow you to restore from last-week only just-now. If the ability to restore from last week is important to you, then you need to design for that sort of thing. By law (in the US and else where) some data needs to be preserved for 7+ years.
Simple replication is the easiest to do. This is what DRBD is designed to do. Once the initial copy is done, it just sends changes. Complicating factors here are network locality, if your 2nd array is not near to the primary DRBD may not be feasible. You'll need a 2nd storage server with at least as much storage space as the first.
About tape backup...
LTO5 can hold 1.5TB of data w/o compression. Feeding these monsters requires very fast networking, which is either Fibre Channel or 6Gb SAS. Since you need to back up more than 1.5TB in a whack you need to look into autoloaders (here is an example: link, a 24 slot 1-drive autoloader from HP). With software that supports them, they'll handle changing tapes mid-backup for you. They're great. You'll still have to pull tapes out to send to off-site, but that's a damn sight better than hanging around all night to load tapes yourself when the backup calls for them.
If tape gives you the 'legacy, ew' heebiegeebies, a Virtual Tape Library may be more your speed (such as this one from Quantum: link). These pretend to be tape libraries to backup software while actually storing things to disk with robust (you hope) de-duplication techniques. The fancier ones will even copy virtual-tapes to real-tapes for you, if you like that sort of thing, which can be very handy for off-site rotations.
If you don't want to muck about with even virtual tapes, but still want to do direct-to-disk backups, you'll need a storage array sized big enough to handle that 20TB, plus however much net-change data you want to keep a hold of. Different backup packages handle this differently. Some de-duplication technologies are really nice, others are hacky kludges. I personally don't know the state of FOSS backup software packages in this area (I've heard of Bacula), but they may be sufficient. A lot of commercial backup packages have local agents you install on servers to be backed up in order to increase throughput, which has a lot of merits.
I am on Ubuntu LTS 14 and just ran the following (for first time even) and it worked like a charm:
lxc-stop -n ubuntu_base
lxc-clone -o ubuntu_base -n ubuntu_base_c1 -s
lxc-start -n ubuntu_base_c1 -d # make changes if needed
lxc-stop -n ubuntu_base_c1
lxc-snapshot -n ubuntu_base_c1
Using -s with lxc-clone will take a snapshot if backing store is btrfs (in your case).
Verify new clone/snapshots with
lxc-ls -f
btrfs subvolume list /var/lib/lxc
Hope that helps!
Best Answer
No tricks needed:
Credits: https://discuss.linuxcontainers.org/t/how-to-move-containers-to-a-new-storage-pool-on-the-same-host/2798