ZFS ZFS Jails Backup Strategy

Martin Garcia

Member


Messages: 21

Hello there,
Im new to FreeBSD, but quite experienced in Linux,
Currently I have CentOS7 virtual machines that runs on KVM. I want to move some of them to FreeBSD/Jails, however Im not clear about the backup strategy that I should run once in jails.

Some of my motivations to move from Linux to FreeBSD are jails, ZFS with lz4, and the way one can manage a FreeBSD.

My Linux vms have incremental and full data backups and periodically the vms can be moved to a remote storage or another server if needed. Im not sure how to achieve the movement of the jail to another host or to backup the full jail.

Thanks in advance for your answers

Martin
 

ekingston

Active Member

Reaction score: 57
Messages: 213

You can use all the generic backup tools you are used to. Tar and gzip and rsync work just fine if you are used to those. But ...

ZFS has the major advantage that you can make snapshots of a filesystem at a specific time. So, to make a nice clean backup you can:
  1. shutdown all the services (especially databases) briefly to ensure data is flushed to disk and files are stable.
  2. create a zfs snapshot.
  3. restart all the services. Thus a downtime of well under a minute is achieved.
  4. run your backup tools on the snapshot.
  5. remove the snapshot or keep a small set of snapshots you can use to restore files locally and quickly.
On the backup tools, you can take advantage of another feature in ZFS. ZFS has built in tools to send and receive a ZFS filesystem (possibly I should say dataset, I've not quite figured out the right terminology) over a network connect and write it to another zfs filesystem.

There are lots of examples of zfs send and zfs recv commands in these forums. I leave finding them up to you.
 
OP
OP
Martin Garcia

Martin Garcia

Member


Messages: 21

Thanks for the reply ekingston,
- Does these snapshot counts as a backup?
- If needed, can I move this snapshot to another host?

Thanks for the lights, I will look for zfs and zfs recv

Martin
 

ekingston

Active Member

Reaction score: 57
Messages: 213

Thanks for the reply ekingston,
- Does these snapshot counts as a backup?
Depends on your definition, but not in the strict traditional sense.

- If needed, can I move this snapshot to another host?
Yes. Or, more accurately copy to another host and then remove from the original.

Thanks for the lights, I will look for zfs and zfs recv

Martin
Snapshots don't really count as "backup" in the traditional sense. A snapshot is somewhat like telling the operating system to freeze the filesystem at a specific point in time and layer any changes on top of that frozen state. At any point in the future you can look at the frozen state and compare it to the current state to see what changed.

Like a backup, any file that is deleted on the current filesystem would still be in the frozen snapshot and any file that got added after the snapshot won't appear in the snapshot. But the snapshot is not a copy. Any file that hasn't changed will appear in both but will only be one copy (ignoring ZFS mirroring). Snapshots won't protect you from drive failures.

Snapshots are useful as a recovery tool if a program corrupts a file or someone wants to recover a deleted file.

They are also very useful for backing up files that are normally locked by a program all the time and can't be backed-up without shutting down the program. A snapshot is a lot faster than copying a file, so the shutdown is much briefer.

Reading through chapter 19 of the FreeBSD handbook is a good place to start understanding ZFS (https://www.freebsd.org/doc/handbook/zfs.html)

I also suggest having somewhere to test things so you can start to practice with ZFS and test out what you can do with it without risking your primary system(s).
 

rigoletto@

Daemon
Developer

Reaction score: 875
Messages: 1,840

You can use snapshot as backup if you create a backup strategy using snapshots and replicating them to a remote machine. The recovery should be even faster than using a traditional backup system, like bacula.

Some tools that might interest you:

sysutils/zap: zap;
sysutils/cbsd: cbsd.
sysutils/iocell: iocell;
sysutils/iohyve: iohyve;

I do not know cbsd well, but sysutils/iocell take automatic snapshots of the jails.

An Article.

EDIT: you may also want take a look at ClonOS. There is a folk who usually hang here and is related with that project, but I do not remember who he/she is.
 
OP
OP
Martin Garcia

Martin Garcia

Member


Messages: 21

sko

Well-Known Member

Reaction score: 221
Messages: 430

So, to make a nice clean backup you can:
  1. shutdown all the services (especially databases) briefly to ensure data is flushed to disk and files are stable.
  2. create a zfs snapshot.
  3. restart all the services. Thus a downtime of well under a minute is achieved.
  4. run your backup tools on the snapshot.
  5. remove the snapshot or keep a small set of snapshots you can use to restore files locally and quickly.
Most databases can also write full dumps and/or transaction protocols. These can also be written to a shared location (not necessary for jails) where your script/backup strategy picks them up and transfers to a ZFS dataset. This way you don't have to stop/start the DB-server.

I'm using this procedure to collect backups of a MSSQL server - it dumps once every night and writes out hourly transaction logs for most databases; so cron runs my script hourly just after the logs (or dump) have been written.
zfsnap(8) is used to take and rotate snapshots with various hold-times (from 48hours up to 4 weeks). The backup-pool/datasets is/are replicated multiple times per day to a NAS where longer-term snapshots are kept.

Databases are very compressible, so activate it on the backup dataset(s). Also, backups where only a small fraction of data/blocks actually differ from one full dump to another (e.g. full filesystem dumps from VMs or also databases), deduplication can be very efficient. If you have enough RAM this might help keeping the storage requirements low when backing up lots of servers; but dedup takes anywhere from ~3-5GB per TB of deduplicated data, so do the math first to check if this is a viable option in your case.
 
Top