public static void archiveRecoveredEdits(Configuration conf, FileSystem fs, RegionInfo regionInfo,
    byte[] family, Collection<HStoreFile> replayedEdits) throws IOException {
    String workingDir = conf.get(CommonFSUtils.HBASE_WAL_DIR, conf.get(HConstants.HBASE_DIR));
    // extra sanity checks for the right FS
    Path path = new Path(workingDir);
    if (path.isAbsoluteAndSchemeAuthorityNull()) {
      // no schema specified on wal dir value, so it's on same FS as StoreFiles
      path = new Path(conf.get(HConstants.HBASE_DIR));
    }
    if (path.toUri().getScheme() != null && !path.toUri().getScheme().equals(fs.getScheme())) {
      throw new IOException(
        "Wrong file system! Should be " + path.toUri().getScheme() + ", but got " + fs.getScheme());
    }
    path = HFileArchiveUtil.getStoreArchivePathForRootDir(path, regionInfo, family);
    archive(conf, fs, regionInfo, family, replayedEdits, path);
  }
Archive recovered edits using existing logic for archiving store files. This is currently only
relevant when <b>hbase.region.archive.recovered.edits</b> is true, as recovered edits shouldn't
be kept after replay. In theory, we could use very same method available for archiving store
files, but supporting WAL dir and store files on different FileSystems added the need for extra
validation of the passed FileSystem instance and the path where the archiving edits should be
placed.
@param conf          {@link Configuration} to determine the archive directory.
@param fs            the filesystem used for storing WAL files.
@param regionInfo    {@link RegionInfo} a pseudo region representation for the archiving logic.
@param family        a pseudo familiy representation for the archiving logic.
@param replayedEdits the recovered edits to be archived.
@throws IOException if files can't be achived due to some internal error.
hbase-server/src/main/java/org/apache/hadoop/hbase/backup/HFileArchiver.java