Forgot your password?
typodupeerror
Linux

Volume Shadow Copy For Linux? 300

Posted by Soulskill
from the restorative-tux dept.
An anonymous reader writes "I was asked to manage a number of Linux servers at work. I would like to use volume snapshots to improve my backup scripts and keep recent copies of data around for quick restore. I normally manage Windows servers and on those I would just use Microsoft's Volume Shadow Copy for this. I tried Linux LVM snapshots, but most of the servers I manage run regular partitions with ext3 file systems, so LVM snapshots will not work. I found some versioning file systems out there like ext3cow and Tux3. Those look interesting, but I need something I can use on my existing ext3 file systems. I also found the R1Soft Hot Copy command-line utility, but it does not yet support my older 2.4 Linux servers. What are you using to make snapshots on Linux?"
This discussion has been archived. No new comments can be posted.

Volume Shadow Copy For Linux?

Comments Filter:
  • nilfs (Score:2, Informative)

    by pinkishpunk (1461107)
    Nilfs will have those things, but you`ll have to wait till its production ready.
  • by Anonymous Coward on Friday June 11, 2010 @02:51PM (#32540680)

    Linux servers don't get backed up, they only get migrated to new hardware every five years. (BSD is the same, except for the second part.)

    • by mikemsd (225775) on Friday June 11, 2010 @02:55PM (#32540734)

      Sweet, I'm going to install Linux on all my systems. I didn't know that Linux could prevent natural and man made disasters as well as being a stable operating system. We've been wasting all this money on backup for all these years.

      • by Unoti (731964) on Friday June 11, 2010 @03:40PM (#32541452) Journal

        Sweet, I'm going to install Linux on all my systems. I didn't know that Linux could prevent natural and man made disasters as well as being a stable operating system. We've been wasting all this money on backup for all these years.

        There's a mix of humor and catty vitriol here all around, but here is something that addresses the serious point made in Grandparent's statement about it being a "Windows" way of thinking.

        Take a look at Infrastructures.org [infrastructures.org] which describes a whole way of thinking about server reliability and configuration. Where I work we essentially use this approach. The fundamental concepts around this approach concentrate more on system configuration, ability to pick a random server and drop it out the window and have another one just like it online in moments. It's less about backups, and far more about a more comprehensive disaster recovery/prevention type of thing. The types of approaches described there are probably more easily implemented using Unix/Linux, but is probably also possible with Windows boxes.

        • Re: (Score:3, Interesting)

          infrastructures.org looks interesting, but then I see they mention things like 'NetSaint' which was renamed to be Nagios about 7 years ago, and references to "LISA '98".

          Some of this information looks old. Am I right? These days, shouldn't we be thinking more about virtualization and cloud infrastructure?

          That said, they do touch upon many good ideas. It seems that many mid-sized shops do follow some similar ideas.

          • by Unoti (731964) on Friday June 11, 2010 @06:53PM (#32544380) Journal

            Yes, it's very old. They also talk about using cvs for version control, and mention that that world has moved on to svn, and the world has moved on a couple of times since then even. We also use Nagios rather than more ancient monitoring software. But still the central ideas are sound, even with many details changed. And practical, too.

            These ideas actually apply very much to cloud infrastructure. It's really all about the cloud-- considering a machine not as just "a machine", but instead thinking of it as having a base image with certain functionality bolted on top of it. Thinking of a machine not just as a machine, but as a replaceable/exchangeable component in a larger collective system. That essentially is cloud computing. The thing a lot of people don't consider is that even a smaller cluster of machines should/could be configuration managed, maintained, and viewed this way.

        • by vegiVamp (518171) on Saturday June 12, 2010 @08:07AM (#32548900) Homepage
          Shadow copies are not about server reliability, they're about stupid users inadvertently overwriting or deleting wrong files, and allowing them to fix their mistakes themselves, without needing to access the backup system or bothering the system administrators.

          Also, versioning filesystems make a copy-on-write, so there's a backup of *every* version of a file, and not only the versions that are there when the backup (or shadowcopy) runs. It's been only this week that we've been looking fruitlessly through the backups for some vanished files. We can only assume that the files were erroneously deleted on the same day they were created, before the backups had a chance of picking them up.
  • Suck it up (Score:5, Insightful)

    by mewsenews (251487) on Friday June 11, 2010 @02:52PM (#32540686) Homepage

    You will have to migrate your servers with plain ext3 to LVM-based ext3. Short term pain for long term gain.

    • That would be my advice too. Migrate.

      Eventually you're going to want to migrate those filesystems to btrfs as well, and that has really nice built-in snapshotting capability. But until then (a few years from now) move to LVM. It will save you so much hassle and be much more tested and stable than some hack like ext3cow

    • Indeed. I've done so, and documented it:

      http://www.tolaris.com/2010/05/06/moving-an-existing-backuppc-partition-to-lvm/ [tolaris.com]

      People smarter than me documented a way to move the data, live, even when the partition is nearly full. See the comments there.

    • by evilviper (135110)

      Short term pain for long term gain.

      Actually, I'd call LVM the long-term pain. For all it's benefits, I don't want my servers to become unresponsive when large files are being written. Doesn't happen on regular partitions, only with LVM.

  • by tlambert (566799) on Friday June 11, 2010 @02:54PM (#32540714)

    "does not yet support my older 2.4 Linux servers"

    So upgrade your servers to a supported release instead?

    -- Terry

    • by 0racle (667029) on Friday June 11, 2010 @03:05PM (#32540908)
      There are Enterprise Linux distributions that are both supported and still run 2.4, though not for much longer. Not everyone runs Ubuntu.
    • by impaledsunset (1337701) on Friday June 11, 2010 @03:12PM (#32541028)

      I'm troubled why people still run 2.4 server. I remember the time when I was reluctant to upgrade to 2.6, and I used prefer the older 2.4, which felt more comfortable than 2.6, regardless of how tempting the new changes sounded. But now I don't see any reason I would run this anywhere, even my router runs 2.6. Especially on newer hardware, 2.4 is really really too old.

      I know there are people who probably still run Linux 2.2, but that are probably systems that are running some task well enough to require any changes, and leaving them as they are is the best. Servers are usually not like that. They need security updates, upgrades to catch up with the times, and many other changes required by the circumstances (for example, adding snapshot abilities, for which some person asked recently on Slashdot). Most production servers are not systems that you just leave running, so upgrades to the kernel are also expected and highly recommended. Not to mention that most recent distributions require 2.6.

      • I'm troubled why people still run 2.4 server

        They fit in well with his other servers, still running Windows 98 Advanced Server Edition.

        But seriously, migrate to LVM already.

      • by bertok (226922)

        Quoth Wikipedia:

        4 January 2001 - Linux 2.4.0 was released (3,377,902 lines of code).

        That's about the same as running Windows 2000 Server in a production environment.

        • Re: (Score:3, Insightful)

          by omglolbah (731566)

          Win2k is still used widely all over the world in production environments.

          The problem with systems that work is that you're usually not to touch them until they stop working :(

          • Re: (Score:3, Interesting)

            by ArsonSmith (13997)

            Exactly, about 2 1/2 years ago I worked for a large company that everyone here has heard of that at the time was running ~4000 servers on a modified Redhat 6.2 image. There was a large code base that got lost sometime in the start-up phase of the mid 90s that was much easier to never touch the OS then to re-write the code.

            • Re: (Score:3, Interesting)

              by omglolbah (731566)

              Some of our systems still use token ring coax networks and OpenVMS servers.

              The problem is that the fuckers just work... and keep on chugging along happily in the basement of the plant...

    • Re: (Score:3, Informative)

      by carton (105671)

      +1.

      u r doing it rong.

      If you need to keep around such old software, it needs to be running inside Xen/VirtualBox and/or become NFS-booted so that it's insulated from the hardware. That way, you're not forced to keep around old hardware to run your old software. If you insulate with Xen/VBox at the block level you can use LVM2 on the host system to do snapshots but are still constrained by the legacy filesystem. If you NFS-boot, you can use future filesystem-level snapshottable Linux filesystems to do snap

  • LVM Snapshots (Score:2, Informative)

    by theunixman (538211)

    I use them on ext3 with no problems. It's true that very early on there was a problem with them and journaled filesystems, but that has long since been solved.

  • by vadim_t (324782) on Friday June 11, 2010 @02:55PM (#32540724) Homepage

    LVM snapshots work on a block level and don't care about the filesystem. A snapshot of any data in a logical volume should work fine, even if it's not a recognized filesystem.

    A nice use for this is using a read/write snapshot to try different strategies for recovering a broken filesystem.

    • by Trepidity (597)

      I think he's saying that he can't use LVM snapshots, because some of his servers have ext3 directly on a plain partition, not on top of LVM (used to be a common setup).

  • ZFS? (Score:3, Informative)

    by corran__horn (178058) on Friday June 11, 2010 @02:57PM (#32540770)

    I will admit that I have not tried it on Linux, but zfs is the best of the next gen filesystems. It does cryptographically assured reads and writes (remember that transitory undetected disk malfunctions occur at a rate of ~1/TB of data), it can snapshot changes, it fricken slices bread. If it had a gender, I would probably marry it (well, I guess I can date it for a while and see how things work out). http://zfs-fuse.net/ [zfs-fuse.net]

  • by xee (128376) on Friday June 11, 2010 @03:00PM (#32540812) Journal

    RSnapshot uses a clever blend of rsync + hard links to do what you want... you can store many incremental backups in just a little more space than a full backup. you can run rsnapshot on a backup server with lots of disk space, and all you need to expose on your target machines is SSH.

    you'd create "backup" users on all the target hosts, generate a PKI key pair, and put the private key on your backup server. put the public key in the "backup" account on each target machine so the backup server can securely login without a password. then you just set up rsnapshot to log into your targets and it will use rsync-over-ssh to pull the data.

    http://rsnapshot.org/ [rsnapshot.org]

    • Re: (Score:3, Informative)

      by dfn_deux (535506)
      This is no good for a true snapshot since the rsync operation is non-atomic on a live filesystem.
      • Re: (Score:3, Informative)

        by jgrahn (181062)

        [RSnapshot] is no good for a true snapshot since the rsync operation is non-atomic on a live filesystem.

        I cannot help wondering when I read stuff like that who *really need* atomic, and who just like it because it sounds cool ... If that 2.4 guy doesn't really *need* theoretical atomicity, and he can do his work with something much more simple, he should.

        • Re: (Score:3, Informative)

          by dfn_deux (535506)
          i wasn't trying to guess at what he needed, but his question was about snap shotting. One of (if not THE) key feature of a snapshot is that it is atomic. Anything that rolls through a changing filesystem one file at a time is not going to fit that bill. Also you run the risk of making "backups" that could break things that presume state consistency. If you capture the log of a daemon before the product output then your backup could have no record of the event which created the output for example.

          These types

  • Hobbling Along (Score:3, Informative)

    by kwalker (1383) on Friday June 11, 2010 @03:00PM (#32540816) Journal

    Since the situation is so hobbled (Old Linux kernel, no LVM) about the only thing you will be able to do is learn to use hardlinks [wikipedia.org]. The ext* filesystems support them but you will have to manage them yourself (cp -varl /source/* /destination/version). Yeah it's a huge hack, but unless you can actually fix the problem, it's about your only hope.

  • Eh? (Score:5, Informative)

    by ledow (319597) on Friday June 11, 2010 @03:00PM (#32540822) Homepage

    If you have backups, then moving to LVM is obviously the way to go if you desire snapshots. The others options are short-term hackery, LVM was designed from the ground up to do such things. And Ext3 has nothing to do with the price of butter.

    To clarify, let me rephrase your question for the other way around

    "I was asked to manage a number of *Windows* servers at work. I would like to use volume snapshots to improve my backup scripts and keep recent copies of data around for quick restore. I tried Windows Shadow Copy, but most of the servers I manage run MBR partitions with FAT file systems, so Shadow Copy will not work. I found some versioning file systems out there... Those look interesting, but I need something I can use on my existing FAT file systems. I also found --random freeware--, but it does not yet support my older Windows NT 3.5 servers. What are you using to make snapshots on Windows?"

    Except, in that case, it makes more sense because the filesystem is the determining factor, not the volume management. If you have LVM, it doesn't matter what the underlying filesystem is, really. Stop faffing about - if you have a server, with backups, that you need snapshots on, take the hit and wipe the drives to a config that supports that... while you're there upgrade that damn kernel already. If nothing else, it will test that the backups you're making are actually worth the effort. It's like complaining that 95 on FAT16 doesn't support Shadow Copy. If you absolutely *can't* take those servers down, or am unable to restore your backups to another machine for testing such changes (whether because of compatibility, software licensing and/or bad backups), you have bigger problems than some random desire for a feature you don't actually *need* at the moment.

  • by CAIMLAS (41445) on Friday June 11, 2010 @03:07PM (#32540948) Homepage

    Knowing where to start on this is a bit of a miffing point.

    First: upgrade your shit. 2.4 kernel systems? Are you running Redhat 6? You know, from the turn of the millennia.

    Second: upgrade your shit. Really,

    Third: if your kernels are that old and you're using these machines for file storage/backup, chances are the hardware needs to be replaced before you even consider considering messing with them. Seriously: this stuff is ancient. Even Debian hasn't had a 2.4 kernel in 5+ years, I think.

    Third: you can do what you're trying to do with rsync 'snapshots'. It works very well, failing filesystem level support. If you're sharing data over samba, this makes it easy: just put a '.snapshot' dir for these 'temporary' backups in their $HOME and hide dotfiles. Then make sure rsync ignores .snapshot. (Of course, there are other ways to do this.)

    rsync snapshots [mikerubel.org] (and here [backupcentral.com]).

    There are other sources of information out ther on rsync snapshots. There's also rsnapshot.

    Chances are you'll have to upgrade before this stuff even works for you, though.

    • Re: (Score:3, Informative)

      by evilviper (135110)

      2.4 kernel systems? Are you running Redhat 6? You know, from the turn of the millennia.

      Redhat 6 was a 2.2.x kernel. So was Redhat 7. While the VER FIRST release of kernel 2.4.x was indeed right around 2001, the most recent revision of 2.4.x was just 4 months ago.

      you can do what you're trying to do with rsync 'snapshots'.

      Not really. There's no atomic rsync snapshots, so while one file in the "snapshot" will be from 12:01, another file might be from 12:15, and depending on the application, the two files mi

  • by Alex Belits (437) * on Friday June 11, 2010 @03:08PM (#32540964) Homepage

    People expect a snapshot to be immediately usable and reliable, however in practice a state of device, even if synchronized with filesystem through its transaction is not a state of all data -- some data may be in buffers, prepared to be written, and rebooting into a restored filesystem may require some cleanup of such state. In particular, SQL databases are completely unsuitable for this kind of backup (this is why they have their own backup and transaction log handling procedures), and database-like applications such as mail servers, may require reindexing.

    However for purposes other than those applications, file-level backup is entirely adequate, so utilities like rdiff-backup end up providing more functionality than complicated snapshot-handling procedures -- incremental backups for subtrees, readable trees in backup media, etc.

    It also should be noted that backups should not be used as a replacement of package management -- on Linux anything installed through a package manager can be uninstalled through it.

    • by bertok (226922) on Friday June 11, 2010 @06:47PM (#32544302)

      Absolutely not! Snapshots are perfectly safe for capturing your database data.

      On real server operating systems snapshot support is integrated into applications, which receive a "snapshot about to occur event" so they can quiesce their writes for a short period to make the snapshot clean.

      For example, on a Windows server, a VSS snapshot is a complete restorable backup of everything, including your databases, event logs, the registry, etc... It's the standard mechanism that practically all Windows backup tools use. They take a snapshot, back it up, and then release it. The point in time that the snapshot was taken turns up in the "last backed up on" date field in SQL Server!

      Even third party snapshot mechanisms integrate using plugins. If you take a snapshot with, say, VMware or your SAN, then the same quiescing mechanism is triggered.

      Some real server operating systems like HP-UX appear to have LVM extensions that are similar to what VSS can do, but I can't find the equivalent in Linux. From what I can see, the closest you can get is to temporarily halt writes from the ext3 filesystem, but that's not the same thing as proper application quiescing.

    • by Craig Ringer (302899) on Saturday June 12, 2010 @01:47AM (#32547266) Homepage Journal

      "In particular, SQL databases are completely unsuitable for this kind of backup (this is why they have their own backup and transaction log handling procedures)"

      While snapshots aren't ideal for SQL DBs, any real snapshot is equivalent to a point-in-time copy of the state of the file system. Restoring it and starting the database should seem to the database just like it's recovering after unexpected power failure or a process crash.

      Any database that doesn't recover properly after a snapshot restore will also fail to recover properly after powerfail or a sudden hardware reset, because it's not ordering its writes properly.

      Of course, proper snapshot implementations (ie not LVM) notify apps that a snapshot is about to happen so they can pause their work and enter a stable, easy to recover from state for the moment it takes to make the snapshot. So it's even easier on the database.

      Now, I'll grant that for databases it's usually *better* to do incremental block-level copies, SQL-level dumps, etc using the databases own tools because doing so is usually much more _efficient_ than taking a snapshot then archiving it somewhere. But sometimes you just want the snapshot around as insurance before doing a major config change or upgrade, and for that they're just unbeatable.

      While I don't much like Windows servers in general, I have a major case of VSS envy (Volume Snapshot Service, not Visual Source Safe - blech!), because it's worlds ahead of anything seen on any open *nix and has been for nearly ten years. Hell, my one and only Windows server maintains in incremental backup of its self on a remote iSCSI volume, including many point-in-time snapshots, that I can just unplug from the iSCSI storage host and boot if I need to for disaster recovery. It's impressive, and VSS is the core of what makes it possible.

  • Take a look at rdiff-backup [nongnu.org].

    rdiff-backup backs up one directory to another, possibly over a network. The target directory ends up a copy of the source directory, but extra reverse diffs are stored in a special subdirectory of that target directory, so you can still recover files lost some time ago. The idea is to combine the best features of a mirror and an incremental backup. rdiff-backup also preserves subdirectories, hard links, dev files, permissions, uid/gid ownership, modification times, extended attributes, acls, and resource forks. Also, rdiff-backup can operate in a bandwidth efficient manner over a pipe, like rsync. Thus you can use rdiff-backup and ssh to securely back a hard drive up to a remote location, and only the differences will be transmitted. Finally, rdiff-backup is easy to use and settings have sensical defaults.

    I can confirm that rdiff-backup is indeed easy to use.

    • by Gogo0 (877020)

      i was doing an rsync mirror from one hard drive to another every evening (cron of course). now iv got incrementals out of 5 minutes of work.
      thanks for the recommendation!

  • Seriously, what is wrong with dump(8)? It works on ext3. I use it on FreeBSD. It takes snapshots to do the dump, so you can shutdown your database, start the dump and then immediately start your database again. Of course you have to backup the entire volume, but still...
    • Re: (Score:2, Informative)

      by Carl Drougge (222479)

      I'm pretty sure the Linux version of dump doesn't do any snapshoting. The FreeBSD version can do it because the FS supports snapshots, but ext3 does not. (Maybe it will do snapshots automatically if you have a setup that will support them, but the original problem is that this is not the case.)

      • by mr_da3m0n (887821)
        You are right, I researched it a bit better, and it is dependent on the filesystem, and ext3 doesn't do any snapshotting. Oh well :(
  • by msh104 (620136) on Friday June 11, 2010 @03:26PM (#32541204)

    Just upgrade your kernel using a manual build of the 2.6 kernel.
    Also install static versions of the modutils ( insmod, modprobe, etc )
    Use an external ( a machine with decent software ) for this so your compile doesn't break.
    I have done so in the past and it works fine. ( and plan an update for those machines, anything with 2.4 is way to old... )

    After that you can just use R1Soft hot copy,
    http://www.r1soft.com/tools/linux-hot-copy/ [r1soft.com]

    This program is free ( as in beer ) to download and works with every block device.
    You can even write to a block device if you really need to.

    Their commercial offerings are pretty good as good. ( and DO work with the 2.4 kernel )
    We use it here at work.

    I heard btrfs supports something like this as well.

    Any way, good luck!

  • Works nicely. I use it for backups over the net. One very nice feature is that it does is reverse diffs, i.e. the nearer to the present time, the faster you get files restored. You also can remove older diffs without any fuss.

  • by Anonymous Coward

    Why does Linux still lack this functionality?

    Since the early 1990's Novell has had the ability to "Salvage" deleted files and even maintained a near limitless amount of previous versions with a Copy On Write functionality. It still exists, even on Linux in their NSS(Novell Storage Services) Volumes.

    Microsoft finally got on board when their Server 2003 product implemented Volume Shadow Copies. This isn't nearly as good as Novell's implementation but, it was better than anything Microsoft had previously offer

  • ZFS and BTRFS, btrfs is included with Fedora 13 (maybe 12 too).

    ZFS is found here http://wiki.github.com/behlendorf/zfs/
  • I have scrolled to the bottem and replied after a scrolling skim. No answers for this guy yet? Just vague debate. No "use either a,b,c,d,or e".

    Thats telling.

    I am in this guys situation at work.
  • Volume shadow copy might not be doing what you think it is. I know it makes a big file, but restoring a snapshot has never worked as expected.

    It sounds like you are just trying to keep an old dinosaur alive. Reboot with a live cd and make a snapshot of the old dog.

    dd if=/dev/hda conv=sync,noerror bs=64K | gzip -c > /mnt/sda1/hda.img.gz

    That applies to Windows partitions too. It's faster and more reliable *restore* than Volume Shadow Copy on identical hardware. You can also move the Old Dog onto somew

  • Perhaps you are making this more complex than it has to be. I've had zero success simply copying the files and filesystems from a Windows server to backup and then being able to restore anything but data -- you can't reinstall a Windows OS from the moral equivalent of a Linux "cp -R" command. Linux, however, does not share this feature. You can -- and I have -- use rsync or tar to copy the entire filesystem off of a Linux machine to your backup device, then restore an entire machine -- data and
  • by Beelzebud (1361137) on Friday June 11, 2010 @05:06PM (#32543064)
    Reading through this thread has brought back the memories of when I first started using Linux. There is a subset of Linux users who seem to think that acting like a giant douche bag will help people adopt the platform.

    Don't get me wrong, I've found that there are some amazing people in the Linux community that are more than willing to help out someone genuinely willing to learn, but there still exists this subset of assholes that seem to think ridicule, and basically acting like a dickhead makes them superior. If you're one of those people get over yourself. Linux would be better off without you!
    • by Atriqus (826899)
      Yeah, the unwarranted nerd superiority complex is running a bit higher than usual in this story's comments. I see no other way around this:

      * breaks out megaphone *
      Alright guys, looks like we all have to hug it out and start over! :D
    • Re: (Score:3, Informative)

      by cynyr (703126)
      yes, it could be phrased a bit better, "to get atomic backups of data, you need LVM with the snapshot module, or be using BTRFS. If the snapshot module for LVM is unavailable in 2.4.x, you will need to upgrade" The OP is basically asking how can i use shadow volume copy to back up my FAT16 partition, running on a windows 98 computer.
  • Depending on how long you're keeping them around, LVM Snapshots are likely to be a bad choice anyway. Their intended use-case is to have a very short lifespan, because they're intended to be used like so:

    1. Create snapshot

    2. Mount snapshot & copy data to backup server

    3. Unmount & destroy snapshot

    The point behind them is to create an unchanging version of a live partition so that you can copy the data out without worrying about whether it is being updated while you copy. Since the snapshots keep a

  • You are approaching management of the Linux boxes as if they where windows boxes. That is the event causing you the greatest pain. Basically a Linux box can be divided into 3 groups

    Configurations

    Data

    OS

    Configurations: Two types Users Configs: this is kept in their home so no need to worry aboutthat as normal backup takes care of it (exception can be /root) System. System Configs: This is /etc/ and key entries in /var for the most part.

    Data: By in large this is also maintained in homes, for that

"If that makes any sense to you, you have a big problem." -- C. Durance, Computer Science 234

Working...